From john.cuthbertson at oracle.com Sat Jun 1 00:33:14 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Sat, 01 Jun 2013 07:33:14 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130601073320.8987548EB0@hg.openjdk.java.net> Changeset: e341c460dcbf Author: johnc Date: 2013-05-31 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e341c460dcbf 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap Summary: Refactor G1's hot card cache and card counts table into their own files. Simplify the card counts table, including removing the encoding of the card index in each entry. The card counts table now has a 1:1 correspondence with the cards spanned by heap. Space for the card counts table is reserved from virtual memory (rather than C heap) during JVM startup and is committed/expanded when the heap is expanded. Changes were also reviewed-by Vitaly Davidovich. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp + src/share/vm/gc_implementation/g1/g1CardCounts.cpp + src/share/vm/gc_implementation/g1/g1CardCounts.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp + src/share/vm/gc_implementation/g1/g1HotCardCache.cpp + src/share/vm/gc_implementation/g1/g1HotCardCache.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cd6a08cb2b86 Author: johnc Date: 2013-05-31 19:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cd6a08cb2b86 Merge From alejandro.murillo at oracle.com Sat Jun 1 03:33:18 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 01 Jun 2013 10:33:18 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130601103328.0DF3848EB2@hg.openjdk.java.net> Changeset: d32b6216bb0e Author: amurillo Date: 2013-05-31 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d32b6216bb0e 8015689: new hotspot build - hs24-b48 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d942f92789f4 Author: amurillo Date: 2013-06-01 00:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d942f92789f4 Merge From bengt.rutisson at oracle.com Mon Jun 3 01:22:50 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 03 Jun 2013 10:22:50 +0200 Subject: Result: New hsx Committer: Thomas Schatzl In-Reply-To: <519345DF.2030207@oracle.com> References: <519345DF.2030207@oracle.com> Message-ID: <51AC525A.7050203@oracle.com> Voting for Thomas Schatzl [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Best regards, Bengt Rutisson [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-May/009511.html [2] http://openjdk.java.net/bylaws#lazy-consensus From vladimir.danushevsky at oracle.com Mon Jun 3 11:17:38 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Mon, 03 Jun 2013 18:17:38 +0000 Subject: hg: hsx/hsx24/hotspot: 8014669: arch specific flags not passed to some link commands Message-ID: <20130603181752.C80B748EF3@hg.openjdk.java.net> Changeset: 010c022d6094 Author: bpittore Date: 2013-06-03 10:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/010c022d6094 8014669: arch specific flags not passed to some link commands Summary: EXTRA_CFLAGS does not propagate to saproc and jsig makefiles Reviewed-by: dholmes, tbell, collins ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make From serguei.spitsyn at oracle.com Mon Jun 3 12:43:44 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Jun 2013 12:43:44 -0700 Subject: Review Request (S) 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' Message-ID: <51ACF1F0.3040200@oracle.com> Please, review a 1-liner fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=8015803 jbs: https://jbs.oracle.com/bugs/browse/JDK-8015803 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8015803-JVMTI-JSR292.1 Summary: Newly added test has an issue: the main class must be public. Testing: Will submit a JPRT job to verify fixed test Thanks, Serguei From serguei.spitsyn at oracle.com Mon Jun 3 12:49:44 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Jun 2013 12:49:44 -0700 Subject: Review Request (S) 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending In-Reply-To: <51A8DDFC.7000107@oracle.com> References: <51A840ED.7030501@oracle.com> <51A8D7FB.1070906@oracle.com> <51A8DDFC.7000107@oracle.com> Message-ID: <51ACF358.9020208@oracle.com> May I have one more review, please? One more explanation to help to understand the fix... The call to finalize_operands_merge() was originally misplaced. As a result, the finalize_operands_merge() is not called in some cases which is wrong. The fix is to make it called unconditionally. Thanks, Serguei On 5/31/13 10:29 AM, serguei.spitsyn at oracle.com wrote: > Thanks, Vladimir! > Serguei > > On 5/31/13 10:03 AM, Vladimir Kozlov wrote: >> Good. >> >> Vladimir >> >> On 5/30/13 11:19 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> bug: https://jbs.oracle.com/bugs/browse/JDK-8014052 >>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8014052 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8014052-JVMTI-JSR292.1 >>> >>> >>> >>> Summary: >>> A call to the finalize_operands_merge() must be unconditional. >>> Otherwise, the merge of the bootstrap method operands is not >>> completed correctly. >>> >>> >>> Testing: vm/mlvm, nsk/jvmti, nsk/jdi, nsk/jdwp >>> >>> Thanks, >>> Serguei > From vladimir.kozlov at oracle.com Mon Jun 3 13:36:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 03 Jun 2013 13:36:49 -0700 Subject: Review Request (S) 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' In-Reply-To: <51ACF1F0.3040200@oracle.com> References: <51ACF1F0.3040200@oracle.com> Message-ID: <51ACFE61.5070608@oracle.com> Good. Vladimir On 6/3/13 12:43 PM, serguei.spitsyn at oracle.com wrote: > Please, review a 1-liner fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=8015803 > jbs: https://jbs.oracle.com/bugs/browse/JDK-8015803 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8015803-JVMTI-JSR292.1 > > > Summary: > Newly added test has an issue: the main class must be public. > > > Testing: Will submit a JPRT job to verify fixed test > > Thanks, > Serguei From serguei.spitsyn at oracle.com Mon Jun 3 13:53:54 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Jun 2013 13:53:54 -0700 Subject: Review Request (S) 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' In-Reply-To: <51ACFE61.5070608@oracle.com> References: <51ACF1F0.3040200@oracle.com> <51ACFE61.5070608@oracle.com> Message-ID: <51AD0262.8030802@oracle.com> Thanks! Serguei On 6/3/13 1:36 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 6/3/13 12:43 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a 1-liner fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=8015803 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8015803 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8015803-JVMTI-JSR292.1 >> >> >> >> Summary: >> Newly added test has an issue: the main class must be public. >> >> >> Testing: Will submit a JPRT job to verify fixed test >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Mon Jun 3 13:54:49 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Jun 2013 13:54:49 -0700 Subject: Review Request (S) 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' In-Reply-To: <51AD008A.1060004@oracle.com> References: <51ACF1F0.3040200@oracle.com> <51AD008A.1060004@oracle.com> Message-ID: <51AD0299.4080604@oracle.com> Thanks, Jaroslav! Serguei On 6/3/13 1:46 PM, Jaroslav Bachorik wrote: > Looks good (not a reviewer) > > -JB- > > On Mon 03 Jun 2013 09:43:44 PM CEST, serguei.spitsyn at oracle.com wrote: >> Please, review a 1-liner fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=8015803 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8015803 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8015803-JVMTI-JSR292.1 >> >> >> Summary: >> Newly added test has an issue: the main class must be public. >> >> >> Testing: Will submit a JPRT job to verify fixed test >> >> Thanks, >> Serguei > From christian.thalinger at oracle.com Mon Jun 3 14:09:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 3 Jun 2013 14:09:25 -0700 Subject: Review Request (S) 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending In-Reply-To: <51A840ED.7030501@oracle.com> References: <51A840ED.7030501@oracle.com> Message-ID: Looks good. -- Chris On May 30, 2013, at 11:19 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > bug: https://jbs.oracle.com/bugs/browse/JDK-8014052 > jbs: https://jbs.oracle.com/bugs/browse/JDK-8014052 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8014052-JVMTI-JSR292.1 > > Summary: > A call to the finalize_operands_merge() must be unconditional. > Otherwise, the merge of the bootstrap method operands is not completed correctly. > > > Testing: vm/mlvm, nsk/jvmti, nsk/jdi, nsk/jdwp > > Thanks, > Serguei From serguei.spitsyn at oracle.com Mon Jun 3 14:11:28 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Jun 2013 14:11:28 -0700 Subject: Review Request (S) 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending In-Reply-To: References: <51A840ED.7030501@oracle.com> Message-ID: <51AD0680.3010505@oracle.com> Thanks, Chris! Serguei On 6/3/13 2:09 PM, Christian Thalinger wrote: > Looks good. -- Chris > > On May 30, 2013, at 11:19 PM, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> bug: https://jbs.oracle.com/bugs/browse/JDK-8014052 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8014052 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8014052-JVMTI-JSR292.1 >> >> Summary: >> A call to the finalize_operands_merge() must be unconditional. >> Otherwise, the merge of the bootstrap method operands is not completed correctly. >> >> >> Testing: vm/mlvm, nsk/jvmti, nsk/jdi, nsk/jdwp >> >> Thanks, >> Serguei From coleen.phillimore at oracle.com Mon Jun 3 15:22:18 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 03 Jun 2013 18:22:18 -0400 Subject: Review Request (S) 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' In-Reply-To: <51ACFE61.5070608@oracle.com> References: <51ACF1F0.3040200@oracle.com> <51ACFE61.5070608@oracle.com> Message-ID: <51AD171A.3070201@oracle.com> This looks fine. I don't think jprt runs the jtreg tests for hotspot, so you have to run the test manually. Coleen On 06/03/2013 04:36 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 6/3/13 12:43 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a 1-liner fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=8015803 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8015803 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8015803-JVMTI-JSR292.1 >> >> >> >> Summary: >> Newly added test has an issue: the main class must be public. >> >> >> Testing: Will submit a JPRT job to verify fixed test >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Mon Jun 3 15:54:57 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Jun 2013 15:54:57 -0700 Subject: Review Request (S) 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' In-Reply-To: <51AD171A.3070201@oracle.com> References: <51ACF1F0.3040200@oracle.com> <51ACFE61.5070608@oracle.com> <51AD171A.3070201@oracle.com> Message-ID: <51AD1EC1.8090700@oracle.com> Coleen, Thank you for the review! I submitted a jprt job with the test verification as Dan suggested and the job has failed as expected: jprt submit -stree . -email serguei.spitsyn at oracle.com \ -excludetests 'linux_ppc.*' -excludetests 'linux_arm.*' \ -testsonly -noqa \ -otests '.*compiler.*' -rtests '*-*-*-compiler/8015436' A nice way to verify new tests. I'm in process to submit a similar job to test my fix before the integration. Thanks, Serguei On 6/3/13 3:22 PM, Coleen Phillimore wrote: > > This looks fine. I don't think jprt runs the jtreg tests for hotspot, > so you have to run the test manually. > > Coleen > > On 06/03/2013 04:36 PM, Vladimir Kozlov wrote: >> Good. >> >> Vladimir >> >> On 6/3/13 12:43 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a 1-liner fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8015803 >>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8015803 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8015803-JVMTI-JSR292.1 >>> >>> >>> >>> Summary: >>> Newly added test has an issue: the main class must be public. >>> >>> >>> Testing: Will submit a JPRT job to verify fixed test >>> >>> Thanks, >>> Serguei > From openjdk at sunnychan.hk Tue Jun 4 22:08:22 2013 From: openjdk at sunnychan.hk (Sunny Chan) Date: Wed, 5 Jun 2013 05:08:22 +0000 (UTC) Subject: libjsig licensing issue Message-ID: Hello, Not sure where it belongs here, but I have just notice that the JVM signal chaining library (libjsig) source code is licensed with GPL but not GPL+classpath exception (see src/os/linux/jsig.c). This will means that any apps that link against openjdk's libjsig would be affected by GPL licensing. Is it possible for Oracle to license height.c with classmate exception? Thanks, Sunny Chan From staffan.larsen at oracle.com Wed Jun 5 06:54:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 5 Jun 2013 15:54:07 +0200 Subject: Heads-up: Integration of Event-Based JVM Tracing Message-ID: <74F2F687-8F5E-4FF4-A10E-0775975DF10E@oracle.com> All, We are planning to integrate "Event-Based JVM Tracing" into hotspot-rt next week. This is (more or less) a forward port of the implementation that already exists in jdk7u. The main difference compared to jdk7u is the adaptations made to support metaspace instead of permgen. The changes have been thoroughly tested internally, but given the size of the changes there is a large risk of unforeseen problems. hotspot: http://cr.openjdk.java.net/~sla/jep167/jdk8-webrev.02/hotspot/ jdk: http://cr.openjdk.java.net/~sla/jep167/jdk8-webrev.02/jdk/ Thanks From erik.helin at oracle.com Wed Jun 5 09:43:55 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Wed, 05 Jun 2013 16:43:55 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130605164412.D88DC48FB0@hg.openjdk.java.net> Changeset: 5534bd30c151 Author: jcoomes Date: 2013-05-30 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5534bd30c151 6725714: par compact - add a table to speed up bitmap searches Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 47bdfb3d010f Author: stefank Date: 2013-05-30 10:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/47bdfb3d010f 8015486: PSScavenge::is_obj_in_young is unnecessarily slow with UseCompressedOops Summary: Compare compressed oops to a compressed young gen boundary instead of uncompressing the oops before doing the young gen boundary check. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp Changeset: c20186fa611b Author: jwilhelm Date: 2013-06-01 10:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c20186fa611b Merge Changeset: e72f7eecc96d Author: tschatzl Date: 2013-05-28 09:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e72f7eecc96d 8013895: G1: G1SummarizeRSetStats output on Linux needs improvemen Summary: Fixed the output of G1SummarizeRSetStats: too small datatype for the number of concurrently processed cards, added concurrent remembered set thread time retrieval for Linux and Windows (BSD uses os::elapsedTime() now), and other cleanup. The information presented during VM operation is now relative to the previous output, not always cumulative if G1SummarizeRSetStatsPeriod > 0. At VM exit, the code prints a cumulative summary. Reviewed-by: johnc, jwilhelm ! make/excludeSrc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! 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/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStats.java Changeset: 3a4805ad0005 Author: johnc Date: 2013-06-04 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a4805ad0005 8015244: G1: Verification after a full GC is incorrectly placed. Summary: In a full GC, move the verification after the GC to after RSet rebuilding. Verify RSet entries during a full GC under control of a flag. Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 87c64c0438fb Author: tamao Date: 2013-06-03 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/87c64c0438fb 6976350: G1: deal with fragmentation while copying objects during GC Summary: Create G1ParGCAllocBufferContainer to contain two buffers instead of previously using one buffer, in order to hold the first priority buffer longer. Thus, when some large objects hits the value of free space left in the first priority buffer it has an alternative to fit in the second priority buffer while the first priority buffer is given more chances to try allocating smaller objects. Overall, it will improve heap space efficiency. Reviewed-by: johnc, jmasa, brutisso Contributed-by: tamao ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp Changeset: 2f7a31318b84 Author: johnc Date: 2013-06-04 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f7a31318b84 Merge From nils.loodin at oracle.com Wed Jun 5 13:08:56 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Wed, 05 Jun 2013 20:08:56 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20130605200917.55C3348FC4@hg.openjdk.java.net> Changeset: a1ebd310d5c1 Author: iklam Date: 2013-05-28 16:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a1ebd310d5c1 8014912: Restore PrintSharedSpaces functionality after NPG Summary: Added dumping of object sizes in CDS archive, sorted by MetaspaceObj::Type Reviewed-by: coleenp, acorn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodCounters.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/utilities/array.hpp Changeset: fe00365c8f31 Author: sspitsyn Date: 2013-05-30 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fe00365c8f31 8015436: compiler/ciReplay/TestSA.sh fails with assert() index is out of bounds Summary: The InstanceKlass _initial_method_idnum value must be adjusted if overpass methods are added. Reviewed-by: twisti, kvn Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/classfile/defaultMethods.cpp + test/compiler/8015436/Test8015436.java Changeset: a589c78a8811 Author: rbackman Date: 2013-05-31 13:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a589c78a8811 8014709: Constructor.getAnnotatedReturnType() returns empty AnnotatedType Reviewed-by: stefank, rbackman Contributed-by: Joel Borggren-Franck ! src/share/vm/runtime/reflection.cpp ! test/runtime/8007320/ConstMethodTest.java Changeset: efe8b7d64424 Author: ctornqvi Date: 2013-05-31 20:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/efe8b7d64424 6726963: multi_allocate() call does not CHECK_NULL and causes crash in fastdebug bits Summary: Using CHECK_NULL when calling multi_allocate() from the corresponding reflection code; added test for this condition Reviewed-by: dholmes, minqi Contributed-by: Mikhailo Seledtsov ! src/share/vm/runtime/reflection.cpp + test/runtime/memory/MultiAllocateNullCheck.java Changeset: 532c55335fb6 Author: dcubed Date: 2013-06-01 09:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/532c55335fb6 Merge Changeset: 4552a7633a07 Author: hseigel Date: 2013-06-03 10:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4552a7633a07 8015385: Remove RelaxAccessControlCheck for JDK 8 bytecodes Summary: Check bytecode versions along with RelaxAccessControlCheck version Reviewed-by: dholmes, acorn ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/reflection.cpp Changeset: e7d29a019a3c Author: sspitsyn Date: 2013-06-03 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e7d29a019a3c 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending Summary: A call to the finalize_operands_merge() must be unconditional Reviewed-by: kvn, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 2f004f9dc9e1 Author: sspitsyn Date: 2013-06-04 01:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f004f9dc9e1 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' Summary: Newly added test has an issue: the main class must be public Reviewed-by: kvn, jbachorik, coleenp Contributed-by: serguei.spitsyn at oracle.com ! test/compiler/8015436/Test8015436.java Changeset: 04551f4dbdb9 Author: nloodin Date: 2013-06-05 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/04551f4dbdb9 Merge From john.cuthbertson at oracle.com Wed Jun 5 16:46:31 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Wed, 05 Jun 2013 23:46:31 +0000 Subject: hg: hsx/hsx24/hotspot: 8014408: G1: crashes with assert assert(prev_committed_card_num == _committed_max_card_num) failed Message-ID: <20130605234639.0971848FD5@hg.openjdk.java.net> Changeset: 02d2b7ba71ad Author: johnc Date: 2013-05-15 22:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/02d2b7ba71ad 8014408: G1: crashes with assert assert(prev_committed_card_num == _committed_max_card_num) failed Summary: Mismatch in the card number calculation between next and previous committed sizes of the card counts table. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp From harold.seigel at oracle.com Thu Jun 6 08:30:37 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 06 Jun 2013 15:30:37 +0000 Subject: hg: hsx/hsx24/hotspot: 8009302: Mac OS X: JVM crash on infinite recursion on Appkit Thread Message-ID: <20130606153043.7EDCD4800D@hg.openjdk.java.net> Changeset: d1c1d2ffc2c5 Author: hseigel Date: 2013-06-06 08:54 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d1c1d2ffc2c5 8009302: Mac OS X: JVM crash on infinite recursion on Appkit Thread Summary: Use SA_ONSTACK flag to ensure signal gets delivered properly. Reviewed-by: dholmes, coleenp Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp From daniel.daugherty at oracle.com Thu Jun 6 08:32:56 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 06 Jun 2013 15:32:56 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20130606153316.6D86E4800E@hg.openjdk.java.net> Changeset: 62e7bac9524f Author: dcubed Date: 2013-06-04 19:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/62e7bac9524f 8010257: remove unused thread-local variables _ScratchA and _ScratchB Summary: Remove dead code. Reviewed-by: twisti, coleenp ! src/share/vm/runtime/thread.hpp Changeset: 6bf8b8bb7c19 Author: hseigel Date: 2013-06-05 14:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6bf8b8bb7c19 8009302: Mac OS X: JVM crash on infinite recursion on Appkit Thread Summary: Use SA_ONSTACK flag to ensure signal gets delivered properly. Reviewed-by: dholmes, coleenp Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: f8c8cace25ad Author: dcubed Date: 2013-06-06 05:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f8c8cace25ad Merge ! src/os/bsd/vm/os_bsd.cpp From alejandro.murillo at oracle.com Thu Jun 6 15:09:52 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 06 Jun 2013 22:09:52 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130606221006.9500E4802A@hg.openjdk.java.net> Changeset: 439a2cb6fcc9 Author: katleman Date: 2013-06-05 17:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/439a2cb6fcc9 Added tag jdk7u40-b28 for changeset 6206774b5959 ! .hgtags Changeset: 58e723f20009 Author: amurillo Date: 2013-06-06 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/58e723f20009 Merge Changeset: d74376b0f20b Author: amurillo Date: 2013-06-06 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d74376b0f20b Added tag hs24-b48 for changeset 58e723f20009 ! .hgtags From vladimir.kozlov at oracle.com Thu Jun 6 19:01:58 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 07 Jun 2013 02:01:58 +0000 Subject: hg: hsx/hotspot-main/hotspot: 13 new changesets Message-ID: <20130607020237.4B2C548037@hg.openjdk.java.net> Changeset: 320b4e0f0892 Author: roland Date: 2013-05-30 11:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/320b4e0f0892 8015585: Missing regression test for 8011771 Summary: missing regression test Reviewed-by: kvn + test/compiler/8011771/Test8011771.java Changeset: f15fe46d8c00 Author: twisti Date: 2013-05-30 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f15fe46d8c00 8015266: fix some -Wsign-compare warnings in adlc Reviewed-by: kvn ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp Changeset: 28e5aed7f3a6 Author: roland Date: 2013-05-31 14:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/28e5aed7f3a6 8009981: nashorn tests fail with -XX:+VerifyStack Summary: nmethod::preserve_callee_argument_oops() must take appendix into account. Reviewed-by: kvn, twisti ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 83dcb116fdb1 Author: kvn Date: 2013-05-31 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/83dcb116fdb1 8015441: runThese crashed with assert(opcode == Op_ConP || opcode == Op_ThreadLocal || opcode == Op_CastX2P ..) failed: sanity Summary: Relax the assert to accept any raw ptr types. Reviewed-by: roland ! src/share/vm/opto/escape.cpp Changeset: c07dd9be16e8 Author: anoll Date: 2013-05-31 06:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c07dd9be16e8 8013496: Code cache management command line options work only in special order. Another order of arguments does not deliver the second parameter to the jvm. Summary: Moved check that ReservedCodeCacheSize >= InitialCodeCacheSize to Arguments::check_vm_args_consistency(). As a result, the ordering in which the two parameters are given to the VM is not relevant. Added a regression test. Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/8013496/Test8013496.sh Changeset: 603ca7e51354 Author: roland Date: 2013-04-24 11:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/603ca7e51354 8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292 Summary: ConstMethod::max_stack() doesn't account for JSR 292 appendix. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/matcher.cpp Changeset: 813f26e34135 Author: anoll Date: 2013-06-03 08:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/813f26e34135 8013329: File leak in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: Added calling of the destructor of CompileLog so that files are closed. Added/moved memory allocation/deallocation of the string that contains the name of the log file to class CompileLog. Reviewed-by: kvn, roland ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp Changeset: b274ac1dbe11 Author: adlertz Date: 2013-06-03 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b274ac1dbe11 8005956: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Summary: Disable re-materialization of reaching definitions (which have live inputs) for phi nodes when spilling. Reviewed-by: twisti, kvn ! src/share/vm/opto/reg_split.cpp Changeset: 770e91e578a6 Author: kvn Date: 2013-06-03 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/770e91e578a6 Merge Changeset: 075ea888b039 Author: morris Date: 2013-06-04 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/075ea888b039 8010724: [parfait] Null pointer dereference in hotspot/src/share/vm/c1/c1_LIRGenerator.cpp Summary: added guarantee() Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 2cb5d5f6d5e5 Author: simonis Date: 2013-06-04 22:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2cb5d5f6d5e5 8015252: Enable HotSpot build with Clang Reviewed-by: twisti, dholmes, kvn ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 609aad72004a Author: anoll Date: 2013-06-06 09:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/609aad72004a 8014246: remove assert to catch access to object headers in index_oop_from_field_offset_long Reviewed-by: twisti, jrose ! src/share/vm/prims/unsafe.cpp Changeset: ef1818846c22 Author: kvn Date: 2013-06-06 11:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ef1818846c22 Merge ! src/os/bsd/vm/os_bsd.cpp From alejandro.murillo at oracle.com Thu Jun 6 21:27:12 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 07 Jun 2013 04:27:12 +0000 Subject: hg: hsx/hsx24/hotspot: 8016077: new hotspot build - hs24-b49 Message-ID: <20130607042717.21C5448042@hg.openjdk.java.net> Changeset: 84d31cb59402 Author: amurillo Date: 2013-06-06 11:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/84d31cb59402 8016077: new hotspot build - hs24-b49 Reviewed-by: jcoomes ! make/hotspot_version From markus.gronlund at oracle.com Fri Jun 7 00:07:54 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 7 Jun 2013 00:07:54 -0700 (PDT) Subject: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp Message-ID: <1a584728-48fd-4640-926d-e0b70be7e4e3@default> Greetings, ? Kindly asking for reviews for the following: ? Bug id: ????http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016105 ? Webrev: http://cr.openjdk.java.net/~mgronlun/8016105/webrev01/ ? ? Thank you Markus From john.coomes at oracle.com Fri Jun 7 01:32:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jun 2013 08:32:47 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b93 for changeset 7386eca865e1 Message-ID: <20130607083253.B9C7548071@hg.openjdk.java.net> Changeset: 254c53fd97ab Author: katleman Date: 2013-06-06 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/254c53fd97ab Added tag jdk8-b93 for changeset 7386eca865e1 ! .hgtags From john.coomes at oracle.com Fri Jun 7 01:32:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jun 2013 08:32:11 +0000 Subject: hg: hsx/hotspot-main: 12 new changesets Message-ID: <20130607083212.0E1124806D@hg.openjdk.java.net> Changeset: 78852ce176db Author: jqzuo Date: 2013-05-28 20:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/78852ce176db 8014762: Add JMC configure option mapping to Jprt.gmk Summary: Need to add the mapping between JPRT env var and configure flag for JMC, from ALT_JMC_ZIP_DIR to --with-jmc-zip-dir (same pattern as for Javafx) Reviewed-by: tbell, erikj Contributed-by: klara.ward at oracle.com ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: c22d59e3f06e Author: pbhat Date: 2013-05-29 11:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c22d59e3f06e Merge Changeset: ea6f3bf82903 Author: jqzuo Date: 2013-06-04 00:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ea6f3bf82903 Merge ! common/autoconf/generated-configure.sh Changeset: 33b6df33a2b7 Author: erikj Date: 2013-05-29 13:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/33b6df33a2b7 8013920: Configure sets JOBS to 0 if memory is too low. Reviewed-by: tbell ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh Changeset: 03e60e87d92a Author: erikj Date: 2013-05-29 14:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/03e60e87d92a 8013489: New build system does not run codesign on SA-related launchers on OS X Reviewed-by: sla, tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/MakeBase.gmk ! common/makefiles/NativeCompilation.gmk Changeset: c31e9dc1fe3d Author: erikj Date: 2013-05-31 14:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c31e9dc1fe3d 8014003: New build does not handle symlinks in workspace path Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/generated-configure.sh Changeset: 44259699e0b5 Author: erikj Date: 2013-06-04 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/44259699e0b5 8015784: Add configure parameter --with-update-version Reviewed-by: tbell, katleman, erikj Contributed-by: tristan.yan at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: db3144e1f89b Author: mduigou Date: 2013-06-04 10:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/db3144e1f89b 8015510: (s) Improve JTReg location detection and provide location to test/Makefile Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/makefiles/Main.gmk Changeset: 9b8e8098172c Author: katleman Date: 2013-06-04 11:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9b8e8098172c Merge Changeset: f55734874c4f Author: katleman Date: 2013-06-04 15:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f55734874c4f Merge ! common/autoconf/generated-configure.sh Changeset: 27c51c6e31c1 Author: katleman Date: 2013-06-05 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/27c51c6e31c1 6983966: remove lzma and upx from repository JDK8 Reviewed-by: tbell, paulk, ngthomas ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk ! make/deploy-rules.gmk Changeset: 8dfb6ee04114 Author: katleman Date: 2013-06-06 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8dfb6ee04114 Added tag jdk8-b93 for changeset 27c51c6e31c1 ! .hgtags From john.coomes at oracle.com Fri Jun 7 01:32:15 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jun 2013 08:32:15 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b93 for changeset 8dc9d7ccbb2d Message-ID: <20130607083218.E8C574806E@hg.openjdk.java.net> Changeset: 22f5d7f261d9 Author: katleman Date: 2013-06-06 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/22f5d7f261d9 Added tag jdk8-b93 for changeset 8dc9d7ccbb2d ! .hgtags From john.coomes at oracle.com Fri Jun 7 01:34:43 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jun 2013 08:34:43 +0000 Subject: hg: hsx/hotspot-main/jdk: 68 new changesets Message-ID: <20130607084909.577EC48074@hg.openjdk.java.net> Changeset: 93de1ab38793 Author: jchen Date: 2013-05-17 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/93de1ab38793 8003444: Fix potential NULL pointer dereference Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c Changeset: 0cec8dc2bcf8 Author: lana Date: 2013-05-22 19:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0cec8dc2bcf8 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 0208f5f12dc3 Author: jchen Date: 2013-05-23 12:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0208f5f12dc3 8012629: java.lang.UnsatisfiedLinkError exception throw by getAllFonts() on MacOSX Reviewed-by: bae, prr ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mawt.gmk ! makefiles/CompileNativeLibraries.gmk ! src/macosx/native/sun/font/AWTFont.m Changeset: f24f9038e050 Author: prr Date: 2013-05-24 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f24f9038e050 8008535: JDK7 Printing : CJK and Latin Text in a string overlap Reviewed-by: bae, jgodinez ! src/windows/classes/sun/awt/windows/WPathGraphics.java + test/java/awt/print/PrinterJob/PrintLatinCJKTest.java Changeset: f4ad2fa22474 Author: jgodinez Date: 2013-05-29 09:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4ad2fa22474 7183520: [macosx]Unable to print out the defined page for 2D_PrintingTiger/JTablePrintPageRangesTest. Reviewed-by: bae, prr ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java Changeset: 7e2a887a069e Author: jgodinez Date: 2013-05-29 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7e2a887a069e 8012381: [macosx]Unable to print out the defined page for 2D_PrintingTiger/JTablePrintPageRangesTest Reviewed-by: jchen, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! test/java/awt/print/PrinterJob/Collate2DPrintingTest.java Changeset: 8ac29ee867fd Author: lana Date: 2013-05-29 16:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8ac29ee867fd Merge Changeset: 85df65495177 Author: mcherkas Date: 2013-05-21 03:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85df65495177 7011777: JDK 6 parses html text with script tags within comments differently from previous releases Reviewed-by: alexsch Contributed-by: Dmitry Markov ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/7011777/bug7011777.java Changeset: e36d0b9ed018 Author: alitvinov Date: 2013-05-21 05:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e36d0b9ed018 8005607: Recursion in J2DXErrHandler() Causes a Stack Overflow on Linux Reviewed-by: art, anthony, prr ! src/solaris/classes/sun/awt/X11/MotifDnDConstants.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/WindowPropertyGetter.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XErrorHandler.java + src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTranslateCoordinates.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.h ! src/solaris/native/sun/awt/awt_util.c ! src/solaris/native/sun/awt/awt_util.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 73d3bed5f8c8 Author: lana Date: 2013-05-22 17:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/73d3bed5f8c8 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 6261e94e9869 Author: alexsch Date: 2013-05-23 15:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6261e94e9869 8014924: JToolTip#setTipText() sometimes (very often) not repaints component. Reviewed-by: serb ! src/share/classes/javax/swing/JToolTip.java Changeset: e8cacde33d27 Author: ant Date: 2013-05-24 18:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8cacde33d27 8013437: Test sun/awt/datatransfer/SuplementaryCharactersTransferTest.java fails to compile since 8b86 Reviewed-by: alexsch ! test/sun/awt/datatransfer/SuplementaryCharactersTransferTest.java Changeset: 6b29c27d0807 Author: malenkov Date: 2013-05-24 19:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6b29c27d0807 8013416: Java Bean Persistence with XMLEncoder Reviewed-by: alexsch ! src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java + test/java/beans/XMLEncoder/Test8013416.java Changeset: c36626831f07 Author: vkarnauk Date: 2013-05-27 12:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c36626831f07 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 70ac1bf74865 Author: serb Date: 2013-05-27 22:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70ac1bf74865 8014726: TEST_BUG: java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java should be modified Reviewed-by: serb, anthony Contributed-by: alexander.zvegintsev at oracle.com ! test/java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java Changeset: ff1c2e379f27 Author: pchelko Date: 2013-05-28 12:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff1c2e379f27 8000422: [macosx] Views keep scrolling back to the drag position after DnD Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java Changeset: 4f24a4f65a07 Author: anthony Date: 2013-05-28 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4f24a4f65a07 7039616: java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java should be updated Summary: Consider the test passed if the system does not support translucency Reviewed-by: art ! test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java Changeset: 1f0628078531 Author: pchelko Date: 2013-05-29 12:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1f0628078531 8009911: [macosx] SWT app freeze when going full screen using Java 7 on Mac Reviewed-by: anthony, ksrini ! src/macosx/bin/java_md_macosx.c Changeset: c8a0abc1fd2d Author: mcherkas Date: 2013-05-29 18:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c8a0abc1fd2d 8014863: Line break calculations in Java 7 are incorrect. Reviewed-by: alexp, alexsch Contributed-by: Dmitry Markov ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/View/8014863/bug8014863.java Changeset: aae7b96a350e Author: lana Date: 2013-05-29 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aae7b96a350e Merge Changeset: 3b1450ee2bb9 Author: dxu Date: 2013-05-17 12:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b1450ee2bb9 8011136: FileInputStream.available and skip inconsistencies Summary: Correct the behavior of available() and update related java specs for available() and skip() in InputStream and FileInputStream classes. Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/InputStream.java ! src/share/native/java/io/FileInputStream.c ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/FileInputStream/NegativeAvailable.java Changeset: 0f7aaabed25f Author: weijun Date: 2013-05-18 10:15 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0f7aaabed25f 8012261: update policytool to support java.net.HttpURLPermission Reviewed-by: mullan ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java Changeset: e8b40b034fcd Author: psandoz Date: 2013-05-15 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8b40b034fcd 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit Summary: this changeset also contains some minor, non spec, related fixes to tidy up other areas of the JavaDoc. Reviewed-by: plevart, darcy Contributed-by: John Rose , Mike Duigou , Paul Sandoz ! src/share/classes/java/util/Spliterator.java Changeset: 6bbc2816d936 Author: psandoz Date: 2013-05-15 10:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6bbc2816d936 8014133: Spliterator.OfPrimitive Reviewed-by: mduigou, forax Contributed-by: Paul Sandoz , Brian Goetz ! src/share/classes/java/util/Spliterator.java Changeset: dc5cf74c8c9c Author: mduigou Date: 2013-05-17 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dc5cf74c8c9c 8004015: Additional static and instance utils for functional interfaces. 8011010: Spec j.u.f.Predicate doesn't specify NPEs thrown by the SE8's Reference Implementation Reviewed-by: briangoetz, dholmes, chegar ! src/share/classes/java/util/function/BiConsumer.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BooleanSupplier.java ! src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/ObjDoubleConsumer.java ! src/share/classes/java/util/function/ObjIntConsumer.java ! src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java ! src/share/classes/java/util/function/ToDoubleFunction.java ! src/share/classes/java/util/function/ToIntBiFunction.java ! src/share/classes/java/util/function/ToIntFunction.java ! src/share/classes/java/util/function/ToLongBiFunction.java ! src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java Changeset: 23e75751554a Author: henryjen Date: 2013-05-09 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23e75751554a 8006884: (fs) Add Files.list, lines and find Reviewed-by: briangoetz, mduigou Contributed-by: alan.bateman at oracle.com, henry.jen at oracle.com + src/share/classes/java/nio/file/FileTreeIterator.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java + test/java/nio/file/Files/FaultyFileSystem.java ! test/java/nio/file/Files/PassThroughFileSystem.java + test/java/nio/file/Files/StreamTest.java Changeset: b9b26b424bfc Author: mduigou Date: 2013-05-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b9b26b424bfc Merge Changeset: 08ebdb2b53cc Author: plevart Date: 2013-05-17 14:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/08ebdb2b53cc 8014477: (str) Race condition in String.contentEquals when comparing with StringBuffer Reviewed-by: alanb, mduigou, dholmes ! src/share/classes/java/lang/String.java + test/java/lang/String/StringContentEqualsBug.java Changeset: 6a9148865139 Author: sherman Date: 2013-05-20 11:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a9148865139 8004789: (zipfs) zip provider doesn't work correctly with file systems providers rather than the default Summary: to use Files.createTempFile(...) to create the temp file on the same fs as the targeted path. Reviewed-by: alanb, sherman Contributed-by: philippe.marschall at gmail.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java Changeset: 1baf3d7fe2f1 Author: dholmes Date: 2013-05-21 01:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1baf3d7fe2f1 8014857: Enable ergonomic VM selection in arm/jvm.cfg Reviewed-by: darcy ! src/solaris/bin/arm/jvm.cfg Changeset: 20925206aef8 Author: alanb Date: 2013-05-21 08:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/20925206aef8 8014892: More ProblemList.txt updates (5/2013) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: 63c7e92e5e6d Author: yhuang Date: 2013-05-20 23:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/63c7e92e5e6d 7074882: Locale data needs correction (Month names for Maltese language) Reviewed-by: naoto ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 1fba35ef4360 Author: yhuang Date: 2013-05-21 01:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1fba35ef4360 Merge Changeset: 48e8a6e0c805 Author: chegar Date: 2013-05-22 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/48e8a6e0c805 8010182: Thread safety of Thread get/setName() Reviewed-by: dholmes, alanb, mduigou ! src/share/classes/java/lang/Thread.java Changeset: 4b555b53dc57 Author: mduigou Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b555b53dc57 8014819: set max size for jtreg testvms Reviewed-by: alanb, darcy ! test/Makefile Changeset: bcfab7056195 Author: lana Date: 2013-05-22 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bcfab7056195 Merge Changeset: 760d4187597a Author: lana Date: 2013-05-22 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/760d4187597a Merge Changeset: 50fde3eeb48c Author: naoto Date: 2013-05-22 16:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/50fde3eeb48c 7056126: DateFormatSymbols documentation has incorrect description about DateFormat 7083668: Sample code in ListResourceBundle is still not correct Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/util/ListResourceBundle.java Changeset: a1a8e71e130a Author: dholmes Date: 2013-05-22 20:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a1a8e71e130a 8014814: (str) StringBuffer "null" is not appended Reviewed-by: alanb ! src/share/classes/java/lang/StringBuffer.java ! test/java/lang/StringBuffer/ToStringCache.java Changeset: e764bb01567e Author: darcy Date: 2013-05-22 20:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e764bb01567e 8014836: Have GenericDeclaration extend AnnotatedElement Reviewed-by: abuckley, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java Changeset: 0da6485cf656 Author: nloodin Date: 2013-05-23 15:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0da6485cf656 8014048: Online user guide of jconsole points incorrect link Reviewed-by: mchung, sla, jbachorik ! src/share/classes/sun/tools/jconsole/AboutDialog.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: 3b23e3529ab3 Author: dl Date: 2013-05-23 18:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b23e3529ab3 8014076: Arrays parallel and serial sorting improvements Reviewed-by: chegar, mduigou ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/ArraysParallelSortHelpers.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/DualPivotQuicksort.java ! src/share/classes/java/util/TimSort.java ! test/java/util/Arrays/ParallelSorting.java Changeset: 6816afd70a68 Author: weijun Date: 2013-05-24 17:15 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6816afd70a68 8014196: ktab creates a file with zero kt_vno Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java + test/sun/security/krb5/tools/KtabZero.java + test/sun/security/krb5/tools/ktzero.sh Changeset: 5e769206f036 Author: ksrini Date: 2013-05-24 17:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5e769206f036 8007333: [launcher] removes multiple back slashes Reviewed-by: alanb, akhil ! src/windows/bin/cmdtoargs.c ! test/tools/launcher/Arrrghs.java Changeset: d78f91ab0e96 Author: uta Date: 2013-05-27 15:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d78f91ab0e96 8014394: (fs) WatchService failing when watching \\server\$d Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 0b8dab7fec54 Author: plevart Date: 2013-05-27 09:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0b8dab7fec54 7038914: VM could throw uncaught OOME in ReferenceHandler thread Summary: Catch OutOfMemoryError in reference handler thread if caused by allocation of an InterruptedException Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/ref/Reference.java + test/java/lang/ref/OOMEInReferenceHandler.java Changeset: a2dc42667df3 Author: chegar Date: 2013-05-27 14:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a2dc42667df3 8015439: Minor/sync/cleanup of ConcurrentHashMap Reviewed-by: chegar Contributed-by: Doug Lea
, Chris Hegarty ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: 9bbf2237071e Author: chegar Date: 2013-05-27 15:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9bbf2237071e Merge Changeset: bbf6e6222726 Author: nloodin Date: 2013-05-27 17:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bbf6e6222726 6470730: Disconnect button leads to wrong popup message Reviewed-by: dcubed, sla, egahlin ! src/share/classes/sun/tools/jconsole/VMPanel.java Changeset: 7d9fab5d86cd Author: jbachorik Date: 2013-05-28 15:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d9fab5d86cd 8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows Reviewed-by: chegar, smarks, dfuchs ! test/ProblemList.txt ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java + test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Changeset: 7d7bfce34a79 Author: dsamersoff Date: 2013-05-28 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d7bfce34a79 8014420: Default JDP address does not match the one assigned by IANA Summary: JDP protocol defaults changed to IANA assigned values Reviewed-by: dholmes, jbachorik, hirt Contributed-by: fweimer at redhat.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/jdp/package-info.java ! test/sun/management/jdp/JdpTest.sh Changeset: b16a8b4ae6b4 Author: robm Date: 2013-05-28 16:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b16a8b4ae6b4 7038105: File.isHidden() should return true for pagefile.sys and hiberfil.sys Reviewed-by: alanb ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/IsHidden.java Changeset: 7fa2d1dcb8f6 Author: sherman Date: 2013-05-28 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7fa2d1dcb8f6 8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method Summary: to make defensive copy for set/get replacement byte array Reviewed-by: martin ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java Changeset: b99d56d1aa3f Author: naoto Date: 2013-05-28 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b99d56d1aa3f 6251788: (rb) PropertyResourceBundle doesn't document exceptions Reviewed-by: okutsu ! src/share/classes/java/util/PropertyResourceBundle.java Changeset: 1652a22cf6e7 Author: xuelei Date: 2013-05-28 18:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1652a22cf6e7 8010815: some constructors issues in com.sun.jndi.toolkit Reviewed-by: alanb ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Changeset: e59d7f0f36f7 Author: ewang Date: 2013-05-28 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e59d7f0f36f7 8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently Reviewed-by: dxu, alanb Contributed-by: yiming.wang at oracle.com ! test/java/io/pathNames/General.java ! test/java/io/pathNames/GeneralWin32.java Changeset: bd6d3801347b Author: sla Date: 2013-05-29 09:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bd6d3801347b 8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException Summary: Make sure serial gc compacts heap every time Reviewed-by: mchung, brutisso, nloodin ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java Changeset: 2b3242a69a44 Author: alanb Date: 2013-05-29 10:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2b3242a69a44 8014928: (fs) Files.readAllBytes() copies content to new array when content completely read Reviewed-by: martin ! src/share/classes/java/nio/file/Files.java Changeset: 00ad19610e75 Author: vinnie Date: 2013-05-29 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/00ad19610e75 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 5d9273a5a84e Author: lana Date: 2013-05-29 16:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d9273a5a84e Merge - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Changeset: 7eae7c89dab4 Author: lana Date: 2013-06-03 23:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7eae7c89dab4 Merge - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Changeset: 583e6dec1ed7 Author: erikj Date: 2013-05-29 14:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/583e6dec1ed7 8013489: New build system does not run codesign on SA-related launchers on OS X Reviewed-by: sla, tbell ! makefiles/CompileLaunchers.gmk Changeset: d8c97d6772cd Author: erikj Date: 2013-05-30 09:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d8c97d6772cd Merge Changeset: bc3a17982aae Author: erikj Date: 2013-05-31 14:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc3a17982aae 7195481: FDS: debuginfo file for libjdwp.so is missed Reviewed-by: tbell ! make/jpda/back/Makefile ! makefiles/CompileNativeLibraries.gmk Changeset: c50add191a39 Author: katleman Date: 2013-06-04 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c50add191a39 Merge ! makefiles/CompileNativeLibraries.gmk Changeset: 16003f414ca3 Author: katleman Date: 2013-06-04 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/16003f414ca3 8015644: makefile changes to allow integration of new features Reviewed-by: tbell, erikj, dholmes Contributed-by: amy.y.wang at oracle.com ! makefiles/Images.gmk Changeset: 691d6c6cd332 Author: katleman Date: 2013-06-05 15:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/691d6c6cd332 6983966: remove lzma and upx from repository JDK8 Reviewed-by: tbell, paulk, ngthomas ! make/common/Defs-windows.gmk Changeset: 7b757d567346 Author: katleman Date: 2013-06-06 09:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7b757d567346 Added tag jdk8-b93 for changeset 691d6c6cd332 ! .hgtags From john.coomes at oracle.com Fri Jun 7 01:51:54 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jun 2013 08:51:54 +0000 Subject: hg: hsx/hotspot-main/langtools: 20 new changesets Message-ID: <20130607085255.405C348075@hg.openjdk.java.net> Changeset: 0928f2cfbf8e Author: jjg Date: 2013-05-17 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0928f2cfbf8e 6885876: add comments to javac/util/Convert.java Reviewed-by: mduigou ! src/share/classes/com/sun/tools/javac/util/Convert.java Changeset: 67cbd6d756f4 Author: jfranck Date: 2013-05-21 12:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/67cbd6d756f4 8013180: Qualified type reference with annotations in throws list crashes compiler Reviewed-by: jjg + test/tools/javac/annotations/typeAnnotations/8013180/QualifiedName.java Changeset: 824932ecdbc8 Author: vromero Date: 2013-05-21 11:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/824932ecdbc8 7177168: Redundant array copy in UnsharedNameTable Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java Changeset: 3d9750039fff Author: vromero Date: 2013-05-21 12:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3d9750039fff 7060779: test/tools/javac/diags/Example.java leaves directories in tempdir Reviewed-by: mcimadamore ! test/tools/javac/diags/Example.java Changeset: 37295244f534 Author: vromero Date: 2013-05-21 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/37295244f534 8005207: test has 2 @bug tags Reviewed-by: mcimadamore ! test/tools/doclint/RunTest.java ! test/tools/javac/5045412/Bar.java ! test/tools/javac/5045412/Foo.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/policy/test3/Test.java Changeset: 08daea43a7f8 Author: vromero Date: 2013-05-21 14:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/08daea43a7f8 7164114: Two jtreg tests are not run due to no file extension on the test files Reviewed-by: mcimadamore - test/tools/javac/HiddenAbstractMethod/Test + test/tools/javac/HiddenAbstractMethod/Test.java - test/tools/javac/NonAmbiguousField/Test + test/tools/javac/NonAmbiguousField/Test.java ! test/tools/javac/NonAmbiguousField/two/Child2.java Changeset: 31344e8e3343 Author: lana Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/31344e8e3343 Merge Changeset: 3bd22f99d408 Author: darcy Date: 2013-05-22 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3bd22f99d408 8010680: Clarify "present" and annotation ordering in javax.lang.model Reviewed-by: abuckley, jjg ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/util/Elements.java Changeset: 58329d9f6b68 Author: mcimadamore Date: 2013-05-24 15:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/58329d9f6b68 8014643: Parser regression in JDK 8 when compiling super.x Summary: Fixed latent bug in JavacParser.analyzeParens() Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/8014643/T8014643.java Changeset: 97a9b4b3e63a Author: mcimadamore Date: 2013-05-24 15:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/97a9b4b3e63a 8014649: Regression: bug in Resolve.resolveOperator Summary: Missing curly braces causes Resolve.findMethod to be called spuriously Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/tests/PrimitiveBinopOverload.java Changeset: 6e5076af4660 Author: mcimadamore Date: 2013-05-24 15:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6e5076af4660 8014494: javac crashes when varargs element of a method reference is inferred from the context Summary: varargs element is not refreshed after type-inference Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/TargetType73.java Changeset: 0f8e9a0e5d9a Author: darcy Date: 2013-05-24 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0f8e9a0e5d9a 8014836: Have GenericDeclaration extend AnnotatedElement Reviewed-by: jfranck ! src/share/sample/language/model/CoreReflectionFactory.java Changeset: b391ecea538e Author: vromero Date: 2013-05-27 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b391ecea538e 7030476: Fix conflicting use of JCTree/JCExpression Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java Changeset: c6df5b20f9eb Author: vromero Date: 2013-05-28 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c6df5b20f9eb 6970173: Debug pointer at bad position Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java Changeset: d042cba65eab Author: vromero Date: 2013-05-28 17:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d042cba65eab 8012333: javac, ClassFile should have a read(Path) method Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/ClassFile.java Changeset: 92e420e9807d Author: vromero Date: 2013-05-29 10:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/92e420e9807d 7053059: VerifyError with double Assignment using a Generic Member of a Superclass Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/T7053059/VerifyErrorWithDoubleAssignmentTest.java Changeset: d685b12b62a4 Author: jjg Date: 2013-05-29 15:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d685b12b62a4 8015641: genstubs needs to cope with static interface methods Reviewed-by: ksrini ! make/tools/genstubs/GenStubs.java Changeset: 18943a1b7a47 Author: lana Date: 2013-05-29 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/18943a1b7a47 Merge - test/tools/javac/HiddenAbstractMethod/Test - test/tools/javac/NonAmbiguousField/Test Changeset: 2c5a568ee36e Author: lana Date: 2013-06-03 23:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2c5a568ee36e Merge - test/tools/javac/HiddenAbstractMethod/Test - test/tools/javac/NonAmbiguousField/Test Changeset: 888386fddc09 Author: katleman Date: 2013-06-06 09:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/888386fddc09 Added tag jdk8-b93 for changeset 2c5a568ee36e ! .hgtags From john.coomes at oracle.com Fri Jun 7 01:32:23 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jun 2013 08:32:23 +0000 Subject: hg: hsx/hotspot-main/jaxp: 6 new changesets Message-ID: <20130607083243.65C634806F@hg.openjdk.java.net> Changeset: a7cec93e4682 Author: joehw Date: 2013-05-20 16:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a7cec93e4682 8014891: Redundant setting of external access properties in setFeatures Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: 37b73984640a Author: joehw Date: 2013-05-20 23:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/37b73984640a 8012683: Remove unused, obsolete ObjectFactory classes Reviewed-by: lancea - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java Changeset: 0765806dcc58 Author: lana Date: 2013-05-22 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0765806dcc58 Merge Changeset: 627c265d6e0c Author: lana Date: 2013-05-29 16:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/627c265d6e0c Merge - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java Changeset: d583a491d63c Author: lana Date: 2013-06-03 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d583a491d63c Merge - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java Changeset: 40da96cab40e Author: katleman Date: 2013-06-06 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/40da96cab40e Added tag jdk8-b93 for changeset d583a491d63c ! .hgtags From john.coomes at oracle.com Fri Jun 7 01:53:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jun 2013 08:53:08 +0000 Subject: hg: hsx/hotspot-main/nashorn: 44 new changesets Message-ID: <20130607085341.9A2B648076@hg.openjdk.java.net> Changeset: 80d4db063d5a Author: jlaskey Date: 2013-05-14 11:15 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/80d4db063d5a 8014512: Exclude testing and infrastructure packages from code coverage Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/code_coverage.xml Changeset: eeed4db61215 Author: jlaskey Date: 2013-05-14 11:16 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/eeed4db61215 Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - test/script/trusted/logcoverage.js Changeset: fc20983ef38e Author: attila Date: 2013-05-14 19:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fc20983ef38e 8011718: binding already bound function with extra arguments fails Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java + test/script/basic/JDK-8011718.js + test/script/basic/JDK-8011718.js.EXPECTED Changeset: f88a4818a4dc Author: lagergren Date: 2013-05-14 19:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f88a4818a4dc 8014426: Original exception no longer thrown away when a finally rethrows Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8014426.js + test/script/basic/JDK-8014426.js.EXPECTED Changeset: 64ef1aeaeb4e Author: attila Date: 2013-05-15 10:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/64ef1aeaeb4e 8014639: Remove debug flag from test runs Reviewed-by: hannesw, lagergren ! make/project.properties Changeset: b37eb709ae27 Author: attila Date: 2013-05-15 14:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b37eb709ae27 8014646: Update the Java interop documentation in the Java Scripting Programmer's Guide Reviewed-by: jlaskey, hannesw, lagergren ! docs/JavaScriptingProgrammersGuide.html Changeset: 1eaa542cc8e2 Author: sundar Date: 2013-05-15 19:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1eaa542cc8e2 8012305: Function.bind can't be called on prototype function inside constructor Reviewed-by: lagergren, attila + test/script/basic/JDK-8012305.js + test/script/basic/JDK-8012305.js.EXPECTED Changeset: 6344644b81ec Author: jlaskey Date: 2013-05-15 12:09 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6344644b81ec 8014648: Exclude testing and infrastructure packages from code coverage, round two Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/code_coverage.xml ! src/jdk/nashorn/internal/runtime/options/Option.java ! src/jdk/nashorn/internal/runtime/options/Options.java - src/jdk/nashorn/internal/runtime/options/ValueOption.java ! test/script/basic/allgettersetters.js Changeset: 19e9cd9c7010 Author: attila Date: 2013-05-15 20:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/19e9cd9c7010 8014647: Allow class-based overrides to be initialized with a ScriptFunction Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java + test/script/basic/JDK-8014647.js + test/script/basic/JDK-8014647.js.EXPECTED Changeset: ac14a1fb0cab Author: sundar Date: 2013-05-16 14:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ac14a1fb0cab 8009141: Avoid netscape.javascript.JSObject in nashorn code Reviewed-by: lagergren, hannesw + src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java - src/netscape/javascript/JSObject.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 4c67a692ef97 Author: lagergren Date: 2013-05-16 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4c67a692ef97 8013919: Original exception no longer thrown away when a finally rethrows Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/FunctionNode.java + test/script/basic/JDK-8013919.js + test/script/basic/JDK-8013919.js.EXPECTED Changeset: 98798a6336de Author: hannesw Date: 2013-05-16 19:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/98798a6336de 8012359: Increase code coverage in Joni Reviewed-by: jlaskey, lagergren ! make/build.xml - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java + src/jdk/nashorn/internal/runtime/regexp/JdkRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java ! src/jdk/nashorn/internal/runtime/regexp/joni/BitStatus.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Compiler.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/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Region.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Syntax.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java ! src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java ! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/ObjPtr.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java ! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java ! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ValueException.java + test/src/jdk/nashorn/internal/runtime/regexp/JdkRegExpTest.java + test/src/jdk/nashorn/internal/runtime/regexp/joni/JoniTest.java Changeset: aa1b6e8c51a0 Author: jlaskey Date: 2013-05-17 14:30 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/aa1b6e8c51a0 8012694: Smoke test fail: Windows JDK-8008554.js - access denied ("java.io.FilePermission" "//C/aurora/sandbox/nashorn~source/test/script/basic/NASHORN-99.js" "read") Reviewed-by: jlaskey Contributed-by: konstantin.shefov at oracle.com Changeset: a92be4c0063b Author: jlaskey Date: 2013-05-17 16:12 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a92be4c0063b Merge - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java - src/netscape/javascript/JSObject.java Changeset: 1d5a8f1f416e Author: jlaskey Date: 2013-05-17 16:44 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1d5a8f1f416e 8014823: Reprise - Smoke test fail: Windows JDK-8008554.js - access denied ("java.io.FilePermission" "//C/aurora/sandbox/nashorn~source/test/script/basic/NASHORN-99.js" "read") Reviewed-by: jlaskey Contributed-by: konstantin.shefov at oracle.com ! test/script/basic/JDK-8008554.js Changeset: 92164a5742db Author: lagergren Date: 2013-05-20 16:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/92164a5742db 8006069: Range analysis first iteration, runtime specializations Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/RangeAnalyzer.java + src/jdk/nashorn/internal/codegen/types/Range.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/ranges_disabled.js + test/script/basic/ranges_disabled.js.EXPECTED + test/script/basic/ranges_enabled.js + test/script/basic/ranges_enabled.js.EXPECTED + test/script/basic/ranges_payload.js Changeset: b558e19d5de5 Author: sundar Date: 2013-05-20 23:04 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b558e19d5de5 8014909: ant test compilation error with JoniTest.java Reviewed-by: jlaskey ! make/build.xml Changeset: 1fd18f40ab52 Author: attila Date: 2013-05-20 21:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1fd18f40ab52 8014797: rename Java.toJavaArray/toJavaScriptArray to Java.to/from, respectively. Reviewed-by: jlaskey, sundar ! docs/JavaScriptingProgrammersGuide.html ! docs/source/javaarray.js ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/NASHORN-556.js ! test/script/basic/javaarrayconversion.js ! test/script/currently-failing/logcoverage.js ! test/script/trusted/NASHORN-638.js ! test/script/trusted/NASHORN-653.js Changeset: e955e64fd15d Author: lana Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e955e64fd15d Merge Changeset: 833a9a584b64 Author: attila Date: 2013-05-21 13:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/833a9a584b64 8014953: Have NativeJavaPackage throw a ClassNotFoundException when invoked Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + test/script/basic/JDK-8014953.js + test/script/basic/JDK-8014953.js.EXPECTED Changeset: 288ff54da2a5 Author: jlaskey Date: 2013-05-21 10:17 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/288ff54da2a5 8014827: readLine should accept a prompt as an argument Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java Changeset: 07cefc062032 Author: sundar Date: 2013-05-22 16:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/07cefc062032 8008947: ScriptEnvironment ctor should be public Reviewed-by: lagergren, attila ! .hgignore ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java Changeset: 66685c69bdb3 Author: sundar Date: 2013-05-22 19:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/66685c69bdb3 8014735: Typed Array, BYTES_PER_ELEMENT should be a class property Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/ArrayBufferView.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 + test/script/basic/JDK-8014735.js + test/script/basic/JDK-8014735.js.EXPECTED ! test/script/basic/NASHORN-377.js Changeset: 8f7553df4503 Author: hannesw Date: 2013-05-22 16:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8f7553df4503 8010804: Review long and integer usage conventions Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8010804.js + test/script/basic/JDK-8010804.js.EXPECTED Changeset: 1c1453863ea8 Author: attila Date: 2013-05-23 12:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1c1453863ea8 8015267: Allow conversion of JS arrays to Java List/Deque Reviewed-by: lagergren, sundar ! make/build.xml ! src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8015267.js + test/script/basic/JDK-8015267.js.EXPECTED Changeset: f7eb4436410e Author: lagergren Date: 2013-05-23 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f7eb4436410e 8012083: Array literal constant folding issue Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script/basic/JDK-8012083.js + test/script/basic/JDK-8012083.js.EXPECTED Changeset: 704bc91a0c41 Author: attila Date: 2013-05-23 13:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/704bc91a0c41 8015278: Revert accidental changes to build.xml Reviewed-by: jlaskey, lagergren ! make/build.xml Changeset: 8af550dee961 Author: jlaskey Date: 2013-05-23 09:49 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8af550dee961 Merge Changeset: 6fc7b51e83d6 Author: lagergren Date: 2013-05-23 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6fc7b51e83d6 8012522: Clean up lexical contexts - split out stack based functionality in CodeGenerator and generify NodeVisitors based on their LexicalContext type to avoid casts Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CodeGeneratorLexicalContext.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java Changeset: fdfb4edd78d6 Author: hannesw Date: 2013-05-24 13:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fdfb4edd78d6 8011630: JSON parsing performance issue Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java Changeset: 4d2eca4d4d66 Author: sundar Date: 2013-05-24 18:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4d2eca4d4d66 8015354: JSON.parse should not use [[Put]] but use [[DefineOwnProperty]] instead Reviewed-by: lagergren, hannesw ! 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/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/Property.java + test/script/basic/JDK-8015354.js Changeset: 751cfefff5eb Author: sundar Date: 2013-05-24 23:27 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/751cfefff5eb 8015351: Nashorn shell does not start with Turkish locale Reviewed-by: jlaskey ! make/project.properties ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java Changeset: 0bf451c0678d Author: hannesw Date: 2013-05-27 12:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0bf451c0678d 8015348: RegExp("[") results in StackOverflowError Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8015348.js + test/script/basic/JDK-8015348.js.EXPECTED Changeset: 1f57afd14cc1 Author: lagergren Date: 2013-05-27 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1f57afd14cc1 8014219: Make the run-octane harness more deterministic by not measuring elapsed time every iteration. Also got rid of most of the run logic in base.js and call benchmarks directly for the same purpose Reviewed-by: jlaskey, attila ! make/build-benchmark.xml ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js Changeset: 910fd2849c4c Author: lagergren Date: 2013-05-27 13:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/910fd2849c4c Merge Changeset: 343fd0450802 Author: sundar Date: 2013-05-27 20:41 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/343fd0450802 8015352: "i".toUpperCase() => currently returns "??", but should be "I" (with Turkish locale) Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8015352.js Changeset: e6193dcfe36c Author: lagergren Date: 2013-05-27 17:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e6193dcfe36c 8015447: Octane harness fixes for rhino and entire test runs: ant octane, ant octane-v8, ant octane-rhino Reviewed-by: sundar, jlaskey ! make/build-benchmark.xml ! test/script/basic/run-octane.js Changeset: d56168970de1 Author: sundar Date: 2013-05-28 16:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d56168970de1 8015459: Octane test run fails on Turkish locale Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java Changeset: f472f7046ec9 Author: sundar Date: 2013-05-29 15:41 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f472f7046ec9 8005979: A lot of tests are named "runTest" in reports Reviewed-by: jlaskey ! make/project.properties Changeset: f69e76417211 Author: lagergren Date: 2013-05-29 14:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f69e76417211 8011023: Math round didn't conform to ECMAScript 5 spec Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/objects/NativeMath.java + test/script/basic/JDK-8011023.js + test/script/basic/JDK-8011023.js.EXPECTED Changeset: a2e2797392b3 Author: sundar Date: 2013-05-29 21:27 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a2e2797392b3 8015349: "abc".lastIndexOf("a",-1) should evaluate to 0 and not -1 Reviewed-by: lagergren, attila, jlaskey ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/JDK-8015349.js + test/script/basic/JDK-8015349.js.EXPECTED Changeset: 4463e94d9b0d Author: lana Date: 2013-05-29 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4463e94d9b0d Merge - src/jdk/nashorn/internal/runtime/options/ValueOption.java - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java - src/netscape/javascript/JSObject.java Changeset: ddbf41575a2b Author: lana Date: 2013-06-03 23:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ddbf41575a2b Merge - src/jdk/nashorn/internal/runtime/options/ValueOption.java - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java - src/netscape/javascript/JSObject.java Changeset: e857ab684db0 Author: cl Date: 2013-06-06 20:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e857ab684db0 Added tag jdk8-b93 for changeset ddbf41575a2b ! .hgtags From aleksey.shipilev at oracle.com Fri Jun 7 03:01:16 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 07 Jun 2013 14:01:16 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability Message-ID: <51B1AF6C.5030708@oracle.com> (posting this to hotspot-dev@ and cc-ing core-libs-dev@, as Christian T. suggested offline) Hi guys, The fix for scalability problem is here: http://cr.openjdk.java.net/~shade/7177472/webrev.00/ Testing: - Linux x86_64 builds OK - Linux x86_64 java/lang/invoke/ jtreg passes OK Since this is a proof-of-concept patch at this point, I kept the testing minimal. Let me know what other testing you think is needed before the integration. Thanks, Aleksey. *** Rationale and details for the issue follow: *** This issue was in limbo for an year. The performance issue with MethodType.methodType factory leads to abysmal scalability on the targeted tests. While this can arguably demonstrated on larger workloads, the targeted microbenchmarks are showcasing it nicely. This issue was blocking the JSR292 API performance testing, because on large enough test server, you will inevitably be bitten by this. If you run the JMH-enabled [1] microbenchmark: http://openjdk.java.net/projects/code-tools/jmh/ http://cr.openjdk.java.net/~shade/7177472/jsr292bench.tar.gz ...on the current jdk8/jdk8, 2x2 i5 2.0 Ghz, Linux x86_64, you will see the scalability is going down. ("testCached" makes sure the reference to MethodType is always strongly reachable, "testNew" makes sure the reference is mostly non-reachable, prompting cache re-fill, "testOOB" does not make any precautions about that, and also does not suffer from the static overheads entailed by the reference management in first two tests). 1 thread: MethodTypeBench.testCached 78 +- 1 nsec/op MethodTypeBench.testNew 120 +- 1 nsec/op MethodTypeBench.testOOB 41 +- 1 nsec/op 4 threads: MethodTypeBench.testCached 495 +- 40 nsec/op MethodTypeBench.testNew 611 +- 37 nsec/op MethodTypeBench.testOOB 377 +- 10 nsec/op In fact, on larger machines it may be as bad as tens/hundreds of microseconds to look up the MethodType. With the patch applied, on the same 2x2 machine: 1 thread: MethodTypeBench.testCached 92 +- 1 nsec/op MethodTypeBench.testNew 101 +- 1 nsec/op MethodTypeBench.testOOB 49 +- 1 nsec/op 4 threads: MethodTypeBench.testCached 129 +- 1 nsec/op MethodTypeBench.testNew 142 +- 10 nsec/op MethodTypeBench.testOOB 89 +- 3 nsec/op ...which means the scalability is back: the average time to look up the MethodType is not growing spectacularly when the thread count go up. Again, the effect is astonishing on large machines. Notice that we took some hit in single-threaded performance, and that is due to two reasons: a) WeakEntry allocation in get(); b) CHM. With the upcoming CHMv8, this starts to look better: 1 thread: MethodTypeBench.testCached 87 +- 1 nsec/op MethodTypeBench.testNew 95 +- 1 nsec/op MethodTypeBench.testOOB 52 +- 1 nsec/op 4 threads: MethodTypeBench.testCached 121 +- 2 nsec/op MethodTypeBench.testNew 141 +- 1 nsec/op MethodTypeBench.testOOB 93 +- 5 nsec/op ...which seems to indicate this change is future-proof. From alejandro.murillo at oracle.com Fri Jun 7 12:50:10 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 07 Jun 2013 19:50:10 +0000 Subject: hg: hsx/hsx25/hotspot: 36 new changesets Message-ID: <20130607195124.41DCC480B0@hg.openjdk.java.net> Changeset: 61dcf187a198 Author: katleman Date: 2013-06-06 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/61dcf187a198 Added tag jdk8-b93 for changeset 573d86d412cd ! .hgtags Changeset: b7569f617285 Author: amurillo Date: 2013-05-31 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b7569f617285 8015690: new hotspot build - hs25-b36 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5534bd30c151 Author: jcoomes Date: 2013-05-30 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5534bd30c151 6725714: par compact - add a table to speed up bitmap searches Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 47bdfb3d010f Author: stefank Date: 2013-05-30 10:58 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/47bdfb3d010f 8015486: PSScavenge::is_obj_in_young is unnecessarily slow with UseCompressedOops Summary: Compare compressed oops to a compressed young gen boundary instead of uncompressing the oops before doing the young gen boundary check. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp Changeset: c20186fa611b Author: jwilhelm Date: 2013-06-01 10:00 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c20186fa611b Merge Changeset: e72f7eecc96d Author: tschatzl Date: 2013-05-28 09:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e72f7eecc96d 8013895: G1: G1SummarizeRSetStats output on Linux needs improvemen Summary: Fixed the output of G1SummarizeRSetStats: too small datatype for the number of concurrently processed cards, added concurrent remembered set thread time retrieval for Linux and Windows (BSD uses os::elapsedTime() now), and other cleanup. The information presented during VM operation is now relative to the previous output, not always cumulative if G1SummarizeRSetStatsPeriod > 0. At VM exit, the code prints a cumulative summary. Reviewed-by: johnc, jwilhelm ! make/excludeSrc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! 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/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStats.java Changeset: 3a4805ad0005 Author: johnc Date: 2013-06-04 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a4805ad0005 8015244: G1: Verification after a full GC is incorrectly placed. Summary: In a full GC, move the verification after the GC to after RSet rebuilding. Verify RSet entries during a full GC under control of a flag. Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 87c64c0438fb Author: tamao Date: 2013-06-03 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/87c64c0438fb 6976350: G1: deal with fragmentation while copying objects during GC Summary: Create G1ParGCAllocBufferContainer to contain two buffers instead of previously using one buffer, in order to hold the first priority buffer longer. Thus, when some large objects hits the value of free space left in the first priority buffer it has an alternative to fit in the second priority buffer while the first priority buffer is given more chances to try allocating smaller objects. Overall, it will improve heap space efficiency. Reviewed-by: johnc, jmasa, brutisso Contributed-by: tamao ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp Changeset: 2f7a31318b84 Author: johnc Date: 2013-06-04 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2f7a31318b84 Merge Changeset: a1ebd310d5c1 Author: iklam Date: 2013-05-28 16:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a1ebd310d5c1 8014912: Restore PrintSharedSpaces functionality after NPG Summary: Added dumping of object sizes in CDS archive, sorted by MetaspaceObj::Type Reviewed-by: coleenp, acorn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodCounters.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/utilities/array.hpp Changeset: fe00365c8f31 Author: sspitsyn Date: 2013-05-30 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fe00365c8f31 8015436: compiler/ciReplay/TestSA.sh fails with assert() index is out of bounds Summary: The InstanceKlass _initial_method_idnum value must be adjusted if overpass methods are added. Reviewed-by: twisti, kvn Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/classfile/defaultMethods.cpp + test/compiler/8015436/Test8015436.java Changeset: a589c78a8811 Author: rbackman Date: 2013-05-31 13:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a589c78a8811 8014709: Constructor.getAnnotatedReturnType() returns empty AnnotatedType Reviewed-by: stefank, rbackman Contributed-by: Joel Borggren-Franck ! src/share/vm/runtime/reflection.cpp ! test/runtime/8007320/ConstMethodTest.java Changeset: efe8b7d64424 Author: ctornqvi Date: 2013-05-31 20:24 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/efe8b7d64424 6726963: multi_allocate() call does not CHECK_NULL and causes crash in fastdebug bits Summary: Using CHECK_NULL when calling multi_allocate() from the corresponding reflection code; added test for this condition Reviewed-by: dholmes, minqi Contributed-by: Mikhailo Seledtsov ! src/share/vm/runtime/reflection.cpp + test/runtime/memory/MultiAllocateNullCheck.java Changeset: 532c55335fb6 Author: dcubed Date: 2013-06-01 09:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/532c55335fb6 Merge Changeset: 4552a7633a07 Author: hseigel Date: 2013-06-03 10:00 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4552a7633a07 8015385: Remove RelaxAccessControlCheck for JDK 8 bytecodes Summary: Check bytecode versions along with RelaxAccessControlCheck version Reviewed-by: dholmes, acorn ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/reflection.cpp Changeset: e7d29a019a3c Author: sspitsyn Date: 2013-06-03 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e7d29a019a3c 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending Summary: A call to the finalize_operands_merge() must be unconditional Reviewed-by: kvn, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 2f004f9dc9e1 Author: sspitsyn Date: 2013-06-04 01:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2f004f9dc9e1 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' Summary: Newly added test has an issue: the main class must be public Reviewed-by: kvn, jbachorik, coleenp Contributed-by: serguei.spitsyn at oracle.com ! test/compiler/8015436/Test8015436.java Changeset: 04551f4dbdb9 Author: nloodin Date: 2013-06-05 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/04551f4dbdb9 Merge Changeset: 62e7bac9524f Author: dcubed Date: 2013-06-04 19:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/62e7bac9524f 8010257: remove unused thread-local variables _ScratchA and _ScratchB Summary: Remove dead code. Reviewed-by: twisti, coleenp ! src/share/vm/runtime/thread.hpp Changeset: 6bf8b8bb7c19 Author: hseigel Date: 2013-06-05 14:12 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6bf8b8bb7c19 8009302: Mac OS X: JVM crash on infinite recursion on Appkit Thread Summary: Use SA_ONSTACK flag to ensure signal gets delivered properly. Reviewed-by: dholmes, coleenp Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: f8c8cace25ad Author: dcubed Date: 2013-06-06 05:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f8c8cace25ad Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 320b4e0f0892 Author: roland Date: 2013-05-30 11:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/320b4e0f0892 8015585: Missing regression test for 8011771 Summary: missing regression test Reviewed-by: kvn + test/compiler/8011771/Test8011771.java Changeset: f15fe46d8c00 Author: twisti Date: 2013-05-30 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f15fe46d8c00 8015266: fix some -Wsign-compare warnings in adlc Reviewed-by: kvn ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp Changeset: 28e5aed7f3a6 Author: roland Date: 2013-05-31 14:40 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/28e5aed7f3a6 8009981: nashorn tests fail with -XX:+VerifyStack Summary: nmethod::preserve_callee_argument_oops() must take appendix into account. Reviewed-by: kvn, twisti ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 83dcb116fdb1 Author: kvn Date: 2013-05-31 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/83dcb116fdb1 8015441: runThese crashed with assert(opcode == Op_ConP || opcode == Op_ThreadLocal || opcode == Op_CastX2P ..) failed: sanity Summary: Relax the assert to accept any raw ptr types. Reviewed-by: roland ! src/share/vm/opto/escape.cpp Changeset: c07dd9be16e8 Author: anoll Date: 2013-05-31 06:41 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c07dd9be16e8 8013496: Code cache management command line options work only in special order. Another order of arguments does not deliver the second parameter to the jvm. Summary: Moved check that ReservedCodeCacheSize >= InitialCodeCacheSize to Arguments::check_vm_args_consistency(). As a result, the ordering in which the two parameters are given to the VM is not relevant. Added a regression test. Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/8013496/Test8013496.sh Changeset: 603ca7e51354 Author: roland Date: 2013-04-24 11:49 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/603ca7e51354 8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292 Summary: ConstMethod::max_stack() doesn't account for JSR 292 appendix. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/matcher.cpp Changeset: 813f26e34135 Author: anoll Date: 2013-06-03 08:52 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/813f26e34135 8013329: File leak in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: Added calling of the destructor of CompileLog so that files are closed. Added/moved memory allocation/deallocation of the string that contains the name of the log file to class CompileLog. Reviewed-by: kvn, roland ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp Changeset: b274ac1dbe11 Author: adlertz Date: 2013-06-03 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b274ac1dbe11 8005956: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Summary: Disable re-materialization of reaching definitions (which have live inputs) for phi nodes when spilling. Reviewed-by: twisti, kvn ! src/share/vm/opto/reg_split.cpp Changeset: 770e91e578a6 Author: kvn Date: 2013-06-03 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/770e91e578a6 Merge Changeset: 075ea888b039 Author: morris Date: 2013-06-04 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/075ea888b039 8010724: [parfait] Null pointer dereference in hotspot/src/share/vm/c1/c1_LIRGenerator.cpp Summary: added guarantee() Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 2cb5d5f6d5e5 Author: simonis Date: 2013-06-04 22:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2cb5d5f6d5e5 8015252: Enable HotSpot build with Clang Reviewed-by: twisti, dholmes, kvn ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 609aad72004a Author: anoll Date: 2013-06-06 09:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/609aad72004a 8014246: remove assert to catch access to object headers in index_oop_from_field_offset_long Reviewed-by: twisti, jrose ! src/share/vm/prims/unsafe.cpp Changeset: ef1818846c22 Author: kvn Date: 2013-06-06 11:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ef1818846c22 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 3c78a14da19d Author: amurillo Date: 2013-06-07 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3c78a14da19d Merge ! .hgtags Changeset: 1beed1f6f9ed Author: amurillo Date: 2013-06-07 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1beed1f6f9ed Added tag hs25-b36 for changeset 3c78a14da19d ! .hgtags From mark at talios.com Fri Jun 7 16:07:56 2013 From: mark at talios.com (Mark Derricutt) Date: Sat, 08 Jun 2013 11:07:56 +1200 Subject: Class verifier issues with unboxing method handles In-Reply-To: <51A5E59F.9040007@oracle.com> References: <51A5543B.10506@talios.com> <51A55E5E.4020605@oracle.com> <51A5E59F.9040007@oracle.com> Message-ID: <51B267CC.8000303@talios.com> Maurizio / David / others... Does anyone know if anything has come of this? I don't see any further posts on this thread on either hotspot-dev or lambda-dev. Thanks, Mark Maurizio Cimadamore wrote: > > David, Mark, > a minimal test case to reproduce the issue is this: > > interface IntFunction { > int m(X x); > } > > class Test { > public static void main(String[] args) { > IntFunction s = Integer::new; > } > } > > > Looking at the javap output, in particular at the indy call details, > we find this: > > BootstrapMethods: > 0: #15 invokestatic > java/lang/invoke/LambdaMetafactory.metaFactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > > > Method arguments: > #16 invokeinterface IntFunction.m:(Ljava/lang/Object;)I > #17 newinvokespecial java/lang/Integer."":(Ljava/lang/String;)V > #18 (Ljava/lang/String;)I > > > This seems correct; however, judging from the runtime error, it seems > like the metafactory is not unboxing the Integer instance back to int > (which is the expected return value of the implemented method). Hence > the 292 link failure. Robert, Brian can you confirm? > > Maurizio > > > On 29/05/13 02:48, David Holmes wrote: >> >> Hi Mark, >> >> cc'ing lambda-dev. This may be a bug, a version mismatch, or something >> else. The lambda-dev folk will know. >> >> David >> >> On 29/05/2013 11:04 AM, Mark Derricutt wrote: >>> >>> Hi all, >>> >>> Mark Reinhold suggested I posted this question/bug report to >>> hotspot-dev >>> rather than jdk8-dev so here goes. >>> >>> I have a fairly simple test case using the new streams API: >>> >>> public static void main(String[] args) { >>> List strings = Arrays.asList("1", "2", "3", "4", "5"); >>> strings.stream() >>> .mapToInt(s -> new Integer(s)) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> } >>> >>> >>> which compiles, runs, and prints out what I expect: >>> >>> int 1 >>> int 2 >>> int 3 >>> int 4 >>> int 5 >>> >>> >>> Given that mapToInt() is returning an IntegerStream wrapping primitive >>> ints, the result of my closure is successfully autoboxed down to an int >>> and all is happy with the world. >>> >>> If I change this code to be: >>> >>> strings.stream() >>> .mapToInt(Integer::parseInt) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> >>> Again, everything works as expected as Integer::parseInt returns an >>> int, >>> so there's no boxing. >>> >>> Changing this once again to: >>> >>> strings.stream() >>> .mapToInt(Integer::valueOf) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> >>> I also see the expected result, Integer::valueOf returns an Integer >>> which is then being boxed down to an int. >>> >>> However, if I change the code to: >>> >>> strings.stream() >>> .mapToInt(Integer::new) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> >>> which, if I understand correctly - Integer::new should be returning a >>> method handle to the constructor. IntelliJ IDEA 13 autocompletes this >>> for me, and hyperlinks to the Integer(String s) constructor, javac >>> successfully compiles the code so my -assumption- is that the >>> constructor would be called, returning an Integer which is then boxed >>> down to an int, however, this is what I get: >>> >>> Exception in thread "main" java.lang.BootstrapMethodError: call site >>> initialization exception >>> at java.lang.invoke.CallSite.makeSite(CallSite.java:298) >>> at >>> java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:294) >>> >>> >>> >>> at com.talios.test.TestJdk.main(TestJdk.java:12) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> >>> >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> >>> >>> at java.lang.reflect.Method.invoke(Method.java:491) >>> at >>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >>> Caused by: java.lang.VerifyError: Bad type on operand stack >>> Exception Details: >>> Location: >>> com/talios/test/TestJdk$$Lambda$1.applyAsInt(Ljava/lang/Object;)I >>> @11: ireturn >>> Reason: >>> Type 'java/lang/Integer' (current frame, stack[0]) is not >>> assignable to integer >>> Current Frame: >>> bci: @11 >>> flags: { } >>> locals: { 'com/talios/test/TestJdk$$Lambda$1', 'java/lang/Object' } >>> stack: { 'java/lang/Integer' } >>> Bytecode: >>> 0000000: bb00 0e59 2bc0 0010 b700 13ac >>> >>> at java.lang.Class.getDeclaredConstructors0(Native Method) >>> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2536) >>> at java.lang.Class.getDeclaredConstructors(Class.java:1928) >>> at >>> java.lang.invoke.InnerClassLambdaMetafactory$1.run(InnerClassLambdaMetafactory.java:147) >>> >>> >>> >>> at >>> java.lang.invoke.InnerClassLambdaMetafactory$1.run(InnerClassLambdaMetafactory.java:144) >>> >>> >>> >>> at java.security.AccessController.doPrivileged(Native Method) >>> at >>> java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite(InnerClassLambdaMetafactory.java:143) >>> >>> >>> >>> at >>> java.lang.invoke.LambdaMetafactory.metaFactory(LambdaMetafactory.java:191) >>> >>> >>> at java.lang.invoke.CallSite.makeSite(CallSite.java:283) >>> ... 7 more >>> >>> This is on OSX Mountain Lion, with JDK 8 Build 91. >>> >>> Have I walked in an obscure corner case of method handle breakage and >>> found something new, or is this a new problem? >>> >>> Cheers, >>> Mark >>> >> > From alejandro.murillo at oracle.com Fri Jun 7 16:47:19 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 07 Jun 2013 23:47:19 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130607234730.15639480B7@hg.openjdk.java.net> Changeset: 61dcf187a198 Author: katleman Date: 2013-06-06 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/61dcf187a198 Added tag jdk8-b93 for changeset 573d86d412cd ! .hgtags Changeset: 3c78a14da19d Author: amurillo Date: 2013-06-07 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c78a14da19d Merge ! .hgtags Changeset: 1beed1f6f9ed Author: amurillo Date: 2013-06-07 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1beed1f6f9ed Added tag hs25-b36 for changeset 3c78a14da19d ! .hgtags Changeset: d0add7016434 Author: amurillo Date: 2013-06-07 09:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d0add7016434 8016078: new hotspot build - hs25-b37 Reviewed-by: jcoomes ! make/hotspot_version From john.cuthbertson at oracle.com Fri Jun 7 20:38:16 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Sat, 08 Jun 2013 03:38:16 +0000 Subject: hg: hsx/hsx24/hotspot: 7186737: Unable to allocate bit maps or card tables for parallel gc for the requested heap Message-ID: <20130608033819.ECC7F480BE@hg.openjdk.java.net> Changeset: 79d6da9207c8 Author: tamao Date: 2013-06-06 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/79d6da9207c8 7186737: Unable to allocate bit maps or card tables for parallel gc for the requested heap Summary: Print helpful error message when VM aborts due to inability of allocating bit maps or card tables Reviewed-by: jmasa, stefank Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp From aleksey.shipilev at oracle.com Sat Jun 8 04:21:28 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 08 Jun 2013 15:21:28 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B3059A.4030703@univ-mlv.fr> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> Message-ID: <51B313B8.1060309@oracle.com> (copying hotspot-dev@ back, the patch is theirs) Thanks Remi! On 06/08/2013 02:21 PM, Remi Forax wrote: > in add, the do/while does something a little weird, if putIfAbsent > returns null, interned is equals to elem, there is no need to do a > e.get() in that case, Oh yes, that a nice micro-optimization, relying on the fact $elem is still strongly reachable. > The cast to WeakEntry in expungeStaleElements is not needed. Yup. > In WeakEntry.equals, the null check is not needed because null > instanceof WeakEntry returns false, and you don't need to cast > obj.get() to a WeakEntry given you only to call equals on > entry.get(). Yup, thanks for the nit-picking this. > Otherwise, it looks good. I had also renamed the class to ConcurrentWeakInternSet, to emphasize it should do interning, not only the caching. The new webrev is here: http://cr.openjdk.java.net/~shade/7177472/webrev.01/ Testing: - Linux x86_64 builds OK - Linux x86_64 java/lang/invoke/ jtreg passes OK - The microbenchmark scores in the original note are still in effect. -Aleksey. From markus.gronlund at oracle.com Mon Jun 10 02:46:19 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 10 Jun 2013 02:46:19 -0700 (PDT) Subject: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp In-Reply-To: <7016df98-0b5a-48fe-83c4-46bbd5e7c874@default> References: <1a584728-48fd-4640-926d-e0b70be7e4e3@default> <08EB6131-7607-4419-B7B5-12715B7340F0@oracle.com> <7016df98-0b5a-48fe-83c4-46bbd5e7c874@default> Message-ID: Updated webrev with REALLOC_C_HEAP_ARRAY2 removed: http://cr.openjdk.java.net/~mgronlun/8016105/webrev02/ Thanks to reviewing Markus -----Original Message----- From: Markus Gr?nlund Sent: den 10 juni 2013 11:15 To: Staffan Larsen Cc: hotspot-dev at openjdk.java.net Developers Subject: RE: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp Thanks Staffan, Thanks for spotting - it can be removed. Thanks Markus -----Original Message----- From: Staffan Larsen Sent: den 10 juni 2013 11:06 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Developers Subject: Re: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp Looks good, but do we need REALLOC_C_HEAP_ARRAY2()? It is never used and does not seem to add anything compared to REALLOC_C_HEAP_ARRAY / REALLOC_C_HEAP_ARRAY_RETURN_NULL. /Staffan On 7 jun 2013, at 09:07, Markus Gr?nlund wrote: > Greetings, > > > > Kindly asking for reviews for the following: > > > > Bug id: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016105 > > > > Webrev: http://cr.openjdk.java.net/~mgronlun/8016105/webrev01/ > > > > > > Thank you > > Markus From aleksey.shipilev at oracle.com Mon Jun 10 08:47:37 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 10 Jun 2013 19:47:37 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B39158.5000003@gmail.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> Message-ID: <51B5F519.6030307@oracle.com> On 06/09/2013 12:17 AM, Peter Levart wrote: > In case the loop retries, there's no need to construct another WeakEntry... > > T interned; > WeakEntry e = new WeakEntry<>(elem, stale); > do { > expungeStaleElements(); > WeakEntry exist = map.putIfAbsent(e, e); > interned = (exist == null)? elem: exist.get(); > } while (interned == null); > return interned; That's right, thanks! The update is here: http://cr.openjdk.java.net/~shade/7177472/webrev.02/ Testing: - Linux x86_64 builds OK - Linux x86_64 java/lang/invoke/ jtreg passes OK - The microbenchmark scores in the original note are still the same -Aleksey. From staffan.larsen at oracle.com Mon Jun 10 02:56:16 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 10 Jun 2013 11:56:16 +0200 Subject: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp In-Reply-To: References: <1a584728-48fd-4640-926d-e0b70be7e4e3@default> <08EB6131-7607-4419-B7B5-12715B7340F0@oracle.com> <7016df98-0b5a-48fe-83c4-46bbd5e7c874@default> Message-ID: <96543C7F-FD5A-42EF-A6B5-ED89092ABBAD@oracle.com> Looks good. /Staffan On 10 jun 2013, at 11:46, Markus Gr?nlund wrote: > Updated webrev with REALLOC_C_HEAP_ARRAY2 removed: > > http://cr.openjdk.java.net/~mgronlun/8016105/webrev02/ > > > Thanks to reviewing > > Markus > > -----Original Message----- > From: Markus Gr?nlund > Sent: den 10 juni 2013 11:15 > To: Staffan Larsen > Cc: hotspot-dev at openjdk.java.net Developers > Subject: RE: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp > > Thanks Staffan, > > Thanks for spotting - it can be removed. > > Thanks > Markus > > -----Original Message----- > From: Staffan Larsen > Sent: den 10 juni 2013 11:06 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net Developers > Subject: Re: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp > > Looks good, but do we need REALLOC_C_HEAP_ARRAY2()? It is never used and does not seem to add anything compared to REALLOC_C_HEAP_ARRAY / REALLOC_C_HEAP_ARRAY_RETURN_NULL. > > /Staffan > > On 7 jun 2013, at 09:07, Markus Gr?nlund wrote: > >> Greetings, >> >> >> >> Kindly asking for reviews for the following: >> >> >> >> Bug id: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016105 >> >> >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8016105/webrev01/ >> >> >> >> >> >> Thank you >> >> Markus > From markus.gronlund at oracle.com Mon Jun 10 02:14:36 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 10 Jun 2013 02:14:36 -0700 (PDT) Subject: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp In-Reply-To: <08EB6131-7607-4419-B7B5-12715B7340F0@oracle.com> References: <1a584728-48fd-4640-926d-e0b70be7e4e3@default> <08EB6131-7607-4419-B7B5-12715B7340F0@oracle.com> Message-ID: <7016df98-0b5a-48fe-83c4-46bbd5e7c874@default> Thanks Staffan, Thanks for spotting - it can be removed. Thanks Markus -----Original Message----- From: Staffan Larsen Sent: den 10 juni 2013 11:06 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Developers Subject: Re: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp Looks good, but do we need REALLOC_C_HEAP_ARRAY2()? It is never used and does not seem to add anything compared to REALLOC_C_HEAP_ARRAY / REALLOC_C_HEAP_ARRAY_RETURN_NULL. /Staffan On 7 jun 2013, at 09:07, Markus Gr?nlund wrote: > Greetings, > > > > Kindly asking for reviews for the following: > > > > Bug id: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016105 > > > > Webrev: http://cr.openjdk.java.net/~mgronlun/8016105/webrev01/ > > > > > > Thank you > > Markus From staffan.larsen at oracle.com Mon Jun 10 02:05:41 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 10 Jun 2013 11:05:41 +0200 Subject: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp In-Reply-To: <1a584728-48fd-4640-926d-e0b70be7e4e3@default> References: <1a584728-48fd-4640-926d-e0b70be7e4e3@default> Message-ID: <08EB6131-7607-4419-B7B5-12715B7340F0@oracle.com> Looks good, but do we need REALLOC_C_HEAP_ARRAY2()? It is never used and does not seem to add anything compared to REALLOC_C_HEAP_ARRAY / REALLOC_C_HEAP_ARRAY_RETURN_NULL. /Staffan On 7 jun 2013, at 09:07, Markus Gr?nlund wrote: > Greetings, > > > > Kindly asking for reviews for the following: > > > > Bug id: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016105 > > > > Webrev: http://cr.openjdk.java.net/~mgronlun/8016105/webrev01/ > > > > > > Thank you > > Markus From xiaoran at x1a0ran.com Sat Jun 8 13:06:55 2013 From: xiaoran at x1a0ran.com (Xiaoran Wang) Date: Sat, 8 Jun 2013 13:06:55 -0700 Subject: NoClassDef error when trying to preload additional class in systemDirectory::initialize_preloaded_classes() In-Reply-To: References: Message-ID: To followup, I tried to put foo/bar.class into $JAVA_HOME/jre/classes, now the linux_amd64_compiler2/product/test_gamma passed without error, but another error occured from linux_amd64_compiler2/jvmg/test_gamma, which is even more confusing. cd linux_amd64_compiler2/jvmg && ./test_gamma java full version "1.6.0_22-b04" Using java runtime at: /home/Documents/tools/hotspot-working-dir/java/jre Error occurred during initialization of VM java.lang.NoSuchMethodException: java.lang.reflect.Method.invoke Can someone shed some light please? On Sat, Jun 8, 2013 at 12:32 PM, Xiaoran Wang wrote: > Hi all, > > I'm instrumenting the hotspot JVM for research purposes and one of the > steps is to preload some classes during JVM startup time so that I can use > its KlassOop/KlassHandle later in the template Interpreter. > > I appended the new classes I wanted to load in systemDirectory.hpp, e.g. > *template(bar_klass, foo_bar, Pre) \* > And its corresponding symbol in vmSymbols.hpp > *template(foo_bar, "foo/bar")\* > > Then I put foo/bar.class into the corresponding rt.jar that will be used > to build libjvm.so. > > However, when I built it, the "gamma" test always gives me an > NoClassDefFoundError. > > cd linux_amd64_compiler2/product && ./test_gamma > java full version "1.6.0_22-b04" > Using java runtime at: /home/Documents/tools/hotspot-working-dir/java/jre > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: foo/bar > > > So my question is where should I put my custom class so that it can be > preloaded during JVM startup in > systemDirectory::initialize_preloaded_classes? > > btw, I verified the rt.jar is the one JVM is loading because I tried to > remove java/lang/Object from it and it complained about missing that class > as well. > > Thank you > Xiaoran > From John.Coomes at oracle.com Mon Jun 10 09:59:19 2013 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 10 Jun 2013 09:59:19 -0700 Subject: CFV: New hsx Committer: Tao Mao Message-ID: <20918.1511.548877.879954@oracle.com> I hereby nominate Tao Mao to hsx Committer. Tao is a member of the HotSpot garbage collection team at Oracle and has contributed 13 changesets to date, which have improved or fixed bugs in various GC components including ergonomics, G1 and serial gc. Ten of the changesets can be seen at [1]. Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. Only current hsx Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [4]. John Coomes, hsx Project Lead [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 [3] http://openjdk.java.net/census/#hsx [4] http://openjdk.java.net/projects/#committer-vote From daniel.daugherty at oracle.com Mon Jun 10 10:12:03 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 10 Jun 2013 11:12:03 -0600 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51B608E3.9000302@oracle.com> Vote: yes Dan On 6/10/13 10:59 AM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From jon.masamitsu at oracle.com Mon Jun 10 11:10:20 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 10 Jun 2013 11:10:20 -0700 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51B6168C.70905@oracle.com> Vote: yes On 6/10/13 9:59 AM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From serguei.spitsyn at oracle.com Mon Jun 10 11:33:55 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 10 Jun 2013 11:33:55 -0700 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51B61C13.1010205@oracle.com> Vote: yes Thanks, Serguei On 6/10/13 9:59 AM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From vladimir.kozlov at oracle.com Mon Jun 10 12:05:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Jun 2013 12:05:08 -0700 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51B62364.6050308@oracle.com> Vote: yes Vladimir On 6/10/13 9:59 AM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote > From zhengyu.gu at oracle.com Mon Jun 10 12:06:23 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Mon, 10 Jun 2013 19:06:23 +0000 Subject: hg: hsx/hsx24/hotspot: 8013917: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Message-ID: <20130610190629.193CA48103@hg.openjdk.java.net> Changeset: 643da9d13379 Author: zgu Date: 2013-06-10 10:45 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/643da9d13379 8013917: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Simple fix when memory allocation site is gone, NMT should report 0 memory size, instead old memory size. Reviewed-by: dcubed, ctornqvi ! src/share/vm/services/memReporter.cpp + test/runtime/NMT/JcmdDiffCallsite.java From vladimir.x.ivanov at oracle.com Mon Jun 10 13:06:13 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 11 Jun 2013 00:06:13 +0400 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51B631B5.5000902@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 6/10/13 8:59 PM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote > From christian.thalinger at oracle.com Mon Jun 10 15:52:21 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 10 Jun 2013 15:52:21 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B5F519.6030307@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> Message-ID: <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> On Jun 10, 2013, at 8:47 AM, Aleksey Shipilev wrote: > On 06/09/2013 12:17 AM, Peter Levart wrote: >> In case the loop retries, there's no need to construct another WeakEntry... >> >> T interned; >> WeakEntry e = new WeakEntry<>(elem, stale); >> do { >> expungeStaleElements(); >> WeakEntry exist = map.putIfAbsent(e, e); >> interned = (exist == null)? elem: exist.get(); >> } while (interned == null); >> return interned; > > That's right, thanks! > > The update is here: > http://cr.openjdk.java.net/~shade/7177472/webrev.02/ > > Testing: > - Linux x86_64 builds OK > - Linux x86_64 java/lang/invoke/ jtreg passes OK > - The microbenchmark scores in the original note are still the same This looks good to me. One thing I mentioned in the bug report is that V8's RegExp shows some MethodType related methods in a -Xprof run: Compiled + native Method 11.9% 2455 + 0 java.util.regex.Pattern$GroupTail.match 11.5% 2382 + 0 java.util.regex.Pattern$Start.match 10.2% 2110 + 0 java.util.regex.Pattern$5.isSatisfiedBy 8.5% 1765 + 0 java.util.regex.Pattern$Branch.match 7.1% 1461 + 0 java.lang.invoke.MethodType$WeakInternSet.get 3.4% 709 + 0 java.util.regex.Pattern$CharProperty.match 2.9% 597 + 1 java.lang.invoke.MethodType.makeImpl Could you run RegExp with Nashorn again with and without your changes? -- Chris > > -Aleksey. > From david.holmes at oracle.com Mon Jun 10 23:09:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Jun 2013 16:09:41 +1000 Subject: NoClassDef error when trying to preload additional class in systemDirectory::initialize_preloaded_classes() In-Reply-To: References: Message-ID: <51B6BF25.2050409@oracle.com> What version of hotspot are you building? If it is current sources then you will need a JDK7 import JDK or even JDK8. You can't take current hotspot and place into a 6u JDK for example. David On 9/06/2013 6:06 AM, Xiaoran Wang wrote: > To followup, I tried to put foo/bar.class into $JAVA_HOME/jre/classes, now > the linux_amd64_compiler2/product/test_gamma passed without error, but > another error occured from linux_amd64_compiler2/jvmg/test_gamma, which is > even more confusing. > > cd linux_amd64_compiler2/jvmg && ./test_gamma > java full version "1.6.0_22-b04" > Using java runtime at: /home/Documents/tools/hotspot-working-dir/java/jre > Error occurred during initialization of VM > java.lang.NoSuchMethodException: java.lang.reflect.Method.invoke > > > Can someone shed some light please? > > > On Sat, Jun 8, 2013 at 12:32 PM, Xiaoran Wang wrote: > >> Hi all, >> >> I'm instrumenting the hotspot JVM for research purposes and one of the >> steps is to preload some classes during JVM startup time so that I can use >> its KlassOop/KlassHandle later in the template Interpreter. >> >> I appended the new classes I wanted to load in systemDirectory.hpp, e.g. >> *template(bar_klass, foo_bar, Pre) \* >> And its corresponding symbol in vmSymbols.hpp >> *template(foo_bar, "foo/bar")\* >> >> Then I put foo/bar.class into the corresponding rt.jar that will be used >> to build libjvm.so. >> >> However, when I built it, the "gamma" test always gives me an >> NoClassDefFoundError. >> >> cd linux_amd64_compiler2/product && ./test_gamma >> java full version "1.6.0_22-b04" >> Using java runtime at: /home/Documents/tools/hotspot-working-dir/java/jre >> Error occurred during initialization of VM >> java/lang/NoClassDefFoundError: foo/bar >> >> >> So my question is where should I put my custom class so that it can be >> preloaded during JVM startup in >> systemDirectory::initialize_preloaded_classes? >> >> btw, I verified the rt.jar is the one JVM is loading because I tried to >> remove java/lang/Object from it and it complained about missing that class >> as well. >> >> Thank you >> Xiaoran >> From aleksey.shipilev at oracle.com Tue Jun 11 01:47:06 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 12:47:06 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> Message-ID: <51B6E40A.9050904@oracle.com> On 06/11/2013 02:52 AM, Christian Thalinger wrote: > This looks good to me. Thanks for the review! > Could you run RegExp with Nashorn again with and without your changes? Being single-threaded, the benchmark will not show much of the improvement. Also, the results are rather flaky. Before: 1 thread: 175 +- 5 2 threads: 199 +- 5 msec/op After: 1 thread: 177 +- 6 msec/op 2 threads: 189 +- 6 msec/op -Aleksey. From christian.thalinger at oracle.com Tue Jun 11 08:43:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 08:43:02 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B6E40A.9050904@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> Message-ID: <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> On Jun 11, 2013, at 1:47 AM, Aleksey Shipilev wrote: > On 06/11/2013 02:52 AM, Christian Thalinger wrote: >> This looks good to me. > > Thanks for the review! > >> Could you run RegExp with Nashorn again with and without your changes? > > Being single-threaded, the benchmark will not show much of the > improvement. Also, the results are rather flaky. > > Before: > 1 thread: 175 +- 5 > 2 threads: 199 +- 5 msec/op > > After: > 1 thread: 177 +- 6 msec/op > 2 threads: 189 +- 6 msec/op Thanks for this but I was thinking running it with -Xprof to see whether some of the table methods show up on the profile. -- Chris > > -Aleksey. From aleksey.shipilev at oracle.com Tue Jun 11 09:03:02 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 20:03:02 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> Message-ID: <51B74A36.8010802@oracle.com> On 06/11/2013 07:43 PM, Christian Thalinger wrote: > Thanks for this but I was thinking running it with -Xprof to see > whether some of the table methods show up on the profile. I put little trust into this kind of profiling, but here's the sample output from JMH -prof stack, while running with 4 threads: Before: > Iteration 5 (20s in 4 threads): 380.982 msec/op > Stack | 24.8% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt > | 6.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search > | 5.2% RUNNABLE java.lang.Class.getClassLoader0 > | 3.3% RUNNABLE java.lang.ThreadLocal.get > | 3.0% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. > | 2.9% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace > | 2.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange > | 2.3% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec > | 2.1% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.groups > | 1.9% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace > | 45.6% (other) > | After: > Iteration 5 (20s in 4 threads): 358.121 msec/op > Stack | 24.7% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt > | 5.7% RUNNABLE java.lang.Class.getClassLoader0 > | 5.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search > | 3.5% RUNNABLE java.lang.ThreadLocal.get > | 3.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. > | 2.7% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace > | 2.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange > | 1.8% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec > | 1.7% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace > | 1.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.StackMachine.pop > | 47.3% (other) > | -Xprof shows the similar data. -Aleksey. From christian.thalinger at oracle.com Tue Jun 11 09:06:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 09:06:13 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B74A36.8010802@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> Message-ID: <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> On Jun 11, 2013, at 9:03 AM, Aleksey Shipilev wrote: > On 06/11/2013 07:43 PM, Christian Thalinger wrote: >> Thanks for this but I was thinking running it with -Xprof to see >> whether some of the table methods show up on the profile. > > I put little trust into this kind of profiling, but here's the sample > output from JMH -prof stack, while running with 4 threads: > > Before: >> Iteration 5 (20s in 4 threads): 380.982 msec/op >> Stack | 24.8% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt >> | 6.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search >> | 5.2% RUNNABLE java.lang.Class.getClassLoader0 >> | 3.3% RUNNABLE java.lang.ThreadLocal.get >> | 3.0% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. >> | 2.9% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace >> | 2.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange >> | 2.3% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec >> | 2.1% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.groups >> | 1.9% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace >> | 45.6% (other) >> | > > > After: >> Iteration 5 (20s in 4 threads): 358.121 msec/op >> Stack | 24.7% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt >> | 5.7% RUNNABLE java.lang.Class.getClassLoader0 >> | 5.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search >> | 3.5% RUNNABLE java.lang.ThreadLocal.get >> | 3.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. >> | 2.7% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace >> | 2.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange >> | 1.8% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec >> | 1.7% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace >> | 1.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.StackMachine.pop >> | 47.3% (other) >> | > > -Xprof shows the similar data. Odd. It showed up for me last time. Maybe it's related to using Joni now. Anyway, let's push this. -- Chris > > -Aleksey. From aleksey.shipilev at oracle.com Tue Jun 11 09:08:27 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 20:08:27 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> Message-ID: <51B74B7B.7010104@oracle.com> On 06/11/2013 08:06 PM, Christian Thalinger wrote: > Anyway, let's push this. Do you want me any other testing done? vm.mlvm.testlist is OK, but I haven't done the full JPRT test cycle, only the build one. -Aleksey. From christian.thalinger at oracle.com Tue Jun 11 11:24:48 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 11:24:48 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B74B7B.7010104@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> Message-ID: <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev wrote: > On 06/11/2013 08:06 PM, Christian Thalinger wrote: >> Anyway, let's push this. > > Do you want me any other testing done? vm.mlvm.testlist is OK, but I > haven't done the full JPRT test cycle, only the build one. You could do a full Nashorn 262 run. That would shake out bugs. -- Chris > > -Aleksey. From xiaoran at x1a0ran.com Tue Jun 11 14:06:13 2013 From: xiaoran at x1a0ran.com (Xiaoran Wang) Date: Tue, 11 Jun 2013 14:06:13 -0700 Subject: NoClassDef error when trying to preload additional class in systemDirectory::initialize_preloaded_classes() In-Reply-To: <51B6BF25.2050409@oracle.com> References: <51B6BF25.2050409@oracle.com> Message-ID: I'm building openjdk 7u6 with ALT_BOOTDIR set to jdk7u21 downloaded from java.com, but it still gave me weird build errors. So I removed all my changes, and only added one symbol to vmSymbol.hpp, and then it gave me an error again. added line:vmSymbol.hpp template(foo_bar, "foo/bar") \ cd linux_amd64_compiler2/product && ./test_gamma Using java runtime at: /usr/lib/jvm/jdk1.7.0_21/jre Error occurred during initialization of VM java.lang.InternalError at sun.misc.Launcher.getFileURL(Launcher.java:463) at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:192) at sun.misc.Launcher$ExtClassLoader.(Launcher.java:164) at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:148) at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:142) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:141) at sun.misc.Launcher.(Launcher.java:71) at sun.misc.Launcher.(Launcher.java:57) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1486) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1468) So where seems to be the problem? On Mon, Jun 10, 2013 at 11:09 PM, David Holmes wrote: > What version of hotspot are you building? If it is current sources then > you will need a JDK7 import JDK or even JDK8. You can't take current > hotspot and place into a 6u JDK for example. > > David > > > On 9/06/2013 6:06 AM, Xiaoran Wang wrote: > >> To followup, I tried to put foo/bar.class into $JAVA_HOME/jre/classes, now >> the linux_amd64_compiler2/product/**test_gamma passed without error, but >> another error occured from linux_amd64_compiler2/jvmg/**test_gamma, >> which is >> even more confusing. >> >> cd linux_amd64_compiler2/jvmg && ./test_gamma >> java full version "1.6.0_22-b04" >> Using java runtime at: /home/Documents/tools/hotspot-** >> working-dir/java/jre >> Error occurred during initialization of VM >> java.lang.**NoSuchMethodException: java.lang.reflect.Method.**invoke >> >> >> Can someone shed some light please? >> >> >> On Sat, Jun 8, 2013 at 12:32 PM, Xiaoran Wang >> wrote: >> >> Hi all, >>> >>> I'm instrumenting the hotspot JVM for research purposes and one of the >>> steps is to preload some classes during JVM startup time so that I can >>> use >>> its KlassOop/KlassHandle later in the template Interpreter. >>> >>> I appended the new classes I wanted to load in systemDirectory.hpp, e.g. >>> *template(bar_klass, foo_bar, Pre) \* >>> >>> And its corresponding symbol in vmSymbols.hpp >>> *template(foo_bar, "foo/bar")\* >>> >>> >>> Then I put foo/bar.class into the corresponding rt.jar that will be used >>> to build libjvm.so. >>> >>> However, when I built it, the "gamma" test always gives me an >>> NoClassDefFoundError. >>> >>> cd linux_amd64_compiler2/product && ./test_gamma >>> java full version "1.6.0_22-b04" >>> Using java runtime at: /home/Documents/tools/hotspot-** >>> working-dir/java/jre >>> Error occurred during initialization of VM >>> java/lang/**NoClassDefFoundError: foo/bar >>> >>> >>> So my question is where should I put my custom class so that it can be >>> preloaded during JVM startup in >>> systemDirectory::initialize_**preloaded_classes? >>> >>> btw, I verified the rt.jar is the one JVM is loading because I tried to >>> remove java/lang/Object from it and it complained about missing that >>> class >>> as well. >>> >>> Thank you >>> Xiaoran >>> >>> From aleksey.shipilev at oracle.com Tue Jun 11 14:21:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 12 Jun 2013 01:21:45 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> Message-ID: <51B794E9.2040405@oracle.com> On 06/11/2013 10:24 PM, Christian Thalinger wrote: > > On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev wrote: > >> On 06/11/2013 08:06 PM, Christian Thalinger wrote: >>> Anyway, let's push this. >> >> Do you want me any other testing done? vm.mlvm.testlist is OK, but I >> haven't done the full JPRT test cycle, only the build one. > > You could do a full Nashorn 262 run. That would shake out bugs. Done. Linux x86_64/release passes test262parallel with either clean or patched build. -Aleksey. From alejandro.murillo at oracle.com Tue Jun 11 15:03:07 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 11 Jun 2013 16:03:07 -0600 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51B79E9B.5070308@oracle.com> vote: yes On 6/10/2013 10:59 AM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote -- Alejandro From coleen.phillimore at oracle.com Tue Jun 11 15:02:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Jun 2013 18:02:17 -0400 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51B79E69.80106@oracle.com> Vote: yes On 06/10/2013 12:59 PM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From daniel.daugherty at oracle.com Tue Jun 11 15:14:04 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 11 Jun 2013 22:14:04 +0000 Subject: hg: hsx/hsx24/hotspot: 8013057: assert(_needs_gc || SafepointSynchronize::is_at_safepoint()) failed: only read at safepoint Message-ID: <20130611221410.4DB0348152@hg.openjdk.java.net> Changeset: a1a295252814 Author: dcubed Date: 2013-06-11 07:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a1a295252814 8013057: assert(_needs_gc || SafepointSynchronize::is_at_safepoint()) failed: only read at safepoint Summary: Detect mmap() commit failures in Linux and Solaris os::commit_memory() impls and call vm_exit_out_of_memory(). Add os::commit_memory_or_exit(). Also tidy up some NMT accounting and some mmap() return value checking. Reviewed-by: zgu, stefank, dholmes, dsamersoff ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp From christian.thalinger at oracle.com Tue Jun 11 19:16:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 19:16:06 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B794E9.2040405@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> <51B794E9.2040405@oracle.com> Message-ID: On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev wrote: > On 06/11/2013 10:24 PM, Christian Thalinger wrote: >> >> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev wrote: >> >>> On 06/11/2013 08:06 PM, Christian Thalinger wrote: >>>> Anyway, let's push this. >>> >>> Do you want me any other testing done? vm.mlvm.testlist is OK, but I >>> haven't done the full JPRT test cycle, only the build one. >> >> You could do a full Nashorn 262 run. That would shake out bugs. > > Done. Linux x86_64/release passes test262parallel with either clean or > patched build. Thanks for verifying. I'll push your change tomorrow. -- Chris > > -Aleksey. > From christian.thalinger at oracle.com Tue Jun 11 19:19:44 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 19:19:44 -0700 Subject: NoClassDef error when trying to preload additional class in systemDirectory::initialize_preloaded_classes() In-Reply-To: References: <51B6BF25.2050409@oracle.com> Message-ID: <6B225E88-E19B-40DD-8E9B-EB4D41203D5E@oracle.com> On Jun 11, 2013, at 2:06 PM, Xiaoran Wang wrote: > I'm building openjdk 7u6 with ALT_BOOTDIR set to jdk7u21 downloaded from > java.com, but it still gave me weird build errors. So I removed all my > changes, and only added one symbol to vmSymbol.hpp, and then it gave me an > error again. > > added line:vmSymbol.hpp > template(foo_bar, "foo/bar") \ > > cd linux_amd64_compiler2/product && ./test_gamma > Using java runtime at: /usr/lib/jvm/jdk1.7.0_21/jre That's a long standing problem which we fixed in the 8 repositories: test_gamma runs with the boot JDK. In your case you are trying to run a HotSpot version from 7u6 with a 7u21 JDK. Mix-and-match is not supported and may lead to problems like this. -- Chris > Error occurred during initialization of VM > java.lang.InternalError > at sun.misc.Launcher.getFileURL(Launcher.java:463) > at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:192) > at sun.misc.Launcher$ExtClassLoader.(Launcher.java:164) > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:148) > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:142) > at java.security.AccessController.doPrivileged(Native Method) > at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:141) > at sun.misc.Launcher.(Launcher.java:71) > at sun.misc.Launcher.(Launcher.java:57) > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1486) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1468) > > So where seems to be the problem? > > > > > On Mon, Jun 10, 2013 at 11:09 PM, David Holmes wrote: > >> What version of hotspot are you building? If it is current sources then >> you will need a JDK7 import JDK or even JDK8. You can't take current >> hotspot and place into a 6u JDK for example. >> >> David >> >> >> On 9/06/2013 6:06 AM, Xiaoran Wang wrote: >> >>> To followup, I tried to put foo/bar.class into $JAVA_HOME/jre/classes, now >>> the linux_amd64_compiler2/product/**test_gamma passed without error, but >>> another error occured from linux_amd64_compiler2/jvmg/**test_gamma, >>> which is >>> even more confusing. >>> >>> cd linux_amd64_compiler2/jvmg && ./test_gamma >>> java full version "1.6.0_22-b04" >>> Using java runtime at: /home/Documents/tools/hotspot-** >>> working-dir/java/jre >>> Error occurred during initialization of VM >>> java.lang.**NoSuchMethodException: java.lang.reflect.Method.**invoke >>> >>> >>> Can someone shed some light please? >>> >>> >>> On Sat, Jun 8, 2013 at 12:32 PM, Xiaoran Wang >>> wrote: >>> >>> Hi all, >>>> >>>> I'm instrumenting the hotspot JVM for research purposes and one of the >>>> steps is to preload some classes during JVM startup time so that I can >>>> use >>>> its KlassOop/KlassHandle later in the template Interpreter. >>>> >>>> I appended the new classes I wanted to load in systemDirectory.hpp, e.g. >>>> *template(bar_klass, foo_bar, Pre) \* >>>> >>>> And its corresponding symbol in vmSymbols.hpp >>>> *template(foo_bar, "foo/bar")\* >>>> >>>> >>>> Then I put foo/bar.class into the corresponding rt.jar that will be used >>>> to build libjvm.so. >>>> >>>> However, when I built it, the "gamma" test always gives me an >>>> NoClassDefFoundError. >>>> >>>> cd linux_amd64_compiler2/product && ./test_gamma >>>> java full version "1.6.0_22-b04" >>>> Using java runtime at: /home/Documents/tools/hotspot-** >>>> working-dir/java/jre >>>> Error occurred during initialization of VM >>>> java/lang/**NoClassDefFoundError: foo/bar >>>> >>>> >>>> So my question is where should I put my custom class so that it can be >>>> preloaded during JVM startup in >>>> systemDirectory::initialize_**preloaded_classes? >>>> >>>> btw, I verified the rt.jar is the one JVM is loading because I tried to >>>> remove java/lang/Object from it and it complained about missing that >>>> class >>>> as well. >>>> >>>> Thank you >>>> Xiaoran >>>> >>>> From xiaoran at x1a0ran.com Tue Jun 11 19:45:53 2013 From: xiaoran at x1a0ran.com (Xiaoran Wang) Date: Tue, 11 Jun 2013 19:45:53 -0700 Subject: NoClassDef error when trying to preload additional class in systemDirectory::initialize_preloaded_classes() In-Reply-To: <6B225E88-E19B-40DD-8E9B-EB4D41203D5E@oracle.com> References: <51B6BF25.2050409@oracle.com> <6B225E88-E19B-40DD-8E9B-EB4D41203D5E@oracle.com> Message-ID: Thanks Christian. So I guess the best way would be to download jdk8 and build it without changes, and then instrument the hotspot JVM and build it with the jdk8 that's just built? On Tue, Jun 11, 2013 at 7:19 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On Jun 11, 2013, at 2:06 PM, Xiaoran Wang wrote: > > > I'm building openjdk 7u6 with ALT_BOOTDIR set to jdk7u21 downloaded from > > java.com, but it still gave me weird build errors. So I removed all my > > changes, and only added one symbol to vmSymbol.hpp, and then it gave me > an > > error again. > > > > added line:vmSymbol.hpp > > template(foo_bar, "foo/bar") > \ > > > > cd linux_amd64_compiler2/product && ./test_gamma > > Using java runtime at: /usr/lib/jvm/jdk1.7.0_21/jre > > That's a long standing problem which we fixed in the 8 repositories: > test_gamma runs with the boot JDK. > > In your case you are trying to run a HotSpot version from 7u6 with a 7u21 > JDK. Mix-and-match is not supported and may lead to problems like this. > > -- Chris > > > Error occurred during initialization of VM > > java.lang.InternalError > > at sun.misc.Launcher.getFileURL(Launcher.java:463) > > at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:192) > > at sun.misc.Launcher$ExtClassLoader.(Launcher.java:164) > > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:148) > > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:142) > > at java.security.AccessController.doPrivileged(Native Method) > > at > sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:141) > > at sun.misc.Launcher.(Launcher.java:71) > > at sun.misc.Launcher.(Launcher.java:57) > > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1486) > > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1468) > > > > So where seems to be the problem? > > > > > > > > > > On Mon, Jun 10, 2013 at 11:09 PM, David Holmes >wrote: > > > >> What version of hotspot are you building? If it is current sources then > >> you will need a JDK7 import JDK or even JDK8. You can't take current > >> hotspot and place into a 6u JDK for example. > >> > >> David > >> > >> > >> On 9/06/2013 6:06 AM, Xiaoran Wang wrote: > >> > >>> To followup, I tried to put foo/bar.class into $JAVA_HOME/jre/classes, > now > >>> the linux_amd64_compiler2/product/**test_gamma passed without error, > but > >>> another error occured from linux_amd64_compiler2/jvmg/**test_gamma, > >>> which is > >>> even more confusing. > >>> > >>> cd linux_amd64_compiler2/jvmg && ./test_gamma > >>> java full version "1.6.0_22-b04" > >>> Using java runtime at: /home/Documents/tools/hotspot-** > >>> working-dir/java/jre > >>> Error occurred during initialization of VM > >>> java.lang.**NoSuchMethodException: java.lang.reflect.Method.**invoke > >>> > >>> > >>> Can someone shed some light please? > >>> > >>> > >>> On Sat, Jun 8, 2013 at 12:32 PM, Xiaoran Wang > >>> wrote: > >>> > >>> Hi all, > >>>> > >>>> I'm instrumenting the hotspot JVM for research purposes and one of the > >>>> steps is to preload some classes during JVM startup time so that I can > >>>> use > >>>> its KlassOop/KlassHandle later in the template Interpreter. > >>>> > >>>> I appended the new classes I wanted to load in systemDirectory.hpp, > e.g. > >>>> *template(bar_klass, foo_bar, Pre) \* > >>>> > >>>> And its corresponding symbol in vmSymbols.hpp > >>>> *template(foo_bar, "foo/bar")\* > >>>> > >>>> > >>>> Then I put foo/bar.class into the corresponding rt.jar that will be > used > >>>> to build libjvm.so. > >>>> > >>>> However, when I built it, the "gamma" test always gives me an > >>>> NoClassDefFoundError. > >>>> > >>>> cd linux_amd64_compiler2/product && ./test_gamma > >>>> java full version "1.6.0_22-b04" > >>>> Using java runtime at: /home/Documents/tools/hotspot-** > >>>> working-dir/java/jre > >>>> Error occurred during initialization of VM > >>>> java/lang/**NoClassDefFoundError: foo/bar > >>>> > >>>> > >>>> So my question is where should I put my custom class so that it can be > >>>> preloaded during JVM startup in > >>>> systemDirectory::initialize_**preloaded_classes? > >>>> > >>>> btw, I verified the rt.jar is the one JVM is loading because I tried > to > >>>> remove java/lang/Object from it and it complained about missing that > >>>> class > >>>> as well. > >>>> > >>>> Thank you > >>>> Xiaoran > >>>> > >>>> > > From christian.thalinger at oracle.com Tue Jun 11 21:16:37 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 21:16:37 -0700 Subject: NoClassDef error when trying to preload additional class in systemDirectory::initialize_preloaded_classes() In-Reply-To: References: <51B6BF25.2050409@oracle.com> <6B225E88-E19B-40DD-8E9B-EB4D41203D5E@oracle.com> Message-ID: <0AA02107-3998-454B-9B36-2DFE2122F550@oracle.com> On Jun 11, 2013, at 7:45 PM, Xiaoran Wang wrote: > Thanks Christian. So I guess the best way would be to download jdk8 and build it without changes, and then instrument the hotspot JVM and build it with the jdk8 that's just built? An easier way would be to use the same JDK you are building for as boot JDK. -- Chris > > > On Tue, Jun 11, 2013 at 7:19 PM, Christian Thalinger wrote: > > On Jun 11, 2013, at 2:06 PM, Xiaoran Wang wrote: > > > I'm building openjdk 7u6 with ALT_BOOTDIR set to jdk7u21 downloaded from > > java.com, but it still gave me weird build errors. So I removed all my > > changes, and only added one symbol to vmSymbol.hpp, and then it gave me an > > error again. > > > > added line:vmSymbol.hpp > > template(foo_bar, "foo/bar") \ > > > > cd linux_amd64_compiler2/product && ./test_gamma > > Using java runtime at: /usr/lib/jvm/jdk1.7.0_21/jre > > That's a long standing problem which we fixed in the 8 repositories: test_gamma runs with the boot JDK. > > In your case you are trying to run a HotSpot version from 7u6 with a 7u21 JDK. Mix-and-match is not supported and may lead to problems like this. > > -- Chris > > > Error occurred during initialization of VM > > java.lang.InternalError > > at sun.misc.Launcher.getFileURL(Launcher.java:463) > > at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:192) > > at sun.misc.Launcher$ExtClassLoader.(Launcher.java:164) > > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:148) > > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:142) > > at java.security.AccessController.doPrivileged(Native Method) > > at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:141) > > at sun.misc.Launcher.(Launcher.java:71) > > at sun.misc.Launcher.(Launcher.java:57) > > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1486) > > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1468) > > > > So where seems to be the problem? > > > > > > > > > > On Mon, Jun 10, 2013 at 11:09 PM, David Holmes wrote: > > > >> What version of hotspot are you building? If it is current sources then > >> you will need a JDK7 import JDK or even JDK8. You can't take current > >> hotspot and place into a 6u JDK for example. > >> > >> David > >> > >> > >> On 9/06/2013 6:06 AM, Xiaoran Wang wrote: > >> > >>> To followup, I tried to put foo/bar.class into $JAVA_HOME/jre/classes, now > >>> the linux_amd64_compiler2/product/**test_gamma passed without error, but > >>> another error occured from linux_amd64_compiler2/jvmg/**test_gamma, > >>> which is > >>> even more confusing. > >>> > >>> cd linux_amd64_compiler2/jvmg && ./test_gamma > >>> java full version "1.6.0_22-b04" > >>> Using java runtime at: /home/Documents/tools/hotspot-** > >>> working-dir/java/jre > >>> Error occurred during initialization of VM > >>> java.lang.**NoSuchMethodException: java.lang.reflect.Method.**invoke > >>> > >>> > >>> Can someone shed some light please? > >>> > >>> > >>> On Sat, Jun 8, 2013 at 12:32 PM, Xiaoran Wang > >>> wrote: > >>> > >>> Hi all, > >>>> > >>>> I'm instrumenting the hotspot JVM for research purposes and one of the > >>>> steps is to preload some classes during JVM startup time so that I can > >>>> use > >>>> its KlassOop/KlassHandle later in the template Interpreter. > >>>> > >>>> I appended the new classes I wanted to load in systemDirectory.hpp, e.g. > >>>> *template(bar_klass, foo_bar, Pre) \* > >>>> > >>>> And its corresponding symbol in vmSymbols.hpp > >>>> *template(foo_bar, "foo/bar")\* > >>>> > >>>> > >>>> Then I put foo/bar.class into the corresponding rt.jar that will be used > >>>> to build libjvm.so. > >>>> > >>>> However, when I built it, the "gamma" test always gives me an > >>>> NoClassDefFoundError. > >>>> > >>>> cd linux_amd64_compiler2/product && ./test_gamma > >>>> java full version "1.6.0_22-b04" > >>>> Using java runtime at: /home/Documents/tools/hotspot-** > >>>> working-dir/java/jre > >>>> Error occurred during initialization of VM > >>>> java/lang/**NoClassDefFoundError: foo/bar > >>>> > >>>> > >>>> So my question is where should I put my custom class so that it can be > >>>> preloaded during JVM startup in > >>>> systemDirectory::initialize_**preloaded_classes? > >>>> > >>>> btw, I verified the rt.jar is the one JVM is loading because I tried to > >>>> remove java/lang/Object from it and it complained about missing that > >>>> class > >>>> as well. > >>>> > >>>> Thank you > >>>> Xiaoran > >>>> > >>>> > > From morris.meyer at oracle.com Tue Jun 11 22:19:48 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Wed, 12 Jun 2013 05:19:48 +0000 Subject: hg: hsx/hsx24/hotspot: 8016187: assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range Message-ID: <20130612051951.F2CF448169@hg.openjdk.java.net> Changeset: 5064f1a8b6ee Author: morris Date: 2013-06-11 16:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5064f1a8b6ee 8016187: assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range Summary: Forced SPARC Assembler eden_alloate to use long branch to slow case Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp From rickard.backman at oracle.com Wed Jun 12 02:32:04 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 12 Jun 2013 11:32:04 +0200 Subject: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp In-Reply-To: References: <1a584728-48fd-4640-926d-e0b70be7e4e3@default> <08EB6131-7607-4419-B7B5-12715B7340F0@oracle.com> <7016df98-0b5a-48fe-83c4-46bbd5e7c874@default> Message-ID: Looks good to me. /R On Jun 10, 2013, at 11:46 AM, Markus Gr?nlund wrote: > Updated webrev with REALLOC_C_HEAP_ARRAY2 removed: > > http://cr.openjdk.java.net/~mgronlun/8016105/webrev02/ > > > Thanks to reviewing > > Markus > > -----Original Message----- > From: Markus Gr?nlund > Sent: den 10 juni 2013 11:15 > To: Staffan Larsen > Cc: hotspot-dev at openjdk.java.net Developers > Subject: RE: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp > > Thanks Staffan, > > Thanks for spotting - it can be removed. > > Thanks > Markus > > -----Original Message----- > From: Staffan Larsen > Sent: den 10 juni 2013 11:06 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net Developers > Subject: Re: RFR(XS): 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp > > Looks good, but do we need REALLOC_C_HEAP_ARRAY2()? It is never used and does not seem to add anything compared to REALLOC_C_HEAP_ARRAY / REALLOC_C_HEAP_ARRAY_RETURN_NULL. > > /Staffan > > On 7 jun 2013, at 09:07, Markus Gr?nlund wrote: > >> Greetings, >> >> >> >> Kindly asking for reviews for the following: >> >> >> >> Bug id: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016105 >> >> >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8016105/webrev01/ >> >> >> >> >> >> Thank you >> >> Markus > From erik.helin at oracle.com Wed Jun 12 05:36:56 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Wed, 12 Jun 2013 12:36:56 +0000 Subject: hg: hsx/hsx24/hotspot: 8015972: Refactor the sending of the object count after GC event Message-ID: <20130612123701.7699448185@hg.openjdk.java.net> Changeset: a55abcd09aeb Author: ehelin Date: 2013-06-05 09:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a55abcd09aeb 8015972: Refactor the sending of the object count after GC event Reviewed-by: mgerdin, brutisso ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/heapInspection.hpp - src/share/vm/memory/klassInfoClosure.hpp From goetz.lindenmaier at sap.com Wed Jun 12 07:44:05 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 Jun 2013 14:44:05 +0000 Subject: JEP 175 - Review comments In-Reply-To: <51B75177.3020804@oracle.com> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> Hi, With my recent changes I removed some of the problems Vladimir mentioned. I also added the patches queue I maintain into our jdk8/hotspot repository, at hotspot/ppc_patches. Applied to the staging hotspot directory, the linuxppc and aixppc hotspots can be built. The queue contains the changes proposed by me before, with minor changes due to recent development: 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) 11-15 aixppc C-interpreter port (In our plan milestone M2.2) 101-107 C-interpreter improvements 111-122 ppc C2 compiler port leading to a vm rudimentarily working 200-217 C2 compiler fixes, extensions etc needed for a stable and performant ppc port. Altogether currently 49 changes. Our plan was to propose the changes in the order of the queue for review. I'm happy to create webrevs for any of them. Vladimir, maybe the queue simplifies reviewing the port, as the changes are more complete. They include all later improvements by fixes or adaptions in merge changes. For why and where I renamed PPC to PPC32 see the second change in the queue. Best regards, Goetz. PS: This can be used as the invokedynamic repository: hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot ppc-hotspot hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot stage-hotspot cd stage-hotspot ln -s .../ppc-hotspot/ppc_patches/ .hg/patches hg qpush -a -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 11. Juni 2013 18:34 To: Lindenmaier, Goetz Cc: Volker Simonis; Azeem Jiva; Chris Plummer Subject: Re: JEP 175 - Review comments Here is result of my first attempt to build/test ppc changes together with our closed sources. Small problems: src/share/vm/memory/allocation.hpp:209: Trailing whitespace src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace src/share/vm/opto/escape.cpp:2207: Trailing whitespace src/share/vm/memory/allocation.hpp:212: Trailing whitespace src/share/vm/opto/escape.cpp:2214: Trailing whitespace Build on MacOS: src/share/vm/opto/callGenerator.cpp: In member function 'virtual JVMState* VirtualCallGenerator::generate(JVMState*)': src/share/vm/opto/callGenerator.cpp:204: error: 'zero_page_read_protected' is not a member of 'os' agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error UNSUPPORTED_ARCH agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error UNSUPPORTED_ARCH agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error UNSUPPORTED_ARCH We have several conflict with closed sources builds: src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between signed and unsigned integer expressions src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between signed and unsigned integer expressions error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' member function declared in class 'frame' error: no matching function for call to 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' I think it is due to changes like next: -#ifdef PPC +#ifdef PPC32 oop* interpreter_frame_mirror_addr() const; Next is easy fix in our closed sources but it requires efforts from our side: src/share/vm/prims/methodHandles.cpp: In static member function 'static void MethodHandles::generate_adapters()': src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' cannot be used as a function src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' cannot be used as a function I would suggest to do such shared changes which affects different builds later after initial push. Thanks, Vladimir On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I updated the repo to jdk8-b92. Our nightly tests built and > tested it successfully. In case you experience any problems > please tell me the details so I can fix them. > > Best regards, > Goetz. > > http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 4. Juni 2013 20:58 > To: Simonis, Volker > Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan Bateman > Subject: Re: JEP 175 - Review comments > > Volker, > > Can you or someone update > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest > sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? > I just tried to merge them and build Hotspot on x86 without success. > > Thanks, > Vladimir > > On 6/4/13 7:04 AM, Simonis, Volker wrote: >> >> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in the >> beginning to address a broader audience for the initial discussions. >> >> But I'm happy to change that back to 'ppc-aix-port-dev' now. >> >> Regards, >> Volker >> >> >> ------------------------------------------------------------------------ >> *From:* Iris Clark [iris.clark at oracle.com] >> *Sent:* Tuesday, June 04, 2013 3:50 PM >> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >> iris.clark at oracle.com >> *Cc:* Alan Bateman; Vladimir Kozlov >> *Subject:* RE: JEP 175 - Review comments >> >> Hi, Volker. >> >> Sorry about this, one more thing about the JEP... >> >> I think that the "Discussion" list probably needs to be updated to be >> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >> as porters-dev. >> >> Thanks, >> >> iris >> >> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >> *Sent:* Tuesday, June 04, 2013 12:12 AM >> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >> *Cc:* Alan Bateman; Vladimir Kozlov >> *Subject:* RE: JEP 175 - Review comments >> >> Hi Iris, >> >> you're right, the title is too clumsy - I just couldn't come up with >> something better yesterday in the evening. >> >> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take it. >> >> Thanks, >> Volker >> >> ------------------------------------------------------------------------ >> >> *From:*Iris Clark [iris.clark at oracle.com] >> *Sent:* Tuesday, June 04, 2013 2:57 AM >> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >> ; Tim Ellison >> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >> >> *Subject:* RE: JEP 175 - Review comments >> >> Hi, Volker. >> >> I've just updated the JEP according to your suggestions. >> >> I'm not a Reviewer however, I think that the phrase "OpenJDK master >> repositories" in the revised title is not ideal: >> >> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >> >> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >> >> @@ -1,5 +1,5 @@ >> >> JEP: 175 >> >> -Title: Integrate PowerPC/AIX Port into JDK 8 >> >> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master repositories >> >> Author: Volker Simonis >> >> Organization: SAP AG >> >> Created: 2013/1/11 >> >> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >> about adding features to JDK Release Projects. There are lots of >> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >> additional details. >> >> Perhaps others have suggestions? >> >> Am I right with my assumption that the targeted release will still be >> JDK 8 (or 9/8u respectively) but that the targeted release will be set >> in the "Release" header field of the JEP by the OpenJDK Lead (as >> specified in the JEP specification)? >> >> Yes. Once that field is populated, the value will appear in the JEP >> index [1], see the third column. >> >> Thanks, >> >> Iris >> >> [1]: http://openjdk.java.net/jeps/0 >> >> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >> *Sent:* Monday, June 03, 2013 10:10 AM >> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >> ; Tim Ellison >> *Cc:* Alan Bateman; Vladimir Kozlov >> *Subject:* RE: JEP 175 - Review comments >> >> Hi, >> >> I've just updated the JEP according to your suggestions. Please find >> the new version attached to this mail (I haven't checked the new version >> in until now to give everybody a chance to comment on the changes). >> >> Am I right with my assumption that the targeted release will still be >> JDK 8 (or 9/8u respectively) but that the targeted release will be set >> in the "Release" header field of the JEP by the OpenJDK Lead (as >> specified in the JEP specification)? >> >> In addition to the changes proposed by you I've added the contents of >> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >> section of the JEP. I've also added links to the new "PowerPC/AIX Port >> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >> to the JEP. >> >> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >> Azeems "PPCAIX plan" document. >> >> @Iris: could you please somehow arrange to give Azeem editing rights to >> that page? >> >> @Azeem: could you please be so kind to past the contents of the "PPCAIX >> plan" into that page (once you have the appropriate rights)? I saw that >> the document is created from an Atlassian Confluence Wiki anyway and in >> my unlimited naivety I imagine this could be a simple copy-and-paste >> operation:) If that doesn't work so easily, please let me know how I >> could help. >> >> If there are no objections I plan to checkin the new version of the JEP >> tomorrow after our telephone call. >> >> Thank you and best regards, >> Volker >> >> [2]: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >> >> ------------------------------------------------------------------------ >> >> *From:*Iris Clark [iris.clark at oracle.com] >> *Sent:* Friday, May 31, 2013 8:48 PM >> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; Bernard >> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >> ; Tim Ellison >> *Cc:* iris.clark at oracle.com ; Alan >> Bateman; Vladimir Kozlov >> *Subject:* JEP 175 - Review comments >> >> Hi, Volker. >> >> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >> >> http://openjdk.java.net/jeps/175 >> >> We're actively working to get your JEP to Funded. We had a few comments: >> >> -Recommend that "8" be removed from the JEP title, etc. >> >> -Recommend that the first Motivation bullet clearly indicate that it is >> only covering PPC/AIX. >> >> -Recommend that the second Motivation bullet be modified to make it >> clear that it applies to Hotspot only. >> >> (Instructions for editing the JEP may be found in the "Mechanics" >> section at the bottom of JEP 1 [1].) >> >> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >> be the JEP's reviewers. Once they're satisfied with your >> changes/feedback they'll add themselves to the JEP's "Reviewed-by" line. >> >> Thanks, >> >> Iris Clark >> >> [1]: http://openjdk.java.net/jeps/1 >> From vladimir.kozlov at oracle.com Wed Jun 12 08:02:33 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2013 08:02:33 -0700 Subject: JEP 175 - Review comments In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> Message-ID: <51B88D89.1070802@oracle.com> Thank you, Goetz. Can I review just 1 patch (for example, 1 from first 1-9), merge it with jdk8 and build? Or I should do review all 1-9 patches and merge them together into jdk8 to be able build? In short, is each patch self-contain? Thanks, Vladimir On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: > Hi, > > With my recent changes I removed some of the problems Vladimir mentioned. > > I also added the patches queue I maintain into our jdk8/hotspot repository, > at hotspot/ppc_patches. > Applied to the staging hotspot directory, the linuxppc and aixppc hotspots > can be built. > > The queue contains the changes proposed by me before, with minor changes due > to recent development: > > 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) > 11-15 aixppc C-interpreter port (In our plan milestone M2.2) > 101-107 C-interpreter improvements > 111-122 ppc C2 compiler port leading to a vm rudimentarily working > 200-217 C2 compiler fixes, extensions etc needed for a stable and > performant ppc port. > Altogether currently 49 changes. > > Our plan was to propose the changes in the order of the queue for > review. I'm happy to create webrevs for any of them. > > Vladimir, maybe the queue simplifies reviewing the port, as the changes > are more complete. They include all later improvements by fixes or > adaptions in merge changes. > For why and where I renamed PPC to PPC32 see the second change in the > queue. > > Best regards, > Goetz. > > > PS: This can be used as the invokedynamic repository: > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot ppc-hotspot > hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot stage-hotspot > cd stage-hotspot > ln -s .../ppc-hotspot/ppc_patches/ .hg/patches > hg qpush -a > > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 11. Juni 2013 18:34 > To: Lindenmaier, Goetz > Cc: Volker Simonis; Azeem Jiva; Chris Plummer > Subject: Re: JEP 175 - Review comments > > Here is result of my first attempt to build/test ppc changes together > with our closed sources. > > Small problems: > > src/share/vm/memory/allocation.hpp:209: Trailing whitespace > src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace > src/share/vm/opto/escape.cpp:2207: Trailing whitespace > src/share/vm/memory/allocation.hpp:212: Trailing whitespace > src/share/vm/opto/escape.cpp:2214: Trailing whitespace > > Build on MacOS: > > src/share/vm/opto/callGenerator.cpp: In member function 'virtual > JVMState* VirtualCallGenerator::generate(JVMState*)': > src/share/vm/opto/callGenerator.cpp:204: error: > 'zero_page_read_protected' is not a member of 'os' > > agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error UNSUPPORTED_ARCH > > > We have several conflict with closed sources builds: > > src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool > ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': > src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between > signed and unsigned integer expressions > src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between > signed and unsigned integer expressions > > error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' > member function declared in class 'frame' > > error: no matching function for call to > 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' > > I think it is due to changes like next: > > -#ifdef PPC > +#ifdef PPC32 > oop* interpreter_frame_mirror_addr() const; > > > Next is easy fix in our closed sources but it requires efforts from our > side: > > src/share/vm/prims/methodHandles.cpp: In static member function 'static > void MethodHandles::generate_adapters()': > src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' > cannot be used as a function > src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' > cannot be used as a function > > > I would suggest to do such shared changes which affects different builds > later after initial push. > > > Thanks, > Vladimir > > On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I updated the repo to jdk8-b92. Our nightly tests built and >> tested it successfully. In case you experience any problems >> please tell me the details so I can fix them. >> >> Best regards, >> Goetz. >> >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 4. Juni 2013 20:58 >> To: Simonis, Volker >> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan Bateman >> Subject: Re: JEP 175 - Review comments >> >> Volker, >> >> Can you or someone update >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >> I just tried to merge them and build Hotspot on x86 without success. >> >> Thanks, >> Vladimir >> >> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>> >>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in the >>> beginning to address a broader audience for the initial discussions. >>> >>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>> >>> Regards, >>> Volker >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>> iris.clark at oracle.com >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> Sorry about this, one more thing about the JEP... >>> >>> I think that the "Discussion" list probably needs to be updated to be >>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>> as porters-dev. >>> >>> Thanks, >>> >>> iris >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi Iris, >>> >>> you're right, the title is too clumsy - I just couldn't come up with >>> something better yesterday in the evening. >>> >>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take it. >>> >>> Thanks, >>> Volker >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>> >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> I've just updated the JEP according to your suggestions. >>> >>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>> repositories" in the revised title is not ideal: >>> >>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>> >>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>> >>> @@ -1,5 +1,5 @@ >>> >>> JEP: 175 >>> >>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>> >>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master repositories >>> >>> Author: Volker Simonis >>> >>> Organization: SAP AG >>> >>> Created: 2013/1/11 >>> >>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>> about adding features to JDK Release Projects. There are lots of >>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>> additional details. >>> >>> Perhaps others have suggestions? >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> Yes. Once that field is populated, the value will appear in the JEP >>> index [1], see the third column. >>> >>> Thanks, >>> >>> Iris >>> >>> [1]: http://openjdk.java.net/jeps/0 >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Monday, June 03, 2013 10:10 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, >>> >>> I've just updated the JEP according to your suggestions. Please find >>> the new version attached to this mail (I haven't checked the new version >>> in until now to give everybody a chance to comment on the changes). >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> In addition to the changes proposed by you I've added the contents of >>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>> to the JEP. >>> >>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>> Azeems "PPCAIX plan" document. >>> >>> @Iris: could you please somehow arrange to give Azeem editing rights to >>> that page? >>> >>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>> plan" into that page (once you have the appropriate rights)? I saw that >>> the document is created from an Atlassian Confluence Wiki anyway and in >>> my unlimited naivety I imagine this could be a simple copy-and-paste >>> operation:) If that doesn't work so easily, please let me know how I >>> could help. >>> >>> If there are no objections I plan to checkin the new version of the JEP >>> tomorrow after our telephone call. >>> >>> Thank you and best regards, >>> Volker >>> >>> [2]: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Friday, May 31, 2013 8:48 PM >>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* iris.clark at oracle.com ; Alan >>> Bateman; Vladimir Kozlov >>> *Subject:* JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>> >>> http://openjdk.java.net/jeps/175 >>> >>> We're actively working to get your JEP to Funded. We had a few comments: >>> >>> -Recommend that "8" be removed from the JEP title, etc. >>> >>> -Recommend that the first Motivation bullet clearly indicate that it is >>> only covering PPC/AIX. >>> >>> -Recommend that the second Motivation bullet be modified to make it >>> clear that it applies to Hotspot only. >>> >>> (Instructions for editing the JEP may be found in the "Mechanics" >>> section at the bottom of JEP 1 [1].) >>> >>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>> be the JEP's reviewers. Once they're satisfied with your >>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" line. >>> >>> Thanks, >>> >>> Iris Clark >>> >>> [1]: http://openjdk.java.net/jeps/1 >>> From goetz.lindenmaier at sap.com Wed Jun 12 08:39:57 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 Jun 2013 15:39:57 +0000 Subject: JEP 175 - Review comments In-Reply-To: <51B88D89.1070802@oracle.com> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B88D89.1070802@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFDA667@DEWDFEMB12A.global.corp.sap> Hi Vladimir, yes, the plan is that each is self contained. When I set up the patches I built and jckecked each. When I updated them I only built them selectively, so there might be minor issues. I had planned to assure this once I make webrevs from the patches. Some of them might apply in any order, but others depend on previous ones, e.g., 0009 containing the ppc files will not work without the changes before. The patches work with hs25-b34. Please tell me if I can do anything to ease your reviewing. Ah, I just saw your mail about closed code ... I tried to keep changes necessary to other platform code to a minimum, but also tried to avoid strange workarounds. Therefore I for example did change 0002 renaming the PPC defines, see the comment there. If you agree with the granularity of the changes, it would be great if you could generate bug-ids for them. Maybe at least for the changes up to 0016? Best regards Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 12. Juni 2013 17:03 To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer Subject: Re: JEP 175 - Review comments Thank you, Goetz. Can I review just 1 patch (for example, 1 from first 1-9), merge it with jdk8 and build? Or I should do review all 1-9 patches and merge them together into jdk8 to be able build? In short, is each patch self-contain? Thanks, Vladimir On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: > Hi, > > With my recent changes I removed some of the problems Vladimir mentioned. > > I also added the patches queue I maintain into our jdk8/hotspot repository, > at hotspot/ppc_patches. > Applied to the staging hotspot directory, the linuxppc and aixppc hotspots > can be built. > > The queue contains the changes proposed by me before, with minor changes due > to recent development: > > 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) > 11-15 aixppc C-interpreter port (In our plan milestone M2.2) > 101-107 C-interpreter improvements > 111-122 ppc C2 compiler port leading to a vm rudimentarily working > 200-217 C2 compiler fixes, extensions etc needed for a stable and > performant ppc port. > Altogether currently 49 changes. > > Our plan was to propose the changes in the order of the queue for > review. I'm happy to create webrevs for any of them. > > Vladimir, maybe the queue simplifies reviewing the port, as the changes > are more complete. They include all later improvements by fixes or > adaptions in merge changes. > For why and where I renamed PPC to PPC32 see the second change in the > queue. > > Best regards, > Goetz. > > > PS: This can be used as the invokedynamic repository: > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot ppc-hotspot > hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot stage-hotspot > cd stage-hotspot > ln -s .../ppc-hotspot/ppc_patches/ .hg/patches > hg qpush -a > > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 11. Juni 2013 18:34 > To: Lindenmaier, Goetz > Cc: Volker Simonis; Azeem Jiva; Chris Plummer > Subject: Re: JEP 175 - Review comments > > Here is result of my first attempt to build/test ppc changes together > with our closed sources. > > Small problems: > > src/share/vm/memory/allocation.hpp:209: Trailing whitespace > src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace > src/share/vm/opto/escape.cpp:2207: Trailing whitespace > src/share/vm/memory/allocation.hpp:212: Trailing whitespace > src/share/vm/opto/escape.cpp:2214: Trailing whitespace > > Build on MacOS: > > src/share/vm/opto/callGenerator.cpp: In member function 'virtual > JVMState* VirtualCallGenerator::generate(JVMState*)': > src/share/vm/opto/callGenerator.cpp:204: error: > 'zero_page_read_protected' is not a member of 'os' > > agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error UNSUPPORTED_ARCH > > > We have several conflict with closed sources builds: > > src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool > ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': > src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between > signed and unsigned integer expressions > src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between > signed and unsigned integer expressions > > error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' > member function declared in class 'frame' > > error: no matching function for call to > 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' > > I think it is due to changes like next: > > -#ifdef PPC > +#ifdef PPC32 > oop* interpreter_frame_mirror_addr() const; > > > Next is easy fix in our closed sources but it requires efforts from our > side: > > src/share/vm/prims/methodHandles.cpp: In static member function 'static > void MethodHandles::generate_adapters()': > src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' > cannot be used as a function > src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' > cannot be used as a function > > > I would suggest to do such shared changes which affects different builds > later after initial push. > > > Thanks, > Vladimir > > On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I updated the repo to jdk8-b92. Our nightly tests built and >> tested it successfully. In case you experience any problems >> please tell me the details so I can fix them. >> >> Best regards, >> Goetz. >> >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 4. Juni 2013 20:58 >> To: Simonis, Volker >> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan Bateman >> Subject: Re: JEP 175 - Review comments >> >> Volker, >> >> Can you or someone update >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >> I just tried to merge them and build Hotspot on x86 without success. >> >> Thanks, >> Vladimir >> >> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>> >>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in the >>> beginning to address a broader audience for the initial discussions. >>> >>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>> >>> Regards, >>> Volker >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>> iris.clark at oracle.com >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> Sorry about this, one more thing about the JEP... >>> >>> I think that the "Discussion" list probably needs to be updated to be >>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>> as porters-dev. >>> >>> Thanks, >>> >>> iris >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi Iris, >>> >>> you're right, the title is too clumsy - I just couldn't come up with >>> something better yesterday in the evening. >>> >>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take it. >>> >>> Thanks, >>> Volker >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>> >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> I've just updated the JEP according to your suggestions. >>> >>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>> repositories" in the revised title is not ideal: >>> >>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>> >>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>> >>> @@ -1,5 +1,5 @@ >>> >>> JEP: 175 >>> >>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>> >>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master repositories >>> >>> Author: Volker Simonis >>> >>> Organization: SAP AG >>> >>> Created: 2013/1/11 >>> >>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>> about adding features to JDK Release Projects. There are lots of >>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>> additional details. >>> >>> Perhaps others have suggestions? >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> Yes. Once that field is populated, the value will appear in the JEP >>> index [1], see the third column. >>> >>> Thanks, >>> >>> Iris >>> >>> [1]: http://openjdk.java.net/jeps/0 >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Monday, June 03, 2013 10:10 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, >>> >>> I've just updated the JEP according to your suggestions. Please find >>> the new version attached to this mail (I haven't checked the new version >>> in until now to give everybody a chance to comment on the changes). >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> In addition to the changes proposed by you I've added the contents of >>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>> to the JEP. >>> >>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>> Azeems "PPCAIX plan" document. >>> >>> @Iris: could you please somehow arrange to give Azeem editing rights to >>> that page? >>> >>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>> plan" into that page (once you have the appropriate rights)? I saw that >>> the document is created from an Atlassian Confluence Wiki anyway and in >>> my unlimited naivety I imagine this could be a simple copy-and-paste >>> operation:) If that doesn't work so easily, please let me know how I >>> could help. >>> >>> If there are no objections I plan to checkin the new version of the JEP >>> tomorrow after our telephone call. >>> >>> Thank you and best regards, >>> Volker >>> >>> [2]: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Friday, May 31, 2013 8:48 PM >>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* iris.clark at oracle.com ; Alan >>> Bateman; Vladimir Kozlov >>> *Subject:* JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>> >>> http://openjdk.java.net/jeps/175 >>> >>> We're actively working to get your JEP to Funded. We had a few comments: >>> >>> -Recommend that "8" be removed from the JEP title, etc. >>> >>> -Recommend that the first Motivation bullet clearly indicate that it is >>> only covering PPC/AIX. >>> >>> -Recommend that the second Motivation bullet be modified to make it >>> clear that it applies to Hotspot only. >>> >>> (Instructions for editing the JEP may be found in the "Mechanics" >>> section at the bottom of JEP 1 [1].) >>> >>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>> be the JEP's reviewers. Once they're satisfied with your >>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" line. >>> >>> Thanks, >>> >>> Iris Clark >>> >>> [1]: http://openjdk.java.net/jeps/1 >>> From xiaoran at x1a0ran.com Wed Jun 12 09:55:38 2013 From: xiaoran at x1a0ran.com (Xiaoran Wang) Date: Wed, 12 Jun 2013 09:55:38 -0700 Subject: NoClassDef error when trying to preload additional class in systemDirectory::initialize_preloaded_classes() In-Reply-To: <0AA02107-3998-454B-9B36-2DFE2122F550@oracle.com> References: <51B6BF25.2050409@oracle.com> <6B225E88-E19B-40DD-8E9B-EB4D41203D5E@oracle.com> <0AA02107-3998-454B-9B36-2DFE2122F550@oracle.com> Message-ID: I tried to build hotspot 7u6 with bootjdk 7u6, but it still gave me the same error. The ONLY change that I made was to src/share/classfile/vmSymbols.hpp:112 I added a new line "template(foo_bar, "foo/bar") \" and that's it. Without that change hotspot was built fine and no error from test_gamma. Any thought? On Tue, Jun 11, 2013 at 9:16 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On Jun 11, 2013, at 7:45 PM, Xiaoran Wang wrote: > > Thanks Christian. So I guess the best way would be to download jdk8 and > build it without changes, and then instrument the hotspot JVM and build it > with the jdk8 that's just built? > > > An easier way would be to use the same JDK you are building for as boot > JDK. > > -- Chris > > > > On Tue, Jun 11, 2013 at 7:19 PM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > >> >> On Jun 11, 2013, at 2:06 PM, Xiaoran Wang wrote: >> >> > I'm building openjdk 7u6 with ALT_BOOTDIR set to jdk7u21 downloaded from >> > java.com, but it still gave me weird build errors. So I removed all my >> > changes, and only added one symbol to vmSymbol.hpp, and then it gave me >> an >> > error again. >> > >> > added line:vmSymbol.hpp >> > template(foo_bar, "foo/bar") >> \ >> > >> > cd linux_amd64_compiler2/product && ./test_gamma >> > Using java runtime at: /usr/lib/jvm/jdk1.7.0_21/jre >> >> That's a long standing problem which we fixed in the 8 repositories: >> test_gamma runs with the boot JDK. >> >> In your case you are trying to run a HotSpot version from 7u6 with a 7u21 >> JDK. Mix-and-match is not supported and may lead to problems like this. >> >> -- Chris >> >> > Error occurred during initialization of VM >> > java.lang.InternalError >> > at sun.misc.Launcher.getFileURL(Launcher.java:463) >> > at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:192) >> > at sun.misc.Launcher$ExtClassLoader.(Launcher.java:164) >> > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:148) >> > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:142) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at >> sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:141) >> > at sun.misc.Launcher.(Launcher.java:71) >> > at sun.misc.Launcher.(Launcher.java:57) >> > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1486) >> > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1468) >> > >> > So where seems to be the problem? >> > >> > >> > >> > >> > On Mon, Jun 10, 2013 at 11:09 PM, David Holmes > >wrote: >> > >> >> What version of hotspot are you building? If it is current sources then >> >> you will need a JDK7 import JDK or even JDK8. You can't take current >> >> hotspot and place into a 6u JDK for example. >> >> >> >> David >> >> >> >> >> >> On 9/06/2013 6:06 AM, Xiaoran Wang wrote: >> >> >> >>> To followup, I tried to put foo/bar.class into >> $JAVA_HOME/jre/classes, now >> >>> the linux_amd64_compiler2/product/**test_gamma passed without error, >> but >> >>> another error occured from linux_amd64_compiler2/jvmg/**test_gamma, >> >>> which is >> >>> even more confusing. >> >>> >> >>> cd linux_amd64_compiler2/jvmg && ./test_gamma >> >>> java full version "1.6.0_22-b04" >> >>> Using java runtime at: /home/Documents/tools/hotspot-** >> >>> working-dir/java/jre >> >>> Error occurred during initialization of VM >> >>> java.lang.**NoSuchMethodException: java.lang.reflect.Method.**invoke >> >>> >> >>> >> >>> Can someone shed some light please? >> >>> >> >>> >> >>> On Sat, Jun 8, 2013 at 12:32 PM, Xiaoran Wang >> >>> wrote: >> >>> >> >>> Hi all, >> >>>> >> >>>> I'm instrumenting the hotspot JVM for research purposes and one of >> the >> >>>> steps is to preload some classes during JVM startup time so that I >> can >> >>>> use >> >>>> its KlassOop/KlassHandle later in the template Interpreter. >> >>>> >> >>>> I appended the new classes I wanted to load in systemDirectory.hpp, >> e.g. >> >>>> *template(bar_klass, foo_bar, Pre) \* >> >>>> >> >>>> And its corresponding symbol in vmSymbols.hpp >> >>>> *template(foo_bar, "foo/bar")\* >> >>>> >> >>>> >> >>>> Then I put foo/bar.class into the corresponding rt.jar that will be >> used >> >>>> to build libjvm.so. >> >>>> >> >>>> However, when I built it, the "gamma" test always gives me an >> >>>> NoClassDefFoundError. >> >>>> >> >>>> cd linux_amd64_compiler2/product && ./test_gamma >> >>>> java full version "1.6.0_22-b04" >> >>>> Using java runtime at: /home/Documents/tools/hotspot-** >> >>>> working-dir/java/jre >> >>>> Error occurred during initialization of VM >> >>>> java/lang/**NoClassDefFoundError: foo/bar >> >>>> >> >>>> >> >>>> So my question is where should I put my custom class so that it can >> be >> >>>> preloaded during JVM startup in >> >>>> systemDirectory::initialize_**preloaded_classes? >> >>>> >> >>>> btw, I verified the rt.jar is the one JVM is loading because I tried >> to >> >>>> remove java/lang/Object from it and it complained about missing that >> >>>> class >> >>>> as well. >> >>>> >> >>>> Thank you >> >>>> Xiaoran >> >>>> >> >>>> >> >> > > From vladimir.kozlov at oracle.com Wed Jun 12 10:18:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2013 10:18:38 -0700 Subject: JEP 175 - Review comments In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDA667@DEWDFEMB12A.global.corp.sap> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B88D89.1070802@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA667@DEWDFEMB12A.global.corp.sap> Message-ID: <51B8AD6E.9020500@oracle.com> Thanks, Goetz I am perfectly fine with such granularity and I can start generating RFEs. I filed first: 8016476: PPC64 (part 1): reenable CORE build Are you sure that 0001_fix_core_build.patch is complete? I can't build it on my Mac: gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. gnumake[3]: *** [dtrace_stuff] Error 2 gnumake[2]: *** [debugcore] Error 2 gnumake[1]: *** [generic_buildcore] Error 2 gnumake: *** [debugcore] Error 2 And on SPARC: src/share/vm/runtime/globals.hpp", line 170: Error: Multiple declaration for pd_InlineSmallCode. And you should used debugcore instead of jvmgcore: +all_debugcore: jvmgcore docs export_debug I want your changes be perfect from the start ;) And I need to discuss with our embedded group about 0002_PPC_defines.patch because it affects them. It may take time. Thanks, Vladimir On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > yes, the plan is that each is self contained. When I set up the patches I > built and jckecked each. When I updated them I only built them selectively, > so there might be minor issues. I had planned to assure this once I make > webrevs from the patches. > > Some of them might apply in any order, but others depend on previous ones, > e.g., 0009 containing the ppc files will not work without the changes before. > > The patches work with hs25-b34. > > Please tell me if I can do anything to ease your reviewing. > > Ah, I just saw your mail about closed code ... I tried to keep > changes necessary to other platform code to a minimum, but also tried > to avoid strange workarounds. Therefore I for example did change 0002 > renaming the PPC defines, see the comment there. > > If you agree with the granularity of the changes, it would be great if you > could generate bug-ids for them. Maybe at least for the changes > up to 0016? > > Best regards > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 12. Juni 2013 17:03 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer > Subject: Re: JEP 175 - Review comments > > Thank you, Goetz. > > Can I review just 1 patch (for example, 1 from first 1-9), merge it with jdk8 and build? Or I should do review all 1-9 > patches and merge them together into jdk8 to be able build? In short, is each patch self-contain? > > Thanks, > Vladimir > > On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> With my recent changes I removed some of the problems Vladimir mentioned. >> >> I also added the patches queue I maintain into our jdk8/hotspot repository, >> at hotspot/ppc_patches. >> Applied to the staging hotspot directory, the linuxppc and aixppc hotspots >> can be built. >> >> The queue contains the changes proposed by me before, with minor changes due >> to recent development: >> >> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >> 101-107 C-interpreter improvements >> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >> 200-217 C2 compiler fixes, extensions etc needed for a stable and >> performant ppc port. >> Altogether currently 49 changes. >> >> Our plan was to propose the changes in the order of the queue for >> review. I'm happy to create webrevs for any of them. >> >> Vladimir, maybe the queue simplifies reviewing the port, as the changes >> are more complete. They include all later improvements by fixes or >> adaptions in merge changes. >> For why and where I renamed PPC to PPC32 see the second change in the >> queue. >> >> Best regards, >> Goetz. >> >> >> PS: This can be used as the invokedynamic repository: >> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot ppc-hotspot >> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot stage-hotspot >> cd stage-hotspot >> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >> hg qpush -a >> >> >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 11. Juni 2013 18:34 >> To: Lindenmaier, Goetz >> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >> Subject: Re: JEP 175 - Review comments >> >> Here is result of my first attempt to build/test ppc changes together >> with our closed sources. >> >> Small problems: >> >> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >> >> Build on MacOS: >> >> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >> JVMState* VirtualCallGenerator::generate(JVMState*)': >> src/share/vm/opto/callGenerator.cpp:204: error: >> 'zero_page_read_protected' is not a member of 'os' >> >> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error UNSUPPORTED_ARCH >> >> >> We have several conflict with closed sources builds: >> >> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >> signed and unsigned integer expressions >> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >> signed and unsigned integer expressions >> >> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >> member function declared in class 'frame' >> >> error: no matching function for call to >> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >> >> I think it is due to changes like next: >> >> -#ifdef PPC >> +#ifdef PPC32 >> oop* interpreter_frame_mirror_addr() const; >> >> >> Next is easy fix in our closed sources but it requires efforts from our >> side: >> >> src/share/vm/prims/methodHandles.cpp: In static member function 'static >> void MethodHandles::generate_adapters()': >> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >> cannot be used as a function >> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >> cannot be used as a function >> >> >> I would suggest to do such shared changes which affects different builds >> later after initial push. >> >> >> Thanks, >> Vladimir >> >> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I updated the repo to jdk8-b92. Our nightly tests built and >>> tested it successfully. In case you experience any problems >>> please tell me the details so I can fix them. >>> >>> Best regards, >>> Goetz. >>> >>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 4. Juni 2013 20:58 >>> To: Simonis, Volker >>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan Bateman >>> Subject: Re: JEP 175 - Review comments >>> >>> Volker, >>> >>> Can you or someone update >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>> I just tried to merge them and build Hotspot on x86 without success. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>> >>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in the >>>> beginning to address a broader audience for the initial discussions. >>>> >>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>> iris.clark at oracle.com >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> Sorry about this, one more thing about the JEP... >>>> >>>> I think that the "Discussion" list probably needs to be updated to be >>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>> as porters-dev. >>>> >>>> Thanks, >>>> >>>> iris >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi Iris, >>>> >>>> you're right, the title is too clumsy - I just couldn't come up with >>>> something better yesterday in the evening. >>>> >>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take it. >>>> >>>> Thanks, >>>> Volker >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>> >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> I've just updated the JEP according to your suggestions. >>>> >>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>> repositories" in the revised title is not ideal: >>>> >>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>> >>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>> >>>> @@ -1,5 +1,5 @@ >>>> >>>> JEP: 175 >>>> >>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master repositories >>>> >>>> Author: Volker Simonis >>>> >>>> Organization: SAP AG >>>> >>>> Created: 2013/1/11 >>>> >>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>> about adding features to JDK Release Projects. There are lots of >>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>> additional details. >>>> >>>> Perhaps others have suggestions? >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> Yes. Once that field is populated, the value will appear in the JEP >>>> index [1], see the third column. >>>> >>>> Thanks, >>>> >>>> Iris >>>> >>>> [1]: http://openjdk.java.net/jeps/0 >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, >>>> >>>> I've just updated the JEP according to your suggestions. Please find >>>> the new version attached to this mail (I haven't checked the new version >>>> in until now to give everybody a chance to comment on the changes). >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> In addition to the changes proposed by you I've added the contents of >>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>> to the JEP. >>>> >>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>> Azeems "PPCAIX plan" document. >>>> >>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>> that page? >>>> >>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>> plan" into that page (once you have the appropriate rights)? I saw that >>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>> operation:) If that doesn't work so easily, please let me know how I >>>> could help. >>>> >>>> If there are no objections I plan to checkin the new version of the JEP >>>> tomorrow after our telephone call. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> [2]: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* iris.clark at oracle.com ; Alan >>>> Bateman; Vladimir Kozlov >>>> *Subject:* JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> http://openjdk.java.net/jeps/175 >>>> >>>> We're actively working to get your JEP to Funded. We had a few comments: >>>> >>>> -Recommend that "8" be removed from the JEP title, etc. >>>> >>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>> only covering PPC/AIX. >>>> >>>> -Recommend that the second Motivation bullet be modified to make it >>>> clear that it applies to Hotspot only. >>>> >>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>> section at the bottom of JEP 1 [1].) >>>> >>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>> be the JEP's reviewers. Once they're satisfied with your >>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" line. >>>> >>>> Thanks, >>>> >>>> Iris Clark >>>> >>>> [1]: http://openjdk.java.net/jeps/1 >>>> From volker.simonis at gmail.com Wed Jun 12 11:51:21 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 12 Jun 2013 20:51:21 +0200 Subject: JEP 175 - Review comments In-Reply-To: <51B8AD6E.9020500@oracle.com> References: <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B88D89.1070802@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA667@DEWDFEMB12A.global.corp.sap> <51B8AD6E.9020500@oracle.com> Message-ID: On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov wrote: > Thanks, Goetz > > I am perfectly fine with such granularity and I can start generating RFEs. > I filed first: > > 8016476: PPC64 (part 1): reenable CORE build > > Thanks! > Are you sure that 0001_fix_core_build.patch is complete? I can't build it > on my Mac: > > We haven't fixed the CORE build on all platforms. It should wok on Linux/PPC64 and AIX/PPC64 and not break anything else. This is the general approach we have taken. So I'm not sure what will be the best way for you to review the changes. But all of the patches from the first series of changes (1-9) won't probably do anything useful on Linux/x86 and Solaris because we haven't fixed the CORE build and the C++ interpreter on that platforms. So building a CORE build or the C++ interpreter on Linux/x86, Solaris or Mac will probably not succeed (and was not the scope of this project). I think the review for these patches should only make sure that they don't break anything that worked before an any supported platforms (and trust us that they are good for our platforms:). So in that sense "reenable CORE build" only means to provide the appropriate targets in the Makefiles and not the required source code fixes on all platforms (although they may be trivial/minimal). But if you'd absolutely also want to have a core build on Linux/x86 and Solaris, I can have a look at it. gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. > gnumake[3]: *** [dtrace_stuff] Error 2 > gnumake[2]: *** [debugcore] Error 2 > gnumake[1]: *** [generic_buildcore] Error 2 > gnumake: *** [debugcore] Error 2 > > And on SPARC: > > src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple > declaration for pd_InlineSmallCode. > > And you should used debugcore instead of jvmgcore: > +all_debugcore: jvmgcore docs export_debug > > I want your changes be perfect from the start ;) > You're right. The renaming of the 'jvmg' target to 'debug' has happened recently ( http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and we haven't adapted it. We will fix this. > And I need to discuss with our embedded group about 0002_PPC_defines.patch > because it affects them. It may take time. > > Thanks, > Vladimir > > > On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: > >> Hi Vladimir, >> >> yes, the plan is that each is self contained. When I set up the patches I >> built and jckecked each. When I updated them I only built them >> selectively, >> so there might be minor issues. I had planned to assure this once I make >> webrevs from the patches. >> >> Some of them might apply in any order, but others depend on previous ones, >> e.g., 0009 containing the ppc files will not work without the changes >> before. >> >> The patches work with hs25-b34. >> >> Please tell me if I can do anything to ease your reviewing. >> >> Ah, I just saw your mail about closed code ... I tried to keep >> changes necessary to other platform code to a minimum, but also tried >> to avoid strange workarounds. Therefore I for example did change 0002 >> renaming the PPC defines, see the comment there. >> >> If you agree with the granularity of the changes, it would be great if you >> could generate bug-ids for them. Maybe at least for the changes >> up to 0016? >> >> Best regards >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov@**oracle.com >> ] >> Sent: Mittwoch, 12. Juni 2013 17:03 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.**net; >> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer >> Subject: Re: JEP 175 - Review comments >> >> Thank you, Goetz. >> >> Can I review just 1 patch (for example, 1 from first 1-9), merge it with >> jdk8 and build? Or I should do review all 1-9 >> patches and merge them together into jdk8 to be able build? In short, is >> each patch self-contain? >> >> Thanks, >> Vladimir >> >> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >> >>> Hi, >>> >>> With my recent changes I removed some of the problems Vladimir mentioned. >>> >>> I also added the patches queue I maintain into our jdk8/hotspot >>> repository, >>> at hotspot/ppc_patches. >>> Applied to the staging hotspot directory, the linuxppc and aixppc >>> hotspots >>> can be built. >>> >>> The queue contains the changes proposed by me before, with minor changes >>> due >>> to recent development: >>> >>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>> 101-107 C-interpreter improvements >>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>> performant ppc port. >>> Altogether currently 49 changes. >>> >>> Our plan was to propose the changes in the order of the queue for >>> review. I'm happy to create webrevs for any of them. >>> >>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>> are more complete. They include all later improvements by fixes or >>> adaptions in merge changes. >>> For why and where I renamed PPC to PPC32 see the second change in the >>> queue. >>> >>> Best regards, >>> Goetz. >>> >>> >>> PS: This can be used as the invokedynamic repository: >>> hg clone http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot ppc-hotspot >>> hg clone http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>> cd stage-hotspot >>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>> hg qpush -a >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov@**oracle.com >>> ] >>> Sent: Dienstag, 11. Juni 2013 18:34 >>> To: Lindenmaier, Goetz >>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>> Subject: Re: JEP 175 - Review comments >>> >>> Here is result of my first attempt to build/test ppc changes together >>> with our closed sources. >>> >>> Small problems: >>> >>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>> >>> Build on MacOS: >>> >>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>> src/share/vm/opto/**callGenerator.cpp:204: error: >>> 'zero_page_read_protected' is not a member of 'os' >>> >>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>> UNSUPPORTED_ARCH >>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>> UNSUPPORTED_ARCH >>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>> UNSUPPORTED_ARCH >>> >>> >>> We have several conflict with closed sources builds: >>> >>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function 'bool >>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>> between >>> signed and unsigned integer expressions >>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>> between >>> signed and unsigned integer expressions >>> >>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>> member function declared in class 'frame' >>> >>> error: no matching function for call to >>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, uint&)' >>> >>> I think it is due to changes like next: >>> >>> -#ifdef PPC >>> +#ifdef PPC32 >>> oop* interpreter_frame_mirror_addr(**) const; >>> >>> >>> Next is easy fix in our closed sources but it requires efforts from our >>> side: >>> >>> src/share/vm/prims/**methodHandles.cpp: In static member function >>> 'static >>> void MethodHandles::generate_**adapters()': >>> src/share/vm/prims/**methodHandles.cpp:68: error: 'adapter_code_size' >>> cannot be used as a function >>> src/share/vm/prims/**methodHandles.cpp:70: error: 'adapter_code_size' >>> cannot be used as a function >>> >>> >>> I would suggest to do such shared changes which affects different builds >>> later after initial push. >>> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>> >>>> Hi Vladimir, >>>> >>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>> tested it successfully. In case you experience any problems >>>> please tell me the details so I can fix them. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov@**oracle.com >>>> ] >>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>> To: Simonis, Volker >>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; >>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>> Bateman >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Volker, >>>> >>>> Can you or someone update >>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto match latest >>>> sources in http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>> ? >>>> I just tried to merge them and build Hotspot on x86 without success. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>> >>>>> >>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>> the >>>>> beginning to address a broader audience for the initial discussions. >>>>> >>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> ------------------------------**------------------------------** >>>>> ------------ >>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>> iris.clark at oracle.com >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> Sorry about this, one more thing about the JEP... >>>>> >>>>> I think that the "Discussion" list probably needs to be updated to be >>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>> as porters-dev. >>>>> >>>>> Thanks, >>>>> >>>>> iris >>>>> >>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi Iris, >>>>> >>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>> something better yesterday in the evening. >>>>> >>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>> it. >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> ------------------------------**------------------------------** >>>>> ------------ >>>>> >>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>> >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> I've just updated the JEP according to your suggestions. >>>>> >>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>> repositories" in the revised title is not ideal: >>>>> >>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>> >>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>> >>>>> @@ -1,5 +1,5 @@ >>>>> >>>>> JEP: 175 >>>>> >>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>> >>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>> repositories >>>>> >>>>> Author: Volker Simonis >>>>> >>>>> Organization: SAP AG >>>>> >>>>> Created: 2013/1/11 >>>>> >>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>> about adding features to JDK Release Projects. There are lots of >>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>> additional details. >>>>> >>>>> Perhaps others have suggestions? >>>>> >>>>> Am I right with my assumption that the targeted release will still be >>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>> specified in the JEP specification)? >>>>> >>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>> index [1], see the third column. >>>>> >>>>> Thanks, >>>>> >>>>> Iris >>>>> >>>>> [1]: http://openjdk.java.net/jeps/0 >>>>> >>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, >>>>> >>>>> I've just updated the JEP according to your suggestions. Please find >>>>> the new version attached to this mail (I haven't checked the new >>>>> version >>>>> in until now to give everybody a chance to comment on the changes). >>>>> >>>>> Am I right with my assumption that the targeted release will still be >>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>> specified in the JEP specification)? >>>>> >>>>> In addition to the changes proposed by you I've added the contents of >>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>> to the JEP. >>>>> >>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>> Azeems "PPCAIX plan" document. >>>>> >>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>> that page? >>>>> >>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>> operation:) If that doesn't work so easily, please let me know how I >>>>> could help. >>>>> >>>>> If there are no objections I plan to checkin the new version of the JEP >>>>> tomorrow after our telephone call. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> [2]: https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>> 13729959 >>>>> [3]: https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>> >>>>> ------------------------------**------------------------------** >>>>> ------------ >>>>> >>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>> Bateman; Vladimir Kozlov >>>>> *Subject:* JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>> >>>>> http://openjdk.java.net/jeps/**175 >>>>> >>>>> We're actively working to get your JEP to Funded. We had a few >>>>> comments: >>>>> >>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>> >>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>> only covering PPC/AIX. >>>>> >>>>> -Recommend that the second Motivation bullet be modified to make it >>>>> clear that it applies to Hotspot only. >>>>> >>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>> section at the bottom of JEP 1 [1].) >>>>> >>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>> be the JEP's reviewers. Once they're satisfied with your >>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>> line. >>>>> >>>>> Thanks, >>>>> >>>>> Iris Clark >>>>> >>>>> [1]: http://openjdk.java.net/jeps/1 >>>>> >>>>> From vladimir.kozlov at oracle.com Wed Jun 12 12:18:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2013 12:18:47 -0700 Subject: JEP 175 - Review comments In-Reply-To: References: <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B88D89.1070802@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA667@DEWDFEMB12A.global.corp.sap> <51B8AD6E.9020500@oracle.com> Message-ID: <51B8C997.2090103@oracle.com> Okay, I will add comment to the rfe that CORE target is only used on Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for now). Vladimir On 6/12/13 11:51 AM, Volker Simonis wrote: > On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov > wrote: > >> Thanks, Goetz >> >> I am perfectly fine with such granularity and I can start generating RFEs. >> I filed first: >> >> 8016476: PPC64 (part 1): reenable CORE build >> >> > Thanks! > > >> Are you sure that 0001_fix_core_build.patch is complete? I can't build it >> on my Mac: >> >> > We haven't fixed the CORE build on all platforms. It should wok on > Linux/PPC64 and AIX/PPC64 and not break anything else. > > This is the general approach we have taken. So I'm not sure what will be > the best way for you to review the changes. But all of the patches from the > first series of changes (1-9) won't probably do anything useful on > Linux/x86 and Solaris because we haven't fixed the CORE build and the C++ > interpreter on that platforms. So building a CORE build or the C++ > interpreter on Linux/x86, Solaris or Mac will probably not succeed (and was > not the scope of this project). > > I think the review for these patches should only make sure that they don't > break anything that worked before an any supported platforms (and trust us > that they are good for our platforms:). > > So in that sense "reenable CORE build" only means to provide the > appropriate targets in the Makefiles and not the required source code fixes > on all platforms (although they may be trivial/minimal). But if you'd > absolutely also want to have a core build on Linux/x86 and Solaris, I can > have a look at it. > > gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >> gnumake[3]: *** [dtrace_stuff] Error 2 >> gnumake[2]: *** [debugcore] Error 2 >> gnumake[1]: *** [generic_buildcore] Error 2 >> gnumake: *** [debugcore] Error 2 >> >> And on SPARC: >> >> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >> declaration for pd_InlineSmallCode. >> >> And you should used debugcore instead of jvmgcore: >> +all_debugcore: jvmgcore docs export_debug >> >> I want your changes be perfect from the start ;) >> > > You're right. The renaming of the 'jvmg' target to 'debug' has happened > recently ( > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and > we haven't adapted it. We will fix this. > > >> And I need to discuss with our embedded group about 0002_PPC_defines.patch >> because it affects them. It may take time. >> >> Thanks, >> Vladimir >> >> >> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >> >>> Hi Vladimir, >>> >>> yes, the plan is that each is self contained. When I set up the patches I >>> built and jckecked each. When I updated them I only built them >>> selectively, >>> so there might be minor issues. I had planned to assure this once I make >>> webrevs from the patches. >>> >>> Some of them might apply in any order, but others depend on previous ones, >>> e.g., 0009 containing the ppc files will not work without the changes >>> before. >>> >>> The patches work with hs25-b34. >>> >>> Please tell me if I can do anything to ease your reviewing. >>> >>> Ah, I just saw your mail about closed code ... I tried to keep >>> changes necessary to other platform code to a minimum, but also tried >>> to avoid strange workarounds. Therefore I for example did change 0002 >>> renaming the PPC defines, see the comment there. >>> >>> If you agree with the granularity of the changes, it would be great if you >>> could generate bug-ids for them. Maybe at least for the changes >>> up to 0016? >>> >>> Best regards >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov@**oracle.com >>> ] >>> Sent: Mittwoch, 12. Juni 2013 17:03 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.**net; >>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer >>> Subject: Re: JEP 175 - Review comments >>> >>> Thank you, Goetz. >>> >>> Can I review just 1 patch (for example, 1 from first 1-9), merge it with >>> jdk8 and build? Or I should do review all 1-9 >>> patches and merge them together into jdk8 to be able build? In short, is >>> each patch self-contain? >>> >>> Thanks, >>> Vladimir >>> >>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>> >>>> Hi, >>>> >>>> With my recent changes I removed some of the problems Vladimir mentioned. >>>> >>>> I also added the patches queue I maintain into our jdk8/hotspot >>>> repository, >>>> at hotspot/ppc_patches. >>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>> hotspots >>>> can be built. >>>> >>>> The queue contains the changes proposed by me before, with minor changes >>>> due >>>> to recent development: >>>> >>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>> 101-107 C-interpreter improvements >>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>> performant ppc port. >>>> Altogether currently 49 changes. >>>> >>>> Our plan was to propose the changes in the order of the queue for >>>> review. I'm happy to create webrevs for any of them. >>>> >>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>>> are more complete. They include all later improvements by fixes or >>>> adaptions in merge changes. >>>> For why and where I renamed PPC to PPC32 see the second change in the >>>> queue. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> PS: This can be used as the invokedynamic repository: >>>> hg clone http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot ppc-hotspot >>>> hg clone http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>> cd stage-hotspot >>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>> hg qpush -a >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov@**oracle.com >>>> ] >>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>> To: Lindenmaier, Goetz >>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Here is result of my first attempt to build/test ppc changes together >>>> with our closed sources. >>>> >>>> Small problems: >>>> >>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>> >>>> Build on MacOS: >>>> >>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>> 'zero_page_read_protected' is not a member of 'os' >>>> >>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>> UNSUPPORTED_ARCH >>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>> UNSUPPORTED_ARCH >>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>> UNSUPPORTED_ARCH >>>> >>>> >>>> We have several conflict with closed sources builds: >>>> >>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function 'bool >>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>> between >>>> signed and unsigned integer expressions >>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>> between >>>> signed and unsigned integer expressions >>>> >>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>> member function declared in class 'frame' >>>> >>>> error: no matching function for call to >>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, uint&)' >>>> >>>> I think it is due to changes like next: >>>> >>>> -#ifdef PPC >>>> +#ifdef PPC32 >>>> oop* interpreter_frame_mirror_addr(**) const; >>>> >>>> >>>> Next is easy fix in our closed sources but it requires efforts from our >>>> side: >>>> >>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>> 'static >>>> void MethodHandles::generate_**adapters()': >>>> src/share/vm/prims/**methodHandles.cpp:68: error: 'adapter_code_size' >>>> cannot be used as a function >>>> src/share/vm/prims/**methodHandles.cpp:70: error: 'adapter_code_size' >>>> cannot be used as a function >>>> >>>> >>>> I would suggest to do such shared changes which affects different builds >>>> later after initial push. >>>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>> >>>>> Hi Vladimir, >>>>> >>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>> tested it successfully. In case you experience any problems >>>>> please tell me the details so I can fix them. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov@**oracle.com >>>>> ] >>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>> To: Simonis, Volker >>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; >>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>> Bateman >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Volker, >>>>> >>>>> Can you or someone update >>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto match latest >>>>> sources in http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>> ? >>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>> >>>>>> >>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>> the >>>>>> beginning to address a broader audience for the initial discussions. >>>>>> >>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> ------------------------------**------------------------------** >>>>>> ------------ >>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>> iris.clark at oracle.com >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> Sorry about this, one more thing about the JEP... >>>>>> >>>>>> I think that the "Discussion" list probably needs to be updated to be >>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>>> as porters-dev. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> iris >>>>>> >>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi Iris, >>>>>> >>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>> something better yesterday in the evening. >>>>>> >>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>> it. >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> ------------------------------**------------------------------** >>>>>> ------------ >>>>>> >>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>> >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> I've just updated the JEP according to your suggestions. >>>>>> >>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>> repositories" in the revised title is not ideal: >>>>>> >>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>> >>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>> >>>>>> @@ -1,5 +1,5 @@ >>>>>> >>>>>> JEP: 175 >>>>>> >>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>> >>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>> repositories >>>>>> >>>>>> Author: Volker Simonis >>>>>> >>>>>> Organization: SAP AG >>>>>> >>>>>> Created: 2013/1/11 >>>>>> >>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>> about adding features to JDK Release Projects. There are lots of >>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>> additional details. >>>>>> >>>>>> Perhaps others have suggestions? >>>>>> >>>>>> Am I right with my assumption that the targeted release will still be >>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>> specified in the JEP specification)? >>>>>> >>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>> index [1], see the third column. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Iris >>>>>> >>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>> >>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, >>>>>> >>>>>> I've just updated the JEP according to your suggestions. Please find >>>>>> the new version attached to this mail (I haven't checked the new >>>>>> version >>>>>> in until now to give everybody a chance to comment on the changes). >>>>>> >>>>>> Am I right with my assumption that the targeted release will still be >>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>> specified in the JEP specification)? >>>>>> >>>>>> In addition to the changes proposed by you I've added the contents of >>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>>> to the JEP. >>>>>> >>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>>> Azeems "PPCAIX plan" document. >>>>>> >>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>>> that page? >>>>>> >>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>> could help. >>>>>> >>>>>> If there are no objections I plan to checkin the new version of the JEP >>>>>> tomorrow after our telephone call. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> [2]: https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>> 13729959 >>>>>> [3]: https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>> >>>>>> ------------------------------**------------------------------** >>>>>> ------------ >>>>>> >>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>> Bateman; Vladimir Kozlov >>>>>> *Subject:* JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>> >>>>>> http://openjdk.java.net/jeps/**175 >>>>>> >>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>> comments: >>>>>> >>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>> >>>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>>> only covering PPC/AIX. >>>>>> >>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>> clear that it applies to Hotspot only. >>>>>> >>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>> section at the bottom of JEP 1 [1].) >>>>>> >>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>> line. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Iris Clark >>>>>> >>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>> >>>>>> From chris.plummer at oracle.com Wed Jun 12 12:54:58 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Jun 2013 12:54:58 -0700 Subject: JEP 175 - Review comments In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> Message-ID: <51B8D212.1050204@oracle.com> Hi Goetz, Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in make/linux/platform_ppc. There are a lot of PPC references in c1 that don't appear to have been addressed. Is there a reason that PPC is not also defined for both PPC32 and PPC64, allowing you to use #ifdef PPC rather than #if defined(PPC32) || defined(PPC64) best regards, Chris On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: > Hi, > > With my recent changes I removed some of the problems Vladimir mentioned. > > I also added the patches queue I maintain into our jdk8/hotspot repository, > at hotspot/ppc_patches. > Applied to the staging hotspot directory, the linuxppc and aixppc hotspots > can be built. > > The queue contains the changes proposed by me before, with minor changes due > to recent development: > > 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) > 11-15 aixppc C-interpreter port (In our plan milestone M2.2) > 101-107 C-interpreter improvements > 111-122 ppc C2 compiler port leading to a vm rudimentarily working > 200-217 C2 compiler fixes, extensions etc needed for a stable and > performant ppc port. > Altogether currently 49 changes. > > Our plan was to propose the changes in the order of the queue for > review. I'm happy to create webrevs for any of them. > > Vladimir, maybe the queue simplifies reviewing the port, as the changes > are more complete. They include all later improvements by fixes or > adaptions in merge changes. > For why and where I renamed PPC to PPC32 see the second change in the > queue. > > Best regards, > Goetz. > > > PS: This can be used as the invokedynamic repository: > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot ppc-hotspot > hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot stage-hotspot > cd stage-hotspot > ln -s .../ppc-hotspot/ppc_patches/ .hg/patches > hg qpush -a > > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 11. Juni 2013 18:34 > To: Lindenmaier, Goetz > Cc: Volker Simonis; Azeem Jiva; Chris Plummer > Subject: Re: JEP 175 - Review comments > > Here is result of my first attempt to build/test ppc changes together > with our closed sources. > > Small problems: > > src/share/vm/memory/allocation.hpp:209: Trailing whitespace > src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace > src/share/vm/opto/escape.cpp:2207: Trailing whitespace > src/share/vm/memory/allocation.hpp:212: Trailing whitespace > src/share/vm/opto/escape.cpp:2214: Trailing whitespace > > Build on MacOS: > > src/share/vm/opto/callGenerator.cpp: In member function 'virtual > JVMState* VirtualCallGenerator::generate(JVMState*)': > src/share/vm/opto/callGenerator.cpp:204: error: > 'zero_page_read_protected' is not a member of 'os' > > agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error UNSUPPORTED_ARCH > > > We have several conflict with closed sources builds: > > src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool > ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': > src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between > signed and unsigned integer expressions > src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between > signed and unsigned integer expressions > > error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' > member function declared in class 'frame' > > error: no matching function for call to > 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' > > I think it is due to changes like next: > > -#ifdef PPC > +#ifdef PPC32 > oop* interpreter_frame_mirror_addr() const; > > > Next is easy fix in our closed sources but it requires efforts from our > side: > > src/share/vm/prims/methodHandles.cpp: In static member function 'static > void MethodHandles::generate_adapters()': > src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' > cannot be used as a function > src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' > cannot be used as a function > > > I would suggest to do such shared changes which affects different builds > later after initial push. > > > Thanks, > Vladimir > > On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I updated the repo to jdk8-b92. Our nightly tests built and >> tested it successfully. In case you experience any problems >> please tell me the details so I can fix them. >> >> Best regards, >> Goetz. >> >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 4. Juni 2013 20:58 >> To: Simonis, Volker >> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan Bateman >> Subject: Re: JEP 175 - Review comments >> >> Volker, >> >> Can you or someone update >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >> I just tried to merge them and build Hotspot on x86 without success. >> >> Thanks, >> Vladimir >> >> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in the >>> beginning to address a broader audience for the initial discussions. >>> >>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>> >>> Regards, >>> Volker >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>> iris.clark at oracle.com >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> Sorry about this, one more thing about the JEP... >>> >>> I think that the "Discussion" list probably needs to be updated to be >>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>> as porters-dev. >>> >>> Thanks, >>> >>> iris >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi Iris, >>> >>> you're right, the title is too clumsy - I just couldn't come up with >>> something better yesterday in the evening. >>> >>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take it. >>> >>> Thanks, >>> Volker >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>> >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> I've just updated the JEP according to your suggestions. >>> >>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>> repositories" in the revised title is not ideal: >>> >>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>> >>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>> >>> @@ -1,5 +1,5 @@ >>> >>> JEP: 175 >>> >>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>> >>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master repositories >>> >>> Author: Volker Simonis >>> >>> Organization: SAP AG >>> >>> Created: 2013/1/11 >>> >>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>> about adding features to JDK Release Projects. There are lots of >>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>> additional details. >>> >>> Perhaps others have suggestions? >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> Yes. Once that field is populated, the value will appear in the JEP >>> index [1], see the third column. >>> >>> Thanks, >>> >>> Iris >>> >>> [1]: http://openjdk.java.net/jeps/0 >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Monday, June 03, 2013 10:10 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, >>> >>> I've just updated the JEP according to your suggestions. Please find >>> the new version attached to this mail (I haven't checked the new version >>> in until now to give everybody a chance to comment on the changes). >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> In addition to the changes proposed by you I've added the contents of >>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>> to the JEP. >>> >>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>> Azeems "PPCAIX plan" document. >>> >>> @Iris: could you please somehow arrange to give Azeem editing rights to >>> that page? >>> >>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>> plan" into that page (once you have the appropriate rights)? I saw that >>> the document is created from an Atlassian Confluence Wiki anyway and in >>> my unlimited naivety I imagine this could be a simple copy-and-paste >>> operation:) If that doesn't work so easily, please let me know how I >>> could help. >>> >>> If there are no objections I plan to checkin the new version of the JEP >>> tomorrow after our telephone call. >>> >>> Thank you and best regards, >>> Volker >>> >>> [2]: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Friday, May 31, 2013 8:48 PM >>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* iris.clark at oracle.com ; Alan >>> Bateman; Vladimir Kozlov >>> *Subject:* JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>> >>> http://openjdk.java.net/jeps/175 >>> >>> We're actively working to get your JEP to Funded. We had a few comments: >>> >>> -Recommend that "8" be removed from the JEP title, etc. >>> >>> -Recommend that the first Motivation bullet clearly indicate that it is >>> only covering PPC/AIX. >>> >>> -Recommend that the second Motivation bullet be modified to make it >>> clear that it applies to Hotspot only. >>> >>> (Instructions for editing the JEP may be found in the "Mechanics" >>> section at the bottom of JEP 1 [1].) >>> >>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>> be the JEP's reviewers. Once they're satisfied with your >>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" line. >>> >>> Thanks, >>> >>> Iris Clark >>> >>> [1]: http://openjdk.java.net/jeps/1 >>> From erik.helin at oracle.com Wed Jun 12 13:22:28 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Wed, 12 Jun 2013 20:22:28 +0000 Subject: hg: hsx/hsx24/hotspot: 8015683: object_count_after_gc should have the same timestamp for all events Message-ID: <20130612202232.6E012481A0@hg.openjdk.java.net> Changeset: a4c642ecf2db Author: ehelin Date: 2013-06-12 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a4c642ecf2db 8015683: object_count_after_gc should have the same timestamp for all events Reviewed-by: brutisso, stefank ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp From christian.tornqvist at oracle.com Wed Jun 12 15:29:16 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 12 Jun 2013 22:29:16 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130612222920.572E0481A2@hg.openjdk.java.net> Changeset: 7e3960aabb6c Author: ctornqvi Date: 2013-06-12 18:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7e3960aabb6c 8016065: Write regression test for 7167142 Summary: Regression tests written for both test cases (.hotspotrc and .hotspot_compiler). Also reviewed by mikhailo.seledtsov at oracle.com Reviewed-by: zgu, coleenp + test/runtime/CommandLine/CompilerConfigFileWarning.java + test/runtime/CommandLine/ConfigFileWarning.java Changeset: 520dc34d4114 Author: ctornqvi Date: 2013-06-12 22:37 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/520dc34d4114 Merge From vladimir.kozlov at oracle.com Wed Jun 12 15:57:51 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2013 15:57:51 -0700 Subject: JEP 175 - Review comments In-Reply-To: <51B8C997.2090103@oracle.com> References: <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B88D89.1070802@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA667@DEWDFEMB12A.global.corp.sap> <51B8AD6E.9020500@oracle.com> <51B8C997.2090103@oracle.com> Message-ID: <51B8FCEF.2080504@oracle.com> Hi, Volker 0001_fix_core_build.patch passed JPRT build/test run so it is good, consider reviewed (assuming you fix jvmgcore). Should we formalize the process to follow our normal openjdk review process? It will allow other people to see what is coming and to comment on it as you said and I agree. - I will file rfes and add Volker and Goetz to watch list so you get notifications (I hope) about rfes. - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail aliases. - We do reviews and small testing to make sure changes do not break our builds. - You prepare final patch with correct changeset header after we agree on changes. - I push it to staging repo. Is this acceptable to you? About changeset header: : Summary: Reviewed-by: + Contributed-by: I don't think you need "Contributed-by:" since Volker could be author. But it is up to you if you want to mention other contributors. 8016476: PPC64 (part 1): reenable CORE build Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 Reviewed-by: kvn Thanks, Vladimir PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, check that you get notification. You are on watch list. On 6/12/13 12:18 PM, Vladimir Kozlov wrote: > Okay, I will add comment to the rfe that CORE target is only used on > Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for > now). > > Vladimir > > On 6/12/13 11:51 AM, Volker Simonis wrote: >> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >> >> wrote: >> >>> Thanks, Goetz >>> >>> I am perfectly fine with such granularity and I can start generating >>> RFEs. >>> I filed first: >>> >>> 8016476: PPC64 (part 1): reenable CORE build >>> >>> >> Thanks! >> >> >>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>> build it >>> on my Mac: >>> >>> >> We haven't fixed the CORE build on all platforms. It should wok on >> Linux/PPC64 and AIX/PPC64 and not break anything else. >> >> This is the general approach we have taken. So I'm not sure what will be >> the best way for you to review the changes. But all of the patches >> from the >> first series of changes (1-9) won't probably do anything useful on >> Linux/x86 and Solaris because we haven't fixed the CORE build and the C++ >> interpreter on that platforms. So building a CORE build or the C++ >> interpreter on Linux/x86, Solaris or Mac will probably not succeed >> (and was >> not the scope of this project). >> >> I think the review for these patches should only make sure that they >> don't >> break anything that worked before an any supported platforms (and >> trust us >> that they are good for our platforms:). >> >> So in that sense "reenable CORE build" only means to provide the >> appropriate targets in the Makefiles and not the required source code >> fixes >> on all platforms (although they may be trivial/minimal). But if you'd >> absolutely also want to have a core build on Linux/x86 and Solaris, I can >> have a look at it. >> >> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>> gnumake[3]: *** [dtrace_stuff] Error 2 >>> gnumake[2]: *** [debugcore] Error 2 >>> gnumake[1]: *** [generic_buildcore] Error 2 >>> gnumake: *** [debugcore] Error 2 >>> >>> And on SPARC: >>> >>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>> declaration for pd_InlineSmallCode. >>> >>> And you should used debugcore instead of jvmgcore: >>> +all_debugcore: jvmgcore docs export_debug >>> >>> I want your changes be perfect from the start ;) >>> >> >> You're right. The renaming of the 'jvmg' target to 'debug' has happened >> recently ( >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >> we haven't adapted it. We will fix this. >> >> >>> And I need to discuss with our embedded group about >>> 0002_PPC_defines.patch >>> because it affects them. It may take time. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>> >>>> Hi Vladimir, >>>> >>>> yes, the plan is that each is self contained. When I set up the >>>> patches I >>>> built and jckecked each. When I updated them I only built them >>>> selectively, >>>> so there might be minor issues. I had planned to assure this once I >>>> make >>>> webrevs from the patches. >>>> >>>> Some of them might apply in any order, but others depend on previous >>>> ones, >>>> e.g., 0009 containing the ppc files will not work without the changes >>>> before. >>>> >>>> The patches work with hs25-b34. >>>> >>>> Please tell me if I can do anything to ease your reviewing. >>>> >>>> Ah, I just saw your mail about closed code ... I tried to keep >>>> changes necessary to other platform code to a minimum, but also tried >>>> to avoid strange workarounds. Therefore I for example did change 0002 >>>> renaming the PPC defines, see the comment there. >>>> >>>> If you agree with the granularity of the changes, it would be great >>>> if you >>>> could generate bug-ids for them. Maybe at least for the changes >>>> up to 0016? >>>> >>>> Best regards >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov >>>> [mailto:vladimir.kozlov@**oracle.com >>>> ] >>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>> To: Lindenmaier, Goetz >>>> Cc: >>>> ppc-aix-port-dev at openjdk.java.**net; >>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Thank you, Goetz. >>>> >>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>> with >>>> jdk8 and build? Or I should do review all 1-9 >>>> patches and merge them together into jdk8 to be able build? In >>>> short, is >>>> each patch self-contain? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>> >>>>> Hi, >>>>> >>>>> With my recent changes I removed some of the problems Vladimir >>>>> mentioned. >>>>> >>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>> repository, >>>>> at hotspot/ppc_patches. >>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>> hotspots >>>>> can be built. >>>>> >>>>> The queue contains the changes proposed by me before, with minor >>>>> changes >>>>> due >>>>> to recent development: >>>>> >>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>> 101-107 C-interpreter improvements >>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>> performant ppc port. >>>>> Altogether currently 49 changes. >>>>> >>>>> Our plan was to propose the changes in the order of the queue for >>>>> review. I'm happy to create webrevs for any of them. >>>>> >>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>> changes >>>>> are more complete. They include all later improvements by fixes or >>>>> adaptions in merge changes. >>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>> queue. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> PS: This can be used as the invokedynamic repository: >>>>> hg clone >>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>> ppc-hotspot >>>>> hg clone >>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>> >>>>> cd stage-hotspot >>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>> hg qpush -a >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov >>>>> [mailto:vladimir.kozlov@**oracle.com >>>>> ] >>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Here is result of my first attempt to build/test ppc changes together >>>>> with our closed sources. >>>>> >>>>> Small problems: >>>>> >>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>> >>>>> Build on MacOS: >>>>> >>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>> 'zero_page_read_protected' is not a member of 'os' >>>>> >>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> >>>>> >>>>> We have several conflict with closed sources builds: >>>>> >>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function 'bool >>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>> between >>>>> signed and unsigned integer expressions >>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>> between >>>>> signed and unsigned integer expressions >>>>> >>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>> member function declared in class 'frame' >>>>> >>>>> error: no matching function for call to >>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>> uint&)' >>>>> >>>>> I think it is due to changes like next: >>>>> >>>>> -#ifdef PPC >>>>> +#ifdef PPC32 >>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>> >>>>> >>>>> Next is easy fix in our closed sources but it requires efforts from >>>>> our >>>>> side: >>>>> >>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>> 'static >>>>> void MethodHandles::generate_**adapters()': >>>>> src/share/vm/prims/**methodHandles.cpp:68: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> src/share/vm/prims/**methodHandles.cpp:70: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> >>>>> >>>>> I would suggest to do such shared changes which affects different >>>>> builds >>>>> later after initial push. >>>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi Vladimir, >>>>>> >>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>> tested it successfully. In case you experience any problems >>>>>> please tell me the details so I can fix them. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov >>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>> ] >>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>> To: Simonis, Volker >>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; >>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>> Bateman >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Volker, >>>>>> >>>>>> Can you or someone update >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>> match latest >>>>>> sources in >>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>> >>>>>> ? >>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>> >>>>>>> >>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>> the >>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>> >>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> ------------------------------**------------------------------** >>>>>>> ------------ >>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>> Ellison; >>>>>>> iris.clark at oracle.com >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> Sorry about this, one more thing about the JEP... >>>>>>> >>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>> to be >>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>> listed >>>>>>> as porters-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> iris >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi Iris, >>>>>>> >>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>> something better yesterday in the evening. >>>>>>> >>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>> it. >>>>>>> >>>>>>> Thanks, >>>>>>> Volker >>>>>>> >>>>>>> ------------------------------**------------------------------** >>>>>>> ------------ >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>> >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. >>>>>>> >>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>> repositories" in the revised title is not ideal: >>>>>>> >>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>> >>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>> >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> >>>>>>> JEP: 175 >>>>>>> >>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>> repositories >>>>>>> >>>>>>> Author: Volker Simonis >>>>>>> >>>>>>> Organization: SAP AG >>>>>>> >>>>>>> Created: 2013/1/11 >>>>>>> >>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>> Unicode >>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>> additional details. >>>>>>> >>>>>>> Perhaps others have suggestions? >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will >>>>>>> still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>> be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>> index [1], see the third column. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>> find >>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>> version >>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will >>>>>>> still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>> be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> In addition to the changes proposed by you I've added the >>>>>>> contents of >>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>> "Description" >>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>> Port >>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>> Space" [3] >>>>>>> to the JEP. >>>>>>> >>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>> to hold >>>>>>> Azeems "PPCAIX plan" document. >>>>>>> >>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>> rights to >>>>>>> that page? >>>>>>> >>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>> "PPCAIX >>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>> saw that >>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>> and in >>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>> could help. >>>>>>> >>>>>>> If there are no objections I plan to checkin the new version of >>>>>>> the JEP >>>>>>> tomorrow after our telephone call. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> [2]: https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>> 13729959 >>>>>>> >>>>>>> [3]: >>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>> >>>>>>> >>>>>>> ------------------------------**------------------------------** >>>>>>> ------------ >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>> Bateman; Vladimir Kozlov >>>>>>> *Subject:* JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>> >>>>>>> >>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>> comments: >>>>>>> >>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>> >>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>> it is >>>>>>> only covering PPC/AIX. >>>>>>> >>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>> clear that it applies to Hotspot only. >>>>>>> >>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>> section at the bottom of JEP 1 [1].) >>>>>>> >>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>> up to >>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>> line. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris Clark >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>> >>>>>>> From vladimir.kozlov at oracle.com Wed Jun 12 16:29:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2013 16:29:25 -0700 Subject: JEP 175 - Review comments In-Reply-To: <51B8FCEF.2080504@oracle.com> References: <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B88D89.1070802@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA667@DEWDFEMB12A.global.corp.sap> <51B8AD6E.9020500@oracle.com> <51B8C997.2090103@oracle.com> <51B8FCEF.2080504@oracle.com> Message-ID: <51B90455.8010801@oracle.com> > - I push it to staging repo. I want to use JPRT for push to catch "last minute change" problems. It will keep staging repository clean. I understand it would be simpler for you (and me) if you yourself push into staging repo directly after reviews. But I am a little concern. The best would be if you could use JPRT but it is still dream. Thanks, Vladimir On 6/12/13 3:57 PM, Vladimir Kozlov wrote: > Hi, Volker > > 0001_fix_core_build.patch passed JPRT build/test run so it is good, > consider reviewed (assuming you fix jvmgcore). > > Should we formalize the process to follow our normal openjdk review > process? It will allow other people to see what is coming and to comment > on it as you said and I agree. > > - I will file rfes and add Volker and Goetz to watch list so you get > notifications (I hope) about rfes. > > - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail > aliases. > > - We do reviews and small testing to make sure changes do not break our > builds. > > - You prepare final patch with correct changeset header after we agree > on changes. > > - I push it to staging repo. > > Is this acceptable to you? > > About changeset header: > > : > Summary: > Reviewed-by: + > Contributed-by: > > I don't think you need "Contributed-by:" since Volker could be author. > But it is up to you if you want to mention other contributors. > > 8016476: PPC64 (part 1): reenable CORE build > Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 > Reviewed-by: kvn > > Thanks, > Vladimir > > PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, > check that you get notification. You are on watch list. > > > On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >> Okay, I will add comment to the rfe that CORE target is only used on >> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >> now). >> >> Vladimir >> >> On 6/12/13 11:51 AM, Volker Simonis wrote: >>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>> >>> wrote: >>> >>>> Thanks, Goetz >>>> >>>> I am perfectly fine with such granularity and I can start generating >>>> RFEs. >>>> I filed first: >>>> >>>> 8016476: PPC64 (part 1): reenable CORE build >>>> >>>> >>> Thanks! >>> >>> >>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>> build it >>>> on my Mac: >>>> >>>> >>> We haven't fixed the CORE build on all platforms. It should wok on >>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>> >>> This is the general approach we have taken. So I'm not sure what will be >>> the best way for you to review the changes. But all of the patches >>> from the >>> first series of changes (1-9) won't probably do anything useful on >>> Linux/x86 and Solaris because we haven't fixed the CORE build and the >>> C++ >>> interpreter on that platforms. So building a CORE build or the C++ >>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>> (and was >>> not the scope of this project). >>> >>> I think the review for these patches should only make sure that they >>> don't >>> break anything that worked before an any supported platforms (and >>> trust us >>> that they are good for our platforms:). >>> >>> So in that sense "reenable CORE build" only means to provide the >>> appropriate targets in the Makefiles and not the required source code >>> fixes >>> on all platforms (although they may be trivial/minimal). But if you'd >>> absolutely also want to have a core build on Linux/x86 and Solaris, I >>> can >>> have a look at it. >>> >>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>> gnumake[2]: *** [debugcore] Error 2 >>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>> gnumake: *** [debugcore] Error 2 >>>> >>>> And on SPARC: >>>> >>>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>>> declaration for pd_InlineSmallCode. >>>> >>>> And you should used debugcore instead of jvmgcore: >>>> +all_debugcore: jvmgcore docs export_debug >>>> >>>> I want your changes be perfect from the start ;) >>>> >>> >>> You're right. The renaming of the 'jvmg' target to 'debug' has happened >>> recently ( >>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) >>> and >>> we haven't adapted it. We will fix this. >>> >>> >>>> And I need to discuss with our embedded group about >>>> 0002_PPC_defines.patch >>>> because it affects them. It may take time. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>> >>>>> Hi Vladimir, >>>>> >>>>> yes, the plan is that each is self contained. When I set up the >>>>> patches I >>>>> built and jckecked each. When I updated them I only built them >>>>> selectively, >>>>> so there might be minor issues. I had planned to assure this once I >>>>> make >>>>> webrevs from the patches. >>>>> >>>>> Some of them might apply in any order, but others depend on previous >>>>> ones, >>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>> before. >>>>> >>>>> The patches work with hs25-b34. >>>>> >>>>> Please tell me if I can do anything to ease your reviewing. >>>>> >>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>> changes necessary to other platform code to a minimum, but also tried >>>>> to avoid strange workarounds. Therefore I for example did change 0002 >>>>> renaming the PPC defines, see the comment there. >>>>> >>>>> If you agree with the granularity of the changes, it would be great >>>>> if you >>>>> could generate bug-ids for them. Maybe at least for the changes >>>>> up to 0016? >>>>> >>>>> Best regards >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov >>>>> [mailto:vladimir.kozlov@**oracle.com >>>>> ] >>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>> To: Lindenmaier, Goetz >>>>> Cc: >>>>> ppc-aix-port-dev at openjdk.java.**net; >>>>> >>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris >>>>> Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Thank you, Goetz. >>>>> >>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>> with >>>>> jdk8 and build? Or I should do review all 1-9 >>>>> patches and merge them together into jdk8 to be able build? In >>>>> short, is >>>>> each patch self-contain? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> With my recent changes I removed some of the problems Vladimir >>>>>> mentioned. >>>>>> >>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>> repository, >>>>>> at hotspot/ppc_patches. >>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>> hotspots >>>>>> can be built. >>>>>> >>>>>> The queue contains the changes proposed by me before, with minor >>>>>> changes >>>>>> due >>>>>> to recent development: >>>>>> >>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>> 101-107 C-interpreter improvements >>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>> performant ppc port. >>>>>> Altogether currently 49 changes. >>>>>> >>>>>> Our plan was to propose the changes in the order of the queue for >>>>>> review. I'm happy to create webrevs for any of them. >>>>>> >>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>> changes >>>>>> are more complete. They include all later improvements by fixes or >>>>>> adaptions in merge changes. >>>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>>> queue. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> PS: This can be used as the invokedynamic repository: >>>>>> hg clone >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>>> >>>>>> ppc-hotspot >>>>>> hg clone >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>>> >>>>>> >>>>>> cd stage-hotspot >>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>> hg qpush -a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov >>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>> ] >>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Here is result of my first attempt to build/test ppc changes together >>>>>> with our closed sources. >>>>>> >>>>>> Small problems: >>>>>> >>>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>>> >>>>>> Build on MacOS: >>>>>> >>>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>> >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> >>>>>> >>>>>> We have several conflict with closed sources builds: >>>>>> >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function 'bool >>>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>>> between >>>>>> signed and unsigned integer expressions >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>>> between >>>>>> signed and unsigned integer expressions >>>>>> >>>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>>> member function declared in class 'frame' >>>>>> >>>>>> error: no matching function for call to >>>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>>> uint&)' >>>>>> >>>>>> I think it is due to changes like next: >>>>>> >>>>>> -#ifdef PPC >>>>>> +#ifdef PPC32 >>>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>>> >>>>>> >>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>> our >>>>>> side: >>>>>> >>>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>>> 'static >>>>>> void MethodHandles::generate_**adapters()': >>>>>> src/share/vm/prims/**methodHandles.cpp:68: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> src/share/vm/prims/**methodHandles.cpp:70: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> >>>>>> >>>>>> I would suggest to do such shared changes which affects different >>>>>> builds >>>>>> later after initial push. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>> tested it successfully. In case you experience any problems >>>>>>> please tell me the details so I can fix them. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov >>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>> ] >>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>> To: Simonis, Volker >>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; >>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>> Bateman >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Volker, >>>>>>> >>>>>>> Can you or someone update >>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>>> >>>>>>> match latest >>>>>>> sources in >>>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>>> >>>>>>> >>>>>>> ? >>>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>> >>>>>>>> >>>>>>>> We intentionally used 'porters-dev' rather >>>>>>>> than'ppc-aix-port-dev' in >>>>>>>> the >>>>>>>> beginning to address a broader audience for the initial >>>>>>>> discussions. >>>>>>>> >>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>> Ellison; >>>>>>>> iris.clark at oracle.com >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>> >>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>> to be >>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>> listed >>>>>>>> as porters-dev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> iris >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>> Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi Iris, >>>>>>>> >>>>>>>> you're right, the title is too clumsy - I just couldn't come up >>>>>>>> with >>>>>>>> something better yesterday in the evening. >>>>>>>> >>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll >>>>>>>> take >>>>>>>> it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Volker >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>> >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>> >>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>>> repositories" in the revised title is not ideal: >>>>>>>> >>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>> >>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>> >>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>> >>>>>>>> JEP: 175 >>>>>>>> >>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>> repositories >>>>>>>> >>>>>>>> Author: Volker Simonis >>>>>>>> >>>>>>>> Organization: SAP AG >>>>>>>> >>>>>>>> Created: 2013/1/11 >>>>>>>> >>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are >>>>>>>> all >>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>> Unicode >>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself >>>>>>>> contains >>>>>>>> additional details. >>>>>>>> >>>>>>>> Perhaps others have suggestions? >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>> still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>> be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> Yes. Once that field is populated, the value will appear in the >>>>>>>> JEP >>>>>>>> index [1], see the third column. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>> find >>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>> version >>>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>> still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>> be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>> contents of >>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>> "Description" >>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>> Port >>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>> Space" [3] >>>>>>>> to the JEP. >>>>>>>> >>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>> to hold >>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>> >>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>> rights to >>>>>>>> that page? >>>>>>>> >>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>> "PPCAIX >>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>> saw that >>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>> and in >>>>>>>> my unlimited naivety I imagine this could be a simple >>>>>>>> copy-and-paste >>>>>>>> operation:) If that doesn't work so easily, please let me know >>>>>>>> how I >>>>>>>> could help. >>>>>>>> >>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>> the JEP >>>>>>>> tomorrow after our telephone call. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> [2]: >>>>>>>> https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>>> 13729959 >>>>>>>> >>>>>>>> >>>>>>>> [3]: >>>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>>> Bateman; Vladimir Kozlov >>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>>> >>>>>>>> >>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>> comments: >>>>>>>> >>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>> >>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>> it is >>>>>>>> only covering PPC/AIX. >>>>>>>> >>>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>>> clear that it applies to Hotspot only. >>>>>>>> >>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>> >>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>> up to >>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>> line. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris Clark >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>> >>>>>>>> From david.holmes at oracle.com Wed Jun 12 19:45:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2013 12:45:45 +1000 Subject: JEP 175 - Review comments In-Reply-To: <51B8D212.1050204@oracle.com> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> Message-ID: <51B93259.7060206@oracle.com> Just adding my 2c from what was an internal discussion but is not in any way confidential: We don't use 3 architecture designators on other platforms to distinguish between "common", 32-bit and 64-bit, so why do we need to do so for PPC ? The normal approach would be to add _LP64=1 specific ifdefs within an architectural ifdef. This change (PPC32 usage) seems to be introducing unnecessary changes and inconsistency with how 32-bit vs 64-bit is generally handled. Further, it is far from obvious from the patch that code now flagged as PPC32 is indeed 32-bit specific rather than common! David ----- On 13/06/2013 5:54 AM, Chris Plummer wrote: > Hi Goetz, > > Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see > PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in > make/linux/platform_ppc. > > There are a lot of PPC references in c1 that don't appear to have been > addressed. > > Is there a reason that PPC is not also defined for both PPC32 and PPC64, > allowing you to use > > #ifdef PPC > > rather than > > #if defined(PPC32) || defined(PPC64) > > best regards, > > Chris > > On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> With my recent changes I removed some of the problems Vladimir mentioned. >> >> I also added the patches queue I maintain into our jdk8/hotspot >> repository, >> at hotspot/ppc_patches. >> Applied to the staging hotspot directory, the linuxppc and aixppc >> hotspots >> can be built. >> >> The queue contains the changes proposed by me before, with minor >> changes due >> to recent development: >> >> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >> 101-107 C-interpreter improvements >> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >> 200-217 C2 compiler fixes, extensions etc needed for a stable and >> performant ppc port. >> Altogether currently 49 changes. >> >> Our plan was to propose the changes in the order of the queue for >> review. I'm happy to create webrevs for any of them. >> >> Vladimir, maybe the queue simplifies reviewing the port, as the changes >> are more complete. They include all later improvements by fixes or >> adaptions in merge changes. >> For why and where I renamed PPC to PPC32 see the second change in the >> queue. >> >> Best regards, >> Goetz. >> >> >> PS: This can be used as the invokedynamic repository: >> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >> ppc-hotspot >> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >> stage-hotspot >> cd stage-hotspot >> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >> hg qpush -a >> >> >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 11. Juni 2013 18:34 >> To: Lindenmaier, Goetz >> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >> Subject: Re: JEP 175 - Review comments >> >> Here is result of my first attempt to build/test ppc changes together >> with our closed sources. >> >> Small problems: >> >> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >> >> Build on MacOS: >> >> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >> JVMState* VirtualCallGenerator::generate(JVMState*)': >> src/share/vm/opto/callGenerator.cpp:204: error: >> 'zero_page_read_protected' is not a member of 'os' >> >> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >> UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >> UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >> UNSUPPORTED_ARCH >> >> >> We have several conflict with closed sources builds: >> >> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >> signed and unsigned integer expressions >> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >> signed and unsigned integer expressions >> >> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >> member function declared in class 'frame' >> >> error: no matching function for call to >> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >> >> I think it is due to changes like next: >> >> -#ifdef PPC >> +#ifdef PPC32 >> oop* interpreter_frame_mirror_addr() const; >> >> >> Next is easy fix in our closed sources but it requires efforts from our >> side: >> >> src/share/vm/prims/methodHandles.cpp: In static member function 'static >> void MethodHandles::generate_adapters()': >> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >> cannot be used as a function >> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >> cannot be used as a function >> >> >> I would suggest to do such shared changes which affects different builds >> later after initial push. >> >> >> Thanks, >> Vladimir >> >> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I updated the repo to jdk8-b92. Our nightly tests built and >>> tested it successfully. In case you experience any problems >>> please tell me the details so I can fix them. >>> >>> Best regards, >>> Goetz. >>> >>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 4. Juni 2013 20:58 >>> To: Simonis, Volker >>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>> Alan Bateman >>> Subject: Re: JEP 175 - Review comments >>> >>> Volker, >>> >>> Can you or someone update >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>> I just tried to merge them and build Hotspot on x86 without success. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>> the >>>> beginning to address a broader audience for the initial discussions. >>>> >>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:* Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>> Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>> iris.clark at oracle.com >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> Sorry about this, one more thing about the JEP... >>>> >>>> I think that the "Discussion" list probably needs to be updated to be >>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>> as porters-dev. >>>> >>>> Thanks, >>>> >>>> iris >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi Iris, >>>> >>>> you're right, the title is too clumsy - I just couldn't come up with >>>> something better yesterday in the evening. >>>> >>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>> it. >>>> >>>> Thanks, >>>> Volker >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>> Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>> >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> I've just updated the JEP according to your suggestions. >>>> >>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>> repositories" in the revised title is not ideal: >>>> >>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>> >>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>> >>>> @@ -1,5 +1,5 @@ >>>> >>>> JEP: 175 >>>> >>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>> repositories >>>> >>>> Author: Volker Simonis >>>> >>>> Organization: SAP AG >>>> >>>> Created: 2013/1/11 >>>> >>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>> about adding features to JDK Release Projects. There are lots of >>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>> additional details. >>>> >>>> Perhaps others have suggestions? >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> Yes. Once that field is populated, the value will appear in the JEP >>>> index [1], see the third column. >>>> >>>> Thanks, >>>> >>>> Iris >>>> >>>> [1]: http://openjdk.java.net/jeps/0 >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, >>>> >>>> I've just updated the JEP according to your suggestions. Please find >>>> the new version attached to this mail (I haven't checked the new >>>> version >>>> in until now to give everybody a chance to comment on the changes). >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> In addition to the changes proposed by you I've added the contents of >>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>> to the JEP. >>>> >>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>> Azeems "PPCAIX plan" document. >>>> >>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>> that page? >>>> >>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>> plan" into that page (once you have the appropriate rights)? I saw that >>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>> operation:) If that doesn't work so easily, please let me know how I >>>> could help. >>>> >>>> If there are no objections I plan to checkin the new version of the JEP >>>> tomorrow after our telephone call. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> [2]: >>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>> Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* iris.clark at oracle.com ; Alan >>>> Bateman; Vladimir Kozlov >>>> *Subject:* JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> http://openjdk.java.net/jeps/175 >>>> >>>> We're actively working to get your JEP to Funded. We had a few >>>> comments: >>>> >>>> -Recommend that "8" be removed from the JEP title, etc. >>>> >>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>> only covering PPC/AIX. >>>> >>>> -Recommend that the second Motivation bullet be modified to make it >>>> clear that it applies to Hotspot only. >>>> >>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>> section at the bottom of JEP 1 [1].) >>>> >>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>> be the JEP's reviewers. Once they're satisfied with your >>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>> line. >>>> >>>> Thanks, >>>> >>>> Iris Clark >>>> >>>> [1]: http://openjdk.java.net/jeps/1 >>>> > From bengt.rutisson at oracle.com Wed Jun 12 23:58:06 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Jun 2013 08:58:06 +0200 Subject: RFR (S): [increase HeapBaseMinAddress for G1] 8012265: VM often crashes on solaris with a lot of memory Message-ID: <51B96D7E.7090201@oracle.com> Hi everyone, Could I have a couple of reviews for this change? http://cr.openjdk.java.net/~brutisso/8012265/webrev.00/ Sending this to the broad hotspot list since it affects compressed oops, which is a VM wide concern. Background: The G1 GC uses malloc extensively to allocate auxiliary data structures. On Solaris malloc requires a consecutive chunk of memory for the C-heap. It picks this chunk in the low addresses so when hotspot maps the Java heap in the low addresses to get compressed oops we limit the available memory for the C-heap on Solaris. For compressed oops the Java heap is mapped at HeapBaseMinAddress, which by default is 2GB on all platforms except Solaris x86 where it is 256MB. If we have a large Solaris x86 we get many GC worker threads and many G1 heap regions. All of them requiring substantial C-heap allocations. The combination of a limited C-heap and a lot of mallocs for G1 may cause us to run out of memory on large Solaris x86 machines, even with our default settings. The long term solution is to change G1 to be more efficient about its memory consumption and preferably use mapped memory instead of malloced memory. This is a lot of work, but will definitely have to be done. A short term solution to reduce the risk of running out of memory is to increase the default value of HeapBaseMinAddress for G1. That is what my proposed patch does. This will reduce the maximum possible heap sizes for compressed oops without a heap base. Shifted compressed oops will be reduced from almost 32g to 31g and unshifted compressed oops from almost 4g to 3g. Still more than on any other platform where HeapBaseMinAddress=2g by default. It will only affect G1 and it can be overridden by explicitly setting HeapBaseMinAddress on the command line. I've filed this enhancement in JBS to track the work to change back the default value: JDK-8016505: G1: Revert back to use HeapBaseMinAddress=256m on Solaris x86 Thanks, Bengt From goetz.lindenmaier at sap.com Thu Jun 13 00:25:06 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Jun 2013 07:25:06 +0000 Subject: JEP 175 - Review comments In-Reply-To: <51B93259.7060206@oracle.com> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> <51B93259.7060206@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> Hi, @Chris: -DPPC32 needs to be set in make//platform_ppc32. @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, and in macros.hpp you find #if defined(IA32) || defined(AMD64) #define X86 #define X86_ONLY(code) code #define NOT_X86(code) #else #undef X86 #define X86_ONLY(code) #define NOT_X86(code) code #endif It's just not that obvious as the names of these platforms are messed up. On PPC I wanted to follow a clean approach. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Donnerstag, 13. Juni 2013 04:46 To: Lindenmaier, Goetz Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: JEP 175 - Review comments Just adding my 2c from what was an internal discussion but is not in any way confidential: We don't use 3 architecture designators on other platforms to distinguish between "common", 32-bit and 64-bit, so why do we need to do so for PPC ? The normal approach would be to add _LP64=1 specific ifdefs within an architectural ifdef. This change (PPC32 usage) seems to be introducing unnecessary changes and inconsistency with how 32-bit vs 64-bit is generally handled. Further, it is far from obvious from the patch that code now flagged as PPC32 is indeed 32-bit specific rather than common! David ----- On 13/06/2013 5:54 AM, Chris Plummer wrote: > Hi Goetz, > > Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see > PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in > make/linux/platform_ppc. > > There are a lot of PPC references in c1 that don't appear to have been > addressed. > > Is there a reason that PPC is not also defined for both PPC32 and PPC64, > allowing you to use > > #ifdef PPC > > rather than > > #if defined(PPC32) || defined(PPC64) > > best regards, > > Chris > > On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> With my recent changes I removed some of the problems Vladimir mentioned. >> >> I also added the patches queue I maintain into our jdk8/hotspot >> repository, >> at hotspot/ppc_patches. >> Applied to the staging hotspot directory, the linuxppc and aixppc >> hotspots >> can be built. >> >> The queue contains the changes proposed by me before, with minor >> changes due >> to recent development: >> >> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >> 101-107 C-interpreter improvements >> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >> 200-217 C2 compiler fixes, extensions etc needed for a stable and >> performant ppc port. >> Altogether currently 49 changes. >> >> Our plan was to propose the changes in the order of the queue for >> review. I'm happy to create webrevs for any of them. >> >> Vladimir, maybe the queue simplifies reviewing the port, as the changes >> are more complete. They include all later improvements by fixes or >> adaptions in merge changes. >> For why and where I renamed PPC to PPC32 see the second change in the >> queue. >> >> Best regards, >> Goetz. >> >> >> PS: This can be used as the invokedynamic repository: >> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >> ppc-hotspot >> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >> stage-hotspot >> cd stage-hotspot >> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >> hg qpush -a >> >> >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 11. Juni 2013 18:34 >> To: Lindenmaier, Goetz >> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >> Subject: Re: JEP 175 - Review comments >> >> Here is result of my first attempt to build/test ppc changes together >> with our closed sources. >> >> Small problems: >> >> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >> >> Build on MacOS: >> >> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >> JVMState* VirtualCallGenerator::generate(JVMState*)': >> src/share/vm/opto/callGenerator.cpp:204: error: >> 'zero_page_read_protected' is not a member of 'os' >> >> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >> UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >> UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >> UNSUPPORTED_ARCH >> >> >> We have several conflict with closed sources builds: >> >> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >> signed and unsigned integer expressions >> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >> signed and unsigned integer expressions >> >> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >> member function declared in class 'frame' >> >> error: no matching function for call to >> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >> >> I think it is due to changes like next: >> >> -#ifdef PPC >> +#ifdef PPC32 >> oop* interpreter_frame_mirror_addr() const; >> >> >> Next is easy fix in our closed sources but it requires efforts from our >> side: >> >> src/share/vm/prims/methodHandles.cpp: In static member function 'static >> void MethodHandles::generate_adapters()': >> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >> cannot be used as a function >> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >> cannot be used as a function >> >> >> I would suggest to do such shared changes which affects different builds >> later after initial push. >> >> >> Thanks, >> Vladimir >> >> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I updated the repo to jdk8-b92. Our nightly tests built and >>> tested it successfully. In case you experience any problems >>> please tell me the details so I can fix them. >>> >>> Best regards, >>> Goetz. >>> >>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 4. Juni 2013 20:58 >>> To: Simonis, Volker >>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>> Alan Bateman >>> Subject: Re: JEP 175 - Review comments >>> >>> Volker, >>> >>> Can you or someone update >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>> I just tried to merge them and build Hotspot on x86 without success. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>> the >>>> beginning to address a broader audience for the initial discussions. >>>> >>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:* Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>> Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>> iris.clark at oracle.com >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> Sorry about this, one more thing about the JEP... >>>> >>>> I think that the "Discussion" list probably needs to be updated to be >>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>> as porters-dev. >>>> >>>> Thanks, >>>> >>>> iris >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi Iris, >>>> >>>> you're right, the title is too clumsy - I just couldn't come up with >>>> something better yesterday in the evening. >>>> >>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>> it. >>>> >>>> Thanks, >>>> Volker >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>> Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>> >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> I've just updated the JEP according to your suggestions. >>>> >>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>> repositories" in the revised title is not ideal: >>>> >>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>> >>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>> >>>> @@ -1,5 +1,5 @@ >>>> >>>> JEP: 175 >>>> >>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>> repositories >>>> >>>> Author: Volker Simonis >>>> >>>> Organization: SAP AG >>>> >>>> Created: 2013/1/11 >>>> >>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>> about adding features to JDK Release Projects. There are lots of >>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>> additional details. >>>> >>>> Perhaps others have suggestions? >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> Yes. Once that field is populated, the value will appear in the JEP >>>> index [1], see the third column. >>>> >>>> Thanks, >>>> >>>> Iris >>>> >>>> [1]: http://openjdk.java.net/jeps/0 >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, >>>> >>>> I've just updated the JEP according to your suggestions. Please find >>>> the new version attached to this mail (I haven't checked the new >>>> version >>>> in until now to give everybody a chance to comment on the changes). >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> In addition to the changes proposed by you I've added the contents of >>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>> to the JEP. >>>> >>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>> Azeems "PPCAIX plan" document. >>>> >>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>> that page? >>>> >>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>> plan" into that page (once you have the appropriate rights)? I saw that >>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>> operation:) If that doesn't work so easily, please let me know how I >>>> could help. >>>> >>>> If there are no objections I plan to checkin the new version of the JEP >>>> tomorrow after our telephone call. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> [2]: >>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>> Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* iris.clark at oracle.com ; Alan >>>> Bateman; Vladimir Kozlov >>>> *Subject:* JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> http://openjdk.java.net/jeps/175 >>>> >>>> We're actively working to get your JEP to Funded. We had a few >>>> comments: >>>> >>>> -Recommend that "8" be removed from the JEP title, etc. >>>> >>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>> only covering PPC/AIX. >>>> >>>> -Recommend that the second Motivation bullet be modified to make it >>>> clear that it applies to Hotspot only. >>>> >>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>> section at the bottom of JEP 1 [1].) >>>> >>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>> be the JEP's reviewers. Once they're satisfied with your >>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>> line. >>>> >>>> Thanks, >>>> >>>> Iris Clark >>>> >>>> [1]: http://openjdk.java.net/jeps/1 >>>> > From frederic.parain at oracle.com Thu Jun 13 01:19:34 2013 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 13 Jun 2013 10:19:34 +0200 Subject: CFV: New hsx Committer: Thomas Schatzl In-Reply-To: <519345DF.2030207@oracle.com> References: <519345DF.2030207@oracle.com> Message-ID: <51B98096.8030708@oracle.com> Vote: yes Fred On 05/15/13 10:22 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl to hsx Committer. > > Thomas joined the HotSpot garbage collection team at Oracle earlier this > year. Thomas has been active in HotSpot development for several years > before starting at Oracle. He has contributed 2 changesets [1,2] before > starting Oracle and 7 more since he joined the GC team [3]. > > Votes are due by Thu, May 29, 2013 11:00am CEST. > > Only current hsx Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Bengt Rutisson > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db823a892a55 > [2] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7994a5a35fcf > [3] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tschatzl > [4]http://openjdk.java.net/census/#hsx > [5]http://openjdk.java.net/projects/#committer-vote > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From goetz.lindenmaier at sap.com Thu Jun 13 02:53:53 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Jun 2013 09:53:53 +0000 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build Message-ID: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> Hi, I fixed the jvmg target and prepared a webrev: http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ Thanks for reviewing, Vladimir. I need a second reviewer, please. Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Donnerstag, 13. Juni 2013 00:58 To: Volker Simonis Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; hotspot-dev at openjdk.java.net Subject: Re: JEP 175 - Review comments Hi, Volker 0001_fix_core_build.patch passed JPRT build/test run so it is good, consider reviewed (assuming you fix jvmgcore). Should we formalize the process to follow our normal openjdk review process? It will allow other people to see what is coming and to comment on it as you said and I agree. - I will file rfes and add Volker and Goetz to watch list so you get notifications (I hope) about rfes. - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail aliases. - We do reviews and small testing to make sure changes do not break our builds. - You prepare final patch with correct changeset header after we agree on changes. - I push it to staging repo. Is this acceptable to you? About changeset header: : Summary: Reviewed-by: + Contributed-by: I don't think you need "Contributed-by:" since Volker could be author. But it is up to you if you want to mention other contributors. 8016476: PPC64 (part 1): reenable CORE build Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 Reviewed-by: kvn Thanks, Vladimir PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, check that you get notification. You are on watch list. On 6/12/13 12:18 PM, Vladimir Kozlov wrote: > Okay, I will add comment to the rfe that CORE target is only used on > Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for > now). > > Vladimir > > On 6/12/13 11:51 AM, Volker Simonis wrote: >> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >> >> wrote: >> >>> Thanks, Goetz >>> >>> I am perfectly fine with such granularity and I can start generating >>> RFEs. >>> I filed first: >>> >>> 8016476: PPC64 (part 1): reenable CORE build >>> >>> >> Thanks! >> >> >>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>> build it >>> on my Mac: >>> >>> >> We haven't fixed the CORE build on all platforms. It should wok on >> Linux/PPC64 and AIX/PPC64 and not break anything else. >> >> This is the general approach we have taken. So I'm not sure what will be >> the best way for you to review the changes. But all of the patches >> from the >> first series of changes (1-9) won't probably do anything useful on >> Linux/x86 and Solaris because we haven't fixed the CORE build and the C++ >> interpreter on that platforms. So building a CORE build or the C++ >> interpreter on Linux/x86, Solaris or Mac will probably not succeed >> (and was >> not the scope of this project). >> >> I think the review for these patches should only make sure that they >> don't >> break anything that worked before an any supported platforms (and >> trust us >> that they are good for our platforms:). >> >> So in that sense "reenable CORE build" only means to provide the >> appropriate targets in the Makefiles and not the required source code >> fixes >> on all platforms (although they may be trivial/minimal). But if you'd >> absolutely also want to have a core build on Linux/x86 and Solaris, I can >> have a look at it. >> >> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>> gnumake[3]: *** [dtrace_stuff] Error 2 >>> gnumake[2]: *** [debugcore] Error 2 >>> gnumake[1]: *** [generic_buildcore] Error 2 >>> gnumake: *** [debugcore] Error 2 >>> >>> And on SPARC: >>> >>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>> declaration for pd_InlineSmallCode. >>> >>> And you should used debugcore instead of jvmgcore: >>> +all_debugcore: jvmgcore docs export_debug >>> >>> I want your changes be perfect from the start ;) >>> >> >> You're right. The renaming of the 'jvmg' target to 'debug' has happened >> recently ( >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >> we haven't adapted it. We will fix this. >> >> >>> And I need to discuss with our embedded group about >>> 0002_PPC_defines.patch >>> because it affects them. It may take time. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>> >>>> Hi Vladimir, >>>> >>>> yes, the plan is that each is self contained. When I set up the >>>> patches I >>>> built and jckecked each. When I updated them I only built them >>>> selectively, >>>> so there might be minor issues. I had planned to assure this once I >>>> make >>>> webrevs from the patches. >>>> >>>> Some of them might apply in any order, but others depend on previous >>>> ones, >>>> e.g., 0009 containing the ppc files will not work without the changes >>>> before. >>>> >>>> The patches work with hs25-b34. >>>> >>>> Please tell me if I can do anything to ease your reviewing. >>>> >>>> Ah, I just saw your mail about closed code ... I tried to keep >>>> changes necessary to other platform code to a minimum, but also tried >>>> to avoid strange workarounds. Therefore I for example did change 0002 >>>> renaming the PPC defines, see the comment there. >>>> >>>> If you agree with the granularity of the changes, it would be great >>>> if you >>>> could generate bug-ids for them. Maybe at least for the changes >>>> up to 0016? >>>> >>>> Best regards >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov >>>> [mailto:vladimir.kozlov@**oracle.com >>>> ] >>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>> To: Lindenmaier, Goetz >>>> Cc: >>>> ppc-aix-port-dev at openjdk.java.**net; >>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Thank you, Goetz. >>>> >>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>> with >>>> jdk8 and build? Or I should do review all 1-9 >>>> patches and merge them together into jdk8 to be able build? In >>>> short, is >>>> each patch self-contain? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>> >>>>> Hi, >>>>> >>>>> With my recent changes I removed some of the problems Vladimir >>>>> mentioned. >>>>> >>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>> repository, >>>>> at hotspot/ppc_patches. >>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>> hotspots >>>>> can be built. >>>>> >>>>> The queue contains the changes proposed by me before, with minor >>>>> changes >>>>> due >>>>> to recent development: >>>>> >>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>> 101-107 C-interpreter improvements >>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>> performant ppc port. >>>>> Altogether currently 49 changes. >>>>> >>>>> Our plan was to propose the changes in the order of the queue for >>>>> review. I'm happy to create webrevs for any of them. >>>>> >>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>> changes >>>>> are more complete. They include all later improvements by fixes or >>>>> adaptions in merge changes. >>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>> queue. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> PS: This can be used as the invokedynamic repository: >>>>> hg clone >>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>> ppc-hotspot >>>>> hg clone >>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>> >>>>> cd stage-hotspot >>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>> hg qpush -a >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov >>>>> [mailto:vladimir.kozlov@**oracle.com >>>>> ] >>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Here is result of my first attempt to build/test ppc changes together >>>>> with our closed sources. >>>>> >>>>> Small problems: >>>>> >>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>> >>>>> Build on MacOS: >>>>> >>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>> 'zero_page_read_protected' is not a member of 'os' >>>>> >>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> >>>>> >>>>> We have several conflict with closed sources builds: >>>>> >>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function 'bool >>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>> between >>>>> signed and unsigned integer expressions >>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>> between >>>>> signed and unsigned integer expressions >>>>> >>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>> member function declared in class 'frame' >>>>> >>>>> error: no matching function for call to >>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>> uint&)' >>>>> >>>>> I think it is due to changes like next: >>>>> >>>>> -#ifdef PPC >>>>> +#ifdef PPC32 >>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>> >>>>> >>>>> Next is easy fix in our closed sources but it requires efforts from >>>>> our >>>>> side: >>>>> >>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>> 'static >>>>> void MethodHandles::generate_**adapters()': >>>>> src/share/vm/prims/**methodHandles.cpp:68: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> src/share/vm/prims/**methodHandles.cpp:70: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> >>>>> >>>>> I would suggest to do such shared changes which affects different >>>>> builds >>>>> later after initial push. >>>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi Vladimir, >>>>>> >>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>> tested it successfully. In case you experience any problems >>>>>> please tell me the details so I can fix them. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov >>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>> ] >>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>> To: Simonis, Volker >>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; >>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>> Bateman >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Volker, >>>>>> >>>>>> Can you or someone update >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>> match latest >>>>>> sources in >>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>> >>>>>> ? >>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>> >>>>>>> >>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>> the >>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>> >>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> ------------------------------**------------------------------** >>>>>>> ------------ >>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>> Ellison; >>>>>>> iris.clark at oracle.com >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> Sorry about this, one more thing about the JEP... >>>>>>> >>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>> to be >>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>> listed >>>>>>> as porters-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> iris >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi Iris, >>>>>>> >>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>> something better yesterday in the evening. >>>>>>> >>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>> it. >>>>>>> >>>>>>> Thanks, >>>>>>> Volker >>>>>>> >>>>>>> ------------------------------**------------------------------** >>>>>>> ------------ >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>> >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. >>>>>>> >>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>> repositories" in the revised title is not ideal: >>>>>>> >>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>> >>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>> >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> >>>>>>> JEP: 175 >>>>>>> >>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>> repositories >>>>>>> >>>>>>> Author: Volker Simonis >>>>>>> >>>>>>> Organization: SAP AG >>>>>>> >>>>>>> Created: 2013/1/11 >>>>>>> >>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>> Unicode >>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>> additional details. >>>>>>> >>>>>>> Perhaps others have suggestions? >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will >>>>>>> still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>> be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>> index [1], see the third column. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>> find >>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>> version >>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will >>>>>>> still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>> be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> In addition to the changes proposed by you I've added the >>>>>>> contents of >>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>> "Description" >>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>> Port >>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>> Space" [3] >>>>>>> to the JEP. >>>>>>> >>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>> to hold >>>>>>> Azeems "PPCAIX plan" document. >>>>>>> >>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>> rights to >>>>>>> that page? >>>>>>> >>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>> "PPCAIX >>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>> saw that >>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>> and in >>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>> could help. >>>>>>> >>>>>>> If there are no objections I plan to checkin the new version of >>>>>>> the JEP >>>>>>> tomorrow after our telephone call. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> [2]: https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>> 13729959 >>>>>>> >>>>>>> [3]: >>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>> >>>>>>> >>>>>>> ------------------------------**------------------------------** >>>>>>> ------------ >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>> Bateman; Vladimir Kozlov >>>>>>> *Subject:* JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>> >>>>>>> >>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>> comments: >>>>>>> >>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>> >>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>> it is >>>>>>> only covering PPC/AIX. >>>>>>> >>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>> clear that it applies to Hotspot only. >>>>>>> >>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>> section at the bottom of JEP 1 [1].) >>>>>>> >>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>> up to >>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>> line. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris Clark >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>> >>>>>>> From david.holmes at oracle.com Thu Jun 13 03:27:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2013 20:27:09 +1000 Subject: JEP 175 - Review comments In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> <51B93259.7060206@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> Message-ID: <51B99E7D.5010605@oracle.com> Hi Goetz, On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: > Hi, > > @Chris: -DPPC32 needs to be set in make//platform_ppc32. I think BUILD_ARCH would also need to be ppc32 to pick that up - but then we would need to change LIB_ARCH back to ppc. Is the 64-bit port using ppc64 as the LIB_ARCH? > @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, > and in macros.hpp you find Okay I confess, it was a bad idea to generalize that given that out of the four platforms we support in the Oracle JDK, two are 32-bit only, so we only have sparc and x86 as examples. On sparc we only use SPARC and _LP64=1 to indicate things (and obviously in sparc specific files anything not in _LP64=1 is implicitly 32-bit). For x86 .... well x86 is a bit of a historical mess. So yes all those defines exist but the predominant form in shared code is X86 and AMD64 (as a synonym for LP64=1). IA32 exists but is barely used and arguably most of the places it remains are relics from before the 32-bit and 64-bit x86 code merge took place. So we have some historical baggage there. My main concern with the PPC, PPC32, PPC64 proposal is that the patch I saw: http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch seemed to use PPC32 in places I would not expect. I'm starting to feel that this is not 32 vs 64 per-se, but that PPC32 is being used as a way to flag "PPC Oracle" in a way that excludes it from use by the PPC64 port. If that is the case, and I can understand that it may well be given the existing PPC specific code was indeed put in place to support Oracle's PPC port, then perhaps we can look at ways of dealing with that without using what seems to me to be an artificial 32 vs 64-bit distinction? Aside: I would greatly prefer if ARM and PPC were never mentioned in the (existing) openjdk code, but that would require a level of refactoring in places that no-one unfortunately has the time to do. That said perhaps there are some places where a cleaner separation is possible. There are also places where compiler defines could be used to set string values rather than using the cpu ifdefs ie: #ifdef PPC #define CPU "ppc" etc David ----- > > #if defined(IA32) || defined(AMD64) > #define X86 > #define X86_ONLY(code) code > #define NOT_X86(code) > #else > #undef X86 > #define X86_ONLY(code) > #define NOT_X86(code) code > #endif > > It's just not that obvious as the names of these platforms > are messed up. On PPC I wanted to follow a clean approach. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 13. Juni 2013 04:46 > To: Lindenmaier, Goetz > Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Just adding my 2c from what was an internal discussion but is not in any > way confidential: > > We don't use 3 architecture designators on other platforms to > distinguish between "common", 32-bit and 64-bit, so why do we need to do > so for PPC ? > > The normal approach would be to add _LP64=1 specific ifdefs within an > architectural ifdef. > > This change (PPC32 usage) seems to be introducing unnecessary changes > and inconsistency with how 32-bit vs 64-bit is generally handled. > > Further, it is far from obvious from the patch that code now flagged as > PPC32 is indeed 32-bit specific rather than common! > > David > ----- > > On 13/06/2013 5:54 AM, Chris Plummer wrote: >> Hi Goetz, >> >> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >> make/linux/platform_ppc. >> >> There are a lot of PPC references in c1 that don't appear to have been >> addressed. >> >> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >> allowing you to use >> >> #ifdef PPC >> >> rather than >> >> #if defined(PPC32) || defined(PPC64) >> >> best regards, >> >> Chris >> >> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> With my recent changes I removed some of the problems Vladimir mentioned. >>> >>> I also added the patches queue I maintain into our jdk8/hotspot >>> repository, >>> at hotspot/ppc_patches. >>> Applied to the staging hotspot directory, the linuxppc and aixppc >>> hotspots >>> can be built. >>> >>> The queue contains the changes proposed by me before, with minor >>> changes due >>> to recent development: >>> >>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>> 101-107 C-interpreter improvements >>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>> performant ppc port. >>> Altogether currently 49 changes. >>> >>> Our plan was to propose the changes in the order of the queue for >>> review. I'm happy to create webrevs for any of them. >>> >>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>> are more complete. They include all later improvements by fixes or >>> adaptions in merge changes. >>> For why and where I renamed PPC to PPC32 see the second change in the >>> queue. >>> >>> Best regards, >>> Goetz. >>> >>> >>> PS: This can be used as the invokedynamic repository: >>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>> ppc-hotspot >>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>> stage-hotspot >>> cd stage-hotspot >>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>> hg qpush -a >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 11. Juni 2013 18:34 >>> To: Lindenmaier, Goetz >>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>> Subject: Re: JEP 175 - Review comments >>> >>> Here is result of my first attempt to build/test ppc changes together >>> with our closed sources. >>> >>> Small problems: >>> >>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>> >>> Build on MacOS: >>> >>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>> src/share/vm/opto/callGenerator.cpp:204: error: >>> 'zero_page_read_protected' is not a member of 'os' >>> >>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>> UNSUPPORTED_ARCH >>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>> UNSUPPORTED_ARCH >>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>> UNSUPPORTED_ARCH >>> >>> >>> We have several conflict with closed sources builds: >>> >>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>> signed and unsigned integer expressions >>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>> signed and unsigned integer expressions >>> >>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>> member function declared in class 'frame' >>> >>> error: no matching function for call to >>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>> >>> I think it is due to changes like next: >>> >>> -#ifdef PPC >>> +#ifdef PPC32 >>> oop* interpreter_frame_mirror_addr() const; >>> >>> >>> Next is easy fix in our closed sources but it requires efforts from our >>> side: >>> >>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>> void MethodHandles::generate_adapters()': >>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>> cannot be used as a function >>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>> cannot be used as a function >>> >>> >>> I would suggest to do such shared changes which affects different builds >>> later after initial push. >>> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>> Hi Vladimir, >>>> >>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>> tested it successfully. In case you experience any problems >>>> please tell me the details so I can fix them. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>> To: Simonis, Volker >>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>> Alan Bateman >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Volker, >>>> >>>> Can you or someone update >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>> I just tried to merge them and build Hotspot on x86 without success. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>> the >>>>> beginning to address a broader audience for the initial discussions. >>>>> >>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>> iris.clark at oracle.com >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> Sorry about this, one more thing about the JEP... >>>>> >>>>> I think that the "Discussion" list probably needs to be updated to be >>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>> as porters-dev. >>>>> >>>>> Thanks, >>>>> >>>>> iris >>>>> >>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi Iris, >>>>> >>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>> something better yesterday in the evening. >>>>> >>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>> it. >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>> >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> I've just updated the JEP according to your suggestions. >>>>> >>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>> repositories" in the revised title is not ideal: >>>>> >>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>> >>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>> >>>>> @@ -1,5 +1,5 @@ >>>>> >>>>> JEP: 175 >>>>> >>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>> >>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>> repositories >>>>> >>>>> Author: Volker Simonis >>>>> >>>>> Organization: SAP AG >>>>> >>>>> Created: 2013/1/11 >>>>> >>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>> about adding features to JDK Release Projects. There are lots of >>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>> additional details. >>>>> >>>>> Perhaps others have suggestions? >>>>> >>>>> Am I right with my assumption that the targeted release will still be >>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>> specified in the JEP specification)? >>>>> >>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>> index [1], see the third column. >>>>> >>>>> Thanks, >>>>> >>>>> Iris >>>>> >>>>> [1]: http://openjdk.java.net/jeps/0 >>>>> >>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, >>>>> >>>>> I've just updated the JEP according to your suggestions. Please find >>>>> the new version attached to this mail (I haven't checked the new >>>>> version >>>>> in until now to give everybody a chance to comment on the changes). >>>>> >>>>> Am I right with my assumption that the targeted release will still be >>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>> specified in the JEP specification)? >>>>> >>>>> In addition to the changes proposed by you I've added the contents of >>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>> to the JEP. >>>>> >>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>> Azeems "PPCAIX plan" document. >>>>> >>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>> that page? >>>>> >>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>> operation:) If that doesn't work so easily, please let me know how I >>>>> could help. >>>>> >>>>> If there are no objections I plan to checkin the new version of the JEP >>>>> tomorrow after our telephone call. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> [2]: >>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>> Bateman; Vladimir Kozlov >>>>> *Subject:* JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>> >>>>> http://openjdk.java.net/jeps/175 >>>>> >>>>> We're actively working to get your JEP to Funded. We had a few >>>>> comments: >>>>> >>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>> >>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>> only covering PPC/AIX. >>>>> >>>>> -Recommend that the second Motivation bullet be modified to make it >>>>> clear that it applies to Hotspot only. >>>>> >>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>> section at the bottom of JEP 1 [1].) >>>>> >>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>> be the JEP's reviewers. Once they're satisfied with your >>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>> line. >>>>> >>>>> Thanks, >>>>> >>>>> Iris Clark >>>>> >>>>> [1]: http://openjdk.java.net/jeps/1 >>>>> >> From david.holmes at oracle.com Thu Jun 13 03:47:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2013 20:47:43 +1000 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> Message-ID: <51B9A34F.8080702@oracle.com> On 13/06/2013 7:53 PM, Lindenmaier, Goetz wrote: > Hi, > > I fixed the jvmg target and prepared a webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ > > Thanks for reviewing, Vladimir. > I need a second reviewer, please. So to clarify, this restores the old core targets but will only actually work on the new ports? If so do we want to validate that in generic_buildcore similar to the way we validate in generic_buildminimal1? There is a huge amount of cleanup I'd like to do in this makefile to remove all the copy'n'paste duplication. :( Thanks, David > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 13. Juni 2013 00:58 > To: Volker Simonis > Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Hi, Volker > > 0001_fix_core_build.patch passed JPRT build/test run so it is good, > consider reviewed (assuming you fix jvmgcore). > > Should we formalize the process to follow our normal openjdk review > process? It will allow other people to see what is coming and to comment > on it as you said and I agree. > > - I will file rfes and add Volker and Goetz to watch list so you get > notifications (I hope) about rfes. > > - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail > aliases. > > - We do reviews and small testing to make sure changes do not break our > builds. > > - You prepare final patch with correct changeset header after we agree > on changes. > > - I push it to staging repo. > > Is this acceptable to you? > > About changeset header: > > : > Summary: > Reviewed-by: + > Contributed-by: > > I don't think you need "Contributed-by:" since Volker could be author. > But it is up to you if you want to mention other contributors. > > 8016476: PPC64 (part 1): reenable CORE build > Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 > Reviewed-by: kvn > > Thanks, > Vladimir > > PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, > check that you get notification. You are on watch list. > > > On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >> Okay, I will add comment to the rfe that CORE target is only used on >> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >> now). >> >> Vladimir >> >> On 6/12/13 11:51 AM, Volker Simonis wrote: >>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>> >>> wrote: >>> >>>> Thanks, Goetz >>>> >>>> I am perfectly fine with such granularity and I can start generating >>>> RFEs. >>>> I filed first: >>>> >>>> 8016476: PPC64 (part 1): reenable CORE build >>>> >>>> >>> Thanks! >>> >>> >>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>> build it >>>> on my Mac: >>>> >>>> >>> We haven't fixed the CORE build on all platforms. It should wok on >>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>> >>> This is the general approach we have taken. So I'm not sure what will be >>> the best way for you to review the changes. But all of the patches >>> from the >>> first series of changes (1-9) won't probably do anything useful on >>> Linux/x86 and Solaris because we haven't fixed the CORE build and the C++ >>> interpreter on that platforms. So building a CORE build or the C++ >>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>> (and was >>> not the scope of this project). >>> >>> I think the review for these patches should only make sure that they >>> don't >>> break anything that worked before an any supported platforms (and >>> trust us >>> that they are good for our platforms:). >>> >>> So in that sense "reenable CORE build" only means to provide the >>> appropriate targets in the Makefiles and not the required source code >>> fixes >>> on all platforms (although they may be trivial/minimal). But if you'd >>> absolutely also want to have a core build on Linux/x86 and Solaris, I can >>> have a look at it. >>> >>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>> gnumake[2]: *** [debugcore] Error 2 >>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>> gnumake: *** [debugcore] Error 2 >>>> >>>> And on SPARC: >>>> >>>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>>> declaration for pd_InlineSmallCode. >>>> >>>> And you should used debugcore instead of jvmgcore: >>>> +all_debugcore: jvmgcore docs export_debug >>>> >>>> I want your changes be perfect from the start ;) >>>> >>> >>> You're right. The renaming of the 'jvmg' target to 'debug' has happened >>> recently ( >>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >>> we haven't adapted it. We will fix this. >>> >>> >>>> And I need to discuss with our embedded group about >>>> 0002_PPC_defines.patch >>>> because it affects them. It may take time. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>> >>>>> Hi Vladimir, >>>>> >>>>> yes, the plan is that each is self contained. When I set up the >>>>> patches I >>>>> built and jckecked each. When I updated them I only built them >>>>> selectively, >>>>> so there might be minor issues. I had planned to assure this once I >>>>> make >>>>> webrevs from the patches. >>>>> >>>>> Some of them might apply in any order, but others depend on previous >>>>> ones, >>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>> before. >>>>> >>>>> The patches work with hs25-b34. >>>>> >>>>> Please tell me if I can do anything to ease your reviewing. >>>>> >>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>> changes necessary to other platform code to a minimum, but also tried >>>>> to avoid strange workarounds. Therefore I for example did change 0002 >>>>> renaming the PPC defines, see the comment there. >>>>> >>>>> If you agree with the granularity of the changes, it would be great >>>>> if you >>>>> could generate bug-ids for them. Maybe at least for the changes >>>>> up to 0016? >>>>> >>>>> Best regards >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov >>>>> [mailto:vladimir.kozlov@**oracle.com >>>>> ] >>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>> To: Lindenmaier, Goetz >>>>> Cc: >>>>> ppc-aix-port-dev at openjdk.java.**net; >>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Thank you, Goetz. >>>>> >>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>> with >>>>> jdk8 and build? Or I should do review all 1-9 >>>>> patches and merge them together into jdk8 to be able build? In >>>>> short, is >>>>> each patch self-contain? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> With my recent changes I removed some of the problems Vladimir >>>>>> mentioned. >>>>>> >>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>> repository, >>>>>> at hotspot/ppc_patches. >>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>> hotspots >>>>>> can be built. >>>>>> >>>>>> The queue contains the changes proposed by me before, with minor >>>>>> changes >>>>>> due >>>>>> to recent development: >>>>>> >>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>> 101-107 C-interpreter improvements >>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>> performant ppc port. >>>>>> Altogether currently 49 changes. >>>>>> >>>>>> Our plan was to propose the changes in the order of the queue for >>>>>> review. I'm happy to create webrevs for any of them. >>>>>> >>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>> changes >>>>>> are more complete. They include all later improvements by fixes or >>>>>> adaptions in merge changes. >>>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>>> queue. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> PS: This can be used as the invokedynamic repository: >>>>>> hg clone >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>>> ppc-hotspot >>>>>> hg clone >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>>> >>>>>> cd stage-hotspot >>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>> hg qpush -a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov >>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>> ] >>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Here is result of my first attempt to build/test ppc changes together >>>>>> with our closed sources. >>>>>> >>>>>> Small problems: >>>>>> >>>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>>> >>>>>> Build on MacOS: >>>>>> >>>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>> >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> >>>>>> >>>>>> We have several conflict with closed sources builds: >>>>>> >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function 'bool >>>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>>> between >>>>>> signed and unsigned integer expressions >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>>> between >>>>>> signed and unsigned integer expressions >>>>>> >>>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>>> member function declared in class 'frame' >>>>>> >>>>>> error: no matching function for call to >>>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>>> uint&)' >>>>>> >>>>>> I think it is due to changes like next: >>>>>> >>>>>> -#ifdef PPC >>>>>> +#ifdef PPC32 >>>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>>> >>>>>> >>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>> our >>>>>> side: >>>>>> >>>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>>> 'static >>>>>> void MethodHandles::generate_**adapters()': >>>>>> src/share/vm/prims/**methodHandles.cpp:68: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> src/share/vm/prims/**methodHandles.cpp:70: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> >>>>>> >>>>>> I would suggest to do such shared changes which affects different >>>>>> builds >>>>>> later after initial push. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>> tested it successfully. In case you experience any problems >>>>>>> please tell me the details so I can fix them. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov >>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>> ] >>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>> To: Simonis, Volker >>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; >>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>> Bateman >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Volker, >>>>>>> >>>>>>> Can you or someone update >>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>>> match latest >>>>>>> sources in >>>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>>> >>>>>>> ? >>>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>> >>>>>>>> >>>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>>> the >>>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>>> >>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>> Ellison; >>>>>>>> iris.clark at oracle.com >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>> >>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>> to be >>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>> listed >>>>>>>> as porters-dev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> iris >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi Iris, >>>>>>>> >>>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>>> something better yesterday in the evening. >>>>>>>> >>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>>> it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Volker >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>> >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>> >>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>>> repositories" in the revised title is not ideal: >>>>>>>> >>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>> >>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>> >>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>> >>>>>>>> JEP: 175 >>>>>>>> >>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>> repositories >>>>>>>> >>>>>>>> Author: Volker Simonis >>>>>>>> >>>>>>>> Organization: SAP AG >>>>>>>> >>>>>>>> Created: 2013/1/11 >>>>>>>> >>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>> Unicode >>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>>> additional details. >>>>>>>> >>>>>>>> Perhaps others have suggestions? >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>> still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>> be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>>> index [1], see the third column. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>> find >>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>> version >>>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>> still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>> be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>> contents of >>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>> "Description" >>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>> Port >>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>> Space" [3] >>>>>>>> to the JEP. >>>>>>>> >>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>> to hold >>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>> >>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>> rights to >>>>>>>> that page? >>>>>>>> >>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>> "PPCAIX >>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>> saw that >>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>> and in >>>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>>> could help. >>>>>>>> >>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>> the JEP >>>>>>>> tomorrow after our telephone call. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> [2]: https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>>> 13729959 >>>>>>>> >>>>>>>> [3]: >>>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>>> Bateman; Vladimir Kozlov >>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>>> >>>>>>>> >>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>> comments: >>>>>>>> >>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>> >>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>> it is >>>>>>>> only covering PPC/AIX. >>>>>>>> >>>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>>> clear that it applies to Hotspot only. >>>>>>>> >>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>> >>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>> up to >>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>> line. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris Clark >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>> >>>>>>>> From coleen.phillimore at oracle.com Thu Jun 13 04:15:09 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 13 Jun 2013 07:15:09 -0400 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> Message-ID: <51B9A9BD.1020205@oracle.com> This is only the makefile changes. Do you intend to sprinkle #if CORE all over the shared sources again? We were really happy when we took that out. Thanks, Coleen On 6/13/2013 5:53 AM, Lindenmaier, Goetz wrote: > Hi, > > I fixed the jvmg target and prepared a webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ > > Thanks for reviewing, Vladimir. > I need a second reviewer, please. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 13. Juni 2013 00:58 > To: Volker Simonis > Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Hi, Volker > > 0001_fix_core_build.patch passed JPRT build/test run so it is good, > consider reviewed (assuming you fix jvmgcore). > > Should we formalize the process to follow our normal openjdk review > process? It will allow other people to see what is coming and to comment > on it as you said and I agree. > > - I will file rfes and add Volker and Goetz to watch list so you get > notifications (I hope) about rfes. > > - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail > aliases. > > - We do reviews and small testing to make sure changes do not break our > builds. > > - You prepare final patch with correct changeset header after we agree > on changes. > > - I push it to staging repo. > > Is this acceptable to you? > > About changeset header: > > : > Summary: > Reviewed-by: + > Contributed-by: > > I don't think you need "Contributed-by:" since Volker could be author. > But it is up to you if you want to mention other contributors. > > 8016476: PPC64 (part 1): reenable CORE build > Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 > Reviewed-by: kvn > > Thanks, > Vladimir > > PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, > check that you get notification. You are on watch list. > > > On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >> Okay, I will add comment to the rfe that CORE target is only used on >> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >> now). >> >> Vladimir >> >> On 6/12/13 11:51 AM, Volker Simonis wrote: >>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>> >>> wrote: >>>> Thanks, Goetz >>>> >>>> I am perfectly fine with such granularity and I can start generating >>>> RFEs. >>>> I filed first: >>>> >>>> 8016476: PPC64 (part 1): reenable CORE build >>>> >>>> >>> Thanks! >>> >>> >>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>> build it >>>> on my Mac: >>>> >>>> >>> We haven't fixed the CORE build on all platforms. It should wok on >>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>> >>> This is the general approach we have taken. So I'm not sure what will be >>> the best way for you to review the changes. But all of the patches >>> from the >>> first series of changes (1-9) won't probably do anything useful on >>> Linux/x86 and Solaris because we haven't fixed the CORE build and the C++ >>> interpreter on that platforms. So building a CORE build or the C++ >>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>> (and was >>> not the scope of this project). >>> >>> I think the review for these patches should only make sure that they >>> don't >>> break anything that worked before an any supported platforms (and >>> trust us >>> that they are good for our platforms:). >>> >>> So in that sense "reenable CORE build" only means to provide the >>> appropriate targets in the Makefiles and not the required source code >>> fixes >>> on all platforms (although they may be trivial/minimal). But if you'd >>> absolutely also want to have a core build on Linux/x86 and Solaris, I can >>> have a look at it. >>> >>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>> gnumake[2]: *** [debugcore] Error 2 >>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>> gnumake: *** [debugcore] Error 2 >>>> >>>> And on SPARC: >>>> >>>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>>> declaration for pd_InlineSmallCode. >>>> >>>> And you should used debugcore instead of jvmgcore: >>>> +all_debugcore: jvmgcore docs export_debug >>>> >>>> I want your changes be perfect from the start ;) >>>> >>> You're right. The renaming of the 'jvmg' target to 'debug' has happened >>> recently ( >>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >>> we haven't adapted it. We will fix this. >>> >>> >>>> And I need to discuss with our embedded group about >>>> 0002_PPC_defines.patch >>>> because it affects them. It may take time. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>> >>>>> Hi Vladimir, >>>>> >>>>> yes, the plan is that each is self contained. When I set up the >>>>> patches I >>>>> built and jckecked each. When I updated them I only built them >>>>> selectively, >>>>> so there might be minor issues. I had planned to assure this once I >>>>> make >>>>> webrevs from the patches. >>>>> >>>>> Some of them might apply in any order, but others depend on previous >>>>> ones, >>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>> before. >>>>> >>>>> The patches work with hs25-b34. >>>>> >>>>> Please tell me if I can do anything to ease your reviewing. >>>>> >>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>> changes necessary to other platform code to a minimum, but also tried >>>>> to avoid strange workarounds. Therefore I for example did change 0002 >>>>> renaming the PPC defines, see the comment there. >>>>> >>>>> If you agree with the granularity of the changes, it would be great >>>>> if you >>>>> could generate bug-ids for them. Maybe at least for the changes >>>>> up to 0016? >>>>> >>>>> Best regards >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov >>>>> [mailto:vladimir.kozlov@**oracle.com >>>>> ] >>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>> To: Lindenmaier, Goetz >>>>> Cc: >>>>> ppc-aix-port-dev at openjdk.java.**net; >>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Thank you, Goetz. >>>>> >>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>> with >>>>> jdk8 and build? Or I should do review all 1-9 >>>>> patches and merge them together into jdk8 to be able build? In >>>>> short, is >>>>> each patch self-contain? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> With my recent changes I removed some of the problems Vladimir >>>>>> mentioned. >>>>>> >>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>> repository, >>>>>> at hotspot/ppc_patches. >>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>> hotspots >>>>>> can be built. >>>>>> >>>>>> The queue contains the changes proposed by me before, with minor >>>>>> changes >>>>>> due >>>>>> to recent development: >>>>>> >>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>> 101-107 C-interpreter improvements >>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>> performant ppc port. >>>>>> Altogether currently 49 changes. >>>>>> >>>>>> Our plan was to propose the changes in the order of the queue for >>>>>> review. I'm happy to create webrevs for any of them. >>>>>> >>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>> changes >>>>>> are more complete. They include all later improvements by fixes or >>>>>> adaptions in merge changes. >>>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>>> queue. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> PS: This can be used as the invokedynamic repository: >>>>>> hg clone >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>>> ppc-hotspot >>>>>> hg clone >>>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>>> >>>>>> cd stage-hotspot >>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>> hg qpush -a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov >>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>> ] >>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Here is result of my first attempt to build/test ppc changes together >>>>>> with our closed sources. >>>>>> >>>>>> Small problems: >>>>>> >>>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>>> >>>>>> Build on MacOS: >>>>>> >>>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>> >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> >>>>>> >>>>>> We have several conflict with closed sources builds: >>>>>> >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function 'bool >>>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>>> between >>>>>> signed and unsigned integer expressions >>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>>> between >>>>>> signed and unsigned integer expressions >>>>>> >>>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>>> member function declared in class 'frame' >>>>>> >>>>>> error: no matching function for call to >>>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>>> uint&)' >>>>>> >>>>>> I think it is due to changes like next: >>>>>> >>>>>> -#ifdef PPC >>>>>> +#ifdef PPC32 >>>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>>> >>>>>> >>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>> our >>>>>> side: >>>>>> >>>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>>> 'static >>>>>> void MethodHandles::generate_**adapters()': >>>>>> src/share/vm/prims/**methodHandles.cpp:68: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> src/share/vm/prims/**methodHandles.cpp:70: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> >>>>>> >>>>>> I would suggest to do such shared changes which affects different >>>>>> builds >>>>>> later after initial push. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>> tested it successfully. In case you experience any problems >>>>>>> please tell me the details so I can fix them. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov >>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>> ] >>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>> To: Simonis, Volker >>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; >>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>> Bateman >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Volker, >>>>>>> >>>>>>> Can you or someone update >>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>>> match latest >>>>>>> sources in >>>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>>> >>>>>>> ? >>>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>> >>>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>>> the >>>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>>> >>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>> Ellison; >>>>>>>> iris.clark at oracle.com >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>> >>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>> to be >>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>> listed >>>>>>>> as porters-dev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> iris >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi Iris, >>>>>>>> >>>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>>> something better yesterday in the evening. >>>>>>>> >>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>>> it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Volker >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>> >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>> >>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>>> repositories" in the revised title is not ideal: >>>>>>>> >>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>> >>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>> >>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>> >>>>>>>> JEP: 175 >>>>>>>> >>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>> repositories >>>>>>>> >>>>>>>> Author: Volker Simonis >>>>>>>> >>>>>>>> Organization: SAP AG >>>>>>>> >>>>>>>> Created: 2013/1/11 >>>>>>>> >>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>> Unicode >>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>>> additional details. >>>>>>>> >>>>>>>> Perhaps others have suggestions? >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>> still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>> be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>>> index [1], see the third column. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>> find >>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>> version >>>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>> still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>> be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>> contents of >>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>> "Description" >>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>> Port >>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>> Space" [3] >>>>>>>> to the JEP. >>>>>>>> >>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>> to hold >>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>> >>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>> rights to >>>>>>>> that page? >>>>>>>> >>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>> "PPCAIX >>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>> saw that >>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>> and in >>>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>>> could help. >>>>>>>> >>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>> the JEP >>>>>>>> tomorrow after our telephone call. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> [2]: https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>>> 13729959 >>>>>>>> >>>>>>>> [3]: >>>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------**------------------------------** >>>>>>>> ------------ >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>>> Bateman; Vladimir Kozlov >>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>>> >>>>>>>> >>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>> comments: >>>>>>>> >>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>> >>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>> it is >>>>>>>> only covering PPC/AIX. >>>>>>>> >>>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>>> clear that it applies to Hotspot only. >>>>>>>> >>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>> >>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>> up to >>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>> line. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris Clark >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>> >>>>>>>> From erik.helin at oracle.com Thu Jun 13 04:29:43 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Thu, 13 Jun 2013 11:29:43 +0000 Subject: hg: hsx/hsx24/hotspot: 8016170: GC id variable in gcTrace.cpp should use typedef GCId Message-ID: <20130613112947.8FCCC481BE@hg.openjdk.java.net> Changeset: 6424d602021e Author: ehelin Date: 2013-06-12 15:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6424d602021e 8016170: GC id variable in gcTrace.cpp should use typedef GCId Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/shared/gcTrace.cpp From volker.simonis at gmail.com Thu Jun 13 05:18:07 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 13 Jun 2013 14:18:07 +0200 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: <51B9A9BD.1020205@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> <51B9A9BD.1020205@oracle.com> Message-ID: No, we haven't introduced a single "#if CORE" in the sources. As Goetz wrote earlier, you can see all the changes in the Mercurial patch queue at http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches. We used the CORE build to bootstrap our port. It doesn't mean that it is minimal (in the sense that it doesn't contain unnecessary code). But it creates a running, interpreter-only VM which can at least be used to bootstrap the build. And it really required only minimal shared code changes (see changes 0001... to 0008 in the patch queue). Together with the ppc-specific files from change '0009_linux_ppc_files.patch' this gives you a working c++ interpreter VM on Linux/PPC64. Regards, Volker On Thu, Jun 13, 2013 at 1:15 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > This is only the makefile changes. Do you intend to sprinkle #if CORE > all over the shared sources again? > We were really happy when we took that out. > > Thanks, > Coleen > > > On 6/13/2013 5:53 AM, Lindenmaier, Goetz wrote: > >> Hi, >> >> I fixed the jvmg target and prepared a webrev: >> http://cr.openjdk.java.net/~**goetz/webrevs/8016476-CORE/ >> >> Thanks for reviewing, Vladimir. >> I need a second reviewer, please. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.**java.net[mailto: >> hotspot-dev-bounces@**openjdk.java.net] >> On Behalf Of Vladimir Kozlov >> Sent: Donnerstag, 13. Juni 2013 00:58 >> To: Volker Simonis >> Cc: ppc-aix-port-dev at openjdk.java.**net; >> Chris Plummer; hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Hi, Volker >> >> 0001_fix_core_build.patch passed JPRT build/test run so it is good, >> consider reviewed (assuming you fix jvmgcore). >> >> Should we formalize the process to follow our normal openjdk review >> process? It will allow other people to see what is coming and to comment >> on it as you said and I agree. >> >> - I will file rfes and add Volker and Goetz to watch list so you get >> notifications (I hope) about rfes. >> >> - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail >> aliases. >> >> - We do reviews and small testing to make sure changes do not break our >> builds. >> >> - You prepare final patch with correct changeset header after we agree >> on changes. >> >> - I push it to staging repo. >> >> Is this acceptable to you? >> >> About changeset header: >> >> : >> Summary: >> Reviewed-by: + >> Contributed-by: >> >> I don't think you need "Contributed-by:" since Volker could be author. >> But it is up to you if you want to mention other contributors. >> >> 8016476: PPC64 (part 1): reenable CORE build >> Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 >> Reviewed-by: kvn >> >> Thanks, >> Vladimir >> >> PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, >> check that you get notification. You are on watch list. >> >> >> On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >> >>> Okay, I will add comment to the rfe that CORE target is only used on >>> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >>> now). >>> >>> Vladimir >>> >>> On 6/12/13 11:51 AM, Volker Simonis wrote: >>> >>>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>>> >>> >>>>> wrote: >>>>> Thanks, Goetz >>>>> >>>>> I am perfectly fine with such granularity and I can start generating >>>>> RFEs. >>>>> I filed first: >>>>> >>>>> 8016476: PPC64 (part 1): reenable CORE build >>>>> >>>>> >>>>> Thanks! >>>> >>>> >>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>>> build it >>>>> on my Mac: >>>>> >>>>> >>>>> We haven't fixed the CORE build on all platforms. It should wok on >>>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>>> >>>> This is the general approach we have taken. So I'm not sure what will be >>>> the best way for you to review the changes. But all of the patches >>>> from the >>>> first series of changes (1-9) won't probably do anything useful on >>>> Linux/x86 and Solaris because we haven't fixed the CORE build and the >>>> C++ >>>> interpreter on that platforms. So building a CORE build or the C++ >>>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>>> (and was >>>> not the scope of this project). >>>> >>>> I think the review for these patches should only make sure that they >>>> don't >>>> break anything that worked before an any supported platforms (and >>>> trust us >>>> that they are good for our platforms:). >>>> >>>> So in that sense "reenable CORE build" only means to provide the >>>> appropriate targets in the Makefiles and not the required source code >>>> fixes >>>> on all platforms (although they may be trivial/minimal). But if you'd >>>> absolutely also want to have a core build on Linux/x86 and Solaris, I >>>> can >>>> have a look at it. >>>> >>>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>> >>>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>>> gnumake[2]: *** [debugcore] Error 2 >>>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>>> gnumake: *** [debugcore] Error 2 >>>>> >>>>> And on SPARC: >>>>> >>>>> src/share/vm/runtime/globals.****hpp", line 170: Error: Multiple >>>>> declaration for pd_InlineSmallCode. >>>>> >>>>> And you should used debugcore instead of jvmgcore: >>>>> +all_debugcore: jvmgcore docs export_debug >>>>> >>>>> I want your changes be perfect from the start ;) >>>>> >>>>> You're right. The renaming of the 'jvmg' target to 'debug' has >>>> happened >>>> recently ( >>>> http://hg.openjdk.java.net/**hsx/hotspot-main/hotspot/rev/** >>>> f36e073d56a4) >>>> and >>>> we haven't adapted it. We will fix this. >>>> >>>> >>>> And I need to discuss with our embedded group about >>>>> 0002_PPC_defines.patch >>>>> because it affects them. It may take time. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> Hi Vladimir, >>>>>> >>>>>> yes, the plan is that each is self contained. When I set up the >>>>>> patches I >>>>>> built and jckecked each. When I updated them I only built them >>>>>> selectively, >>>>>> so there might be minor issues. I had planned to assure this once I >>>>>> make >>>>>> webrevs from the patches. >>>>>> >>>>>> Some of them might apply in any order, but others depend on previous >>>>>> ones, >>>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>>> before. >>>>>> >>>>>> The patches work with hs25-b34. >>>>>> >>>>>> Please tell me if I can do anything to ease your reviewing. >>>>>> >>>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>>> changes necessary to other platform code to a minimum, but also tried >>>>>> to avoid strange workarounds. Therefore I for example did change 0002 >>>>>> renaming the PPC defines, see the comment there. >>>>>> >>>>>> If you agree with the granularity of the changes, it would be great >>>>>> if you >>>>>> could generate bug-ids for them. Maybe at least for the changes >>>>>> up to 0016? >>>>>> >>>>>> Best regards >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov >>>>>> [mailto:vladimir.kozlov@**orac**le.com < >>>>>> vladimir.kozlov at oracle.**com > >>>>>> ] >>>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: >>>>>> ppc-aix-port-dev at openjdk.java.****net>>>>> openjdk.java.net >; >>>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris >>>>>> Plummer >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Thank you, Goetz. >>>>>> >>>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>>> with >>>>>> jdk8 and build? Or I should do review all 1-9 >>>>>> patches and merge them together into jdk8 to be able build? In >>>>>> short, is >>>>>> each patch self-contain? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> With my recent changes I removed some of the problems Vladimir >>>>>>> mentioned. >>>>>>> >>>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>>> repository, >>>>>>> at hotspot/ppc_patches. >>>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>>> hotspots >>>>>>> can be built. >>>>>>> >>>>>>> The queue contains the changes proposed by me before, with minor >>>>>>> changes >>>>>>> due >>>>>>> to recent development: >>>>>>> >>>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>>> 101-107 C-interpreter improvements >>>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>>> performant ppc port. >>>>>>> Altogether currently 49 changes. >>>>>>> >>>>>>> Our plan was to propose the changes in the order of the queue for >>>>>>> review. I'm happy to create webrevs for any of them. >>>>>>> >>>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>>> changes >>>>>>> are more complete. They include all later improvements by fixes or >>>>>>> adaptions in merge changes. >>>>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>>>> queue. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> PS: This can be used as the invokedynamic repository: >>>>>>> hg clone >>>>>>> http://hg.openjdk.java.net/****ppc-aix-port/jdk8/hotspot >>>>>>> >>>>>>> > >>>>>>> ppc-hotspot >>>>>>> hg clone >>>>>>> http://hg.openjdk.java.net/****ppc-aix-port/stage/hotspot >>>>>>> >>>>>>> >stage-**hotspot >>>>>>> >>>>>>> cd stage-hotspot >>>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>>> hg qpush -a >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov >>>>>>> [mailto:vladimir.kozlov@**orac**le.com < >>>>>>> vladimir.kozlov at oracle.**com > >>>>>>> ] >>>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Here is result of my first attempt to build/test ppc changes together >>>>>>> with our closed sources. >>>>>>> >>>>>>> Small problems: >>>>>>> >>>>>>> src/share/vm/memory/****allocation.hpp:209: Trailing whitespace >>>>>>> src/share/vm/memory/****allocation.inline.hpp:121: Trailing >>>>>>> whitespace >>>>>>> src/share/vm/opto/escape.cpp:****2207: Trailing whitespace >>>>>>> src/share/vm/memory/****allocation.hpp:212: Trailing whitespace >>>>>>> src/share/vm/opto/escape.cpp:****2214: Trailing whitespace >>>>>>> >>>>>>> Build on MacOS: >>>>>>> >>>>>>> src/share/vm/opto/****callGenerator.cpp: In member function 'virtual >>>>>>> JVMState* VirtualCallGenerator::****generate(JVMState*)': >>>>>>> src/share/vm/opto/****callGenerator.cpp:204: error: >>>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>>> >>>>>>> agent/src/os/bsd/****MacosxDebuggerLocal.m:54:2: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> agent/src/os/bsd/****MacosxDebuggerLocal.m:167:4: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> agent/src/os/bsd/****MacosxDebuggerLocal.m:591:2: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> >>>>>>> >>>>>>> We have several conflict with closed sources builds: >>>>>>> >>>>>>> src/share/vm/utilities/****elfSymbolTable.cpp: In member function >>>>>>> 'bool >>>>>>> ElfSymbolTable::lookup(****unsigned char*, int*, int*, int*)': >>>>>>> src/share/vm/utilities/****elfSymbolTable.cpp:97: error: comparison >>>>>>> between >>>>>>> signed and unsigned integer expressions >>>>>>> src/share/vm/utilities/****elfSymbolTable.cpp:124: error: comparison >>>>>>> between >>>>>>> signed and unsigned integer expressions >>>>>>> >>>>>>> error: no 'oopDesc** frame::interpreter_frame_****mirror_addr() >>>>>>> const' >>>>>>> member function declared in class 'frame' >>>>>>> >>>>>>> error: no matching function for call to >>>>>>> 'SharedRuntime::c_calling_****convention(BasicType*&, VMRegPair*&, >>>>>>> uint&)' >>>>>>> >>>>>>> I think it is due to changes like next: >>>>>>> >>>>>>> -#ifdef PPC >>>>>>> +#ifdef PPC32 >>>>>>> oop* interpreter_frame_mirror_addr(****) const; >>>>>>> >>>>>>> >>>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>>> our >>>>>>> side: >>>>>>> >>>>>>> src/share/vm/prims/****methodHandles.cpp: In static member function >>>>>>> 'static >>>>>>> void MethodHandles::generate_****adapters()': >>>>>>> src/share/vm/prims/****methodHandles.cpp:68: error: >>>>>>> 'adapter_code_size' >>>>>>> cannot be used as a function >>>>>>> src/share/vm/prims/****methodHandles.cpp:70: error: >>>>>>> 'adapter_code_size' >>>>>>> cannot be used as a function >>>>>>> >>>>>>> >>>>>>> I would suggest to do such shared changes which affects different >>>>>>> builds >>>>>>> later after initial push. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>>> tested it successfully. In case you experience any problems >>>>>>>> please tell me the details so I can fix them. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~****simonis/ppc-aix-port/index.****html >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov >>>>>>>> [mailto:vladimir.kozlov@**orac**le.com < >>>>>>>> vladimir.kozlov at oracle.**com > >>>>>>>> ] >>>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>>> To: Simonis, Volker >>>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; >>>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>>> Bateman >>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>> >>>>>>>> Volker, >>>>>>>> >>>>>>>> Can you or someone update >>>>>>>> http://hg.openjdk.java.net/****ppc-aix-port/jdk8/hotspot >>>>>>>> >>>>>>>> >to >>>>>>>> match latest >>>>>>>> sources in >>>>>>>> http://hg.openjdk.java.net/****jdk8/jdk8/hotspot >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> ? >>>>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>>> >>>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' >>>>>>>>> in >>>>>>>>> the >>>>>>>>> beginning to address a broader audience for the initial >>>>>>>>> discussions. >>>>>>>>> >>>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------****----------------------------** >>>>>>>>> --** >>>>>>>>> ------------ >>>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>> Ellison; >>>>>>>>> iris.clark at oracle.com >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>>> >>>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>>> to be >>>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>>> listed >>>>>>>>> as porters-dev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> iris >>>>>>>>> >>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com****] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>> Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi Iris, >>>>>>>>> >>>>>>>>> you're right, the title is too clumsy - I just couldn't come up >>>>>>>>> with >>>>>>>>> something better yesterday in the evening. >>>>>>>>> >>>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll >>>>>>>>> take >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> ------------------------------****----------------------------** >>>>>>>>> --** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>>> >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>>> >>>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>>>> repositories" in the revised title is not ideal: >>>>>>>>> >>>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>>> >>>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>>> >>>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>>> >>>>>>>>> JEP: 175 >>>>>>>>> >>>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>> >>>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>>> repositories >>>>>>>>> >>>>>>>>> Author: Volker Simonis >>>>>>>>> >>>>>>>>> Organization: SAP AG >>>>>>>>> >>>>>>>>> Created: 2013/1/11 >>>>>>>>> >>>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are >>>>>>>>> all >>>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>>> Unicode >>>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself >>>>>>>>> contains >>>>>>>>> additional details. >>>>>>>>> >>>>>>>>> Perhaps others have suggestions? >>>>>>>>> >>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>> still be >>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>> be set >>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>> specified in the JEP specification)? >>>>>>>>> >>>>>>>>> Yes. Once that field is populated, the value will appear in the >>>>>>>>> JEP >>>>>>>>> index [1], see the third column. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Iris >>>>>>>>> >>>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>>> >>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com****] >>>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>>> find >>>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>>> version >>>>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>>>> >>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>> still be >>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>> be set >>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>> specified in the JEP specification)? >>>>>>>>> >>>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>>> contents of >>>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>>> "Description" >>>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>>> Port >>>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>>> Space" [3] >>>>>>>>> to the JEP. >>>>>>>>> >>>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>>> to hold >>>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>>> >>>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>>> rights to >>>>>>>>> that page? >>>>>>>>> >>>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>>> "PPCAIX >>>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>>> saw that >>>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>>> and in >>>>>>>>> my unlimited naivety I imagine this could be a simple >>>>>>>>> copy-and-paste >>>>>>>>> operation:) If that doesn't work so easily, please let me know how >>>>>>>>> I >>>>>>>>> could help. >>>>>>>>> >>>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>>> the JEP >>>>>>>>> tomorrow after our telephone call. >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> [2]: https://wiki.openjdk.java.net/****pages/viewpage.action?** >>>>>>>>> pageId=** >>>>>>>>> 13729959>>>>>>>> action?pageId=13729959 >>>>>>>>> > >>>>>>>>> >>>>>>>>> [3]: >>>>>>>>> https://wiki.openjdk.java.net/****display/PPCAIXPort >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------****----------------------------** >>>>>>>>> --** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* iris.clark at oracle.com ****; >>>>>>>>> Alan >>>>>>>>> Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>> >>>>>>>>> http://openjdk.java.net/jeps/****175 >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>>> comments: >>>>>>>>> >>>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>>> >>>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>>> it is >>>>>>>>> only covering PPC/AIX. >>>>>>>>> >>>>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>>>> clear that it applies to Hotspot only. >>>>>>>>> >>>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>>> >>>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>>> up to >>>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>>> line. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Iris Clark >>>>>>>>> >>>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>>> >>>>>>>>> >>>>>>>>> > From goetz.lindenmaier at sap.com Thu Jun 13 05:29:44 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Jun 2013 12:29:44 +0000 Subject: JEP 175 - Review comments In-Reply-To: <51B99E7D.5010605@oracle.com> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> <51B93259.7060206@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> <51B99E7D.5010605@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFDB890@DEWDFEMB12A.global.corp.sap> Hi David, I understand there are three cases: 1.) A real 32-bit processor/instruction set 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. 3.) A 64-bit processor/instruction set using 32-bit addresses etc. My naming is the following: 1.) PPC32 2.) PPC64 & LP64 3.) PPC64 & !LP64. PPC should be valid for all. I understood your port is of kind 1., but I really don?t know that. Thus I changed the existing PPC guards to PPC32 where we don't need the guarded code. This distinction seems to me to fit well in os_bsd_zero.hpp os_linux_zero.hpp sharedRuntime.cpp sharedRuntime.hpp vm_version.cpp / FLOAT_ARCH_STR You are right for the defines in frame.hpp/frame.cpp Here I guard what is probably an implementation detail of your port and not a restriction of the architecture. But maybe you can clean up this piece of code, or tell me by what else I should guard this. In patch 0008 you see the libarch adaption: LIBARCH/ppc64 = ppc64 LIBARCH/ppc = ppc I'm happy to adapt the naming of your port however you want to. Best regards, Goetz. yes, I changed PPC to PPC32 wherever we don't need the special case in our port. I do not know why you implemented the special cases, and maybe you need a define that is more verbose about the reason. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Donnerstag, 13. Juni 2013 12:27 To: Lindenmaier, Goetz Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: JEP 175 - Review comments Hi Goetz, On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: > Hi, > > @Chris: -DPPC32 needs to be set in make//platform_ppc32. I think BUILD_ARCH would also need to be ppc32 to pick that up - but then we would need to change LIB_ARCH back to ppc. Is the 64-bit port using ppc64 as the LIB_ARCH? > @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, > and in macros.hpp you find Okay I confess, it was a bad idea to generalize that given that out of the four platforms we support in the Oracle JDK, two are 32-bit only, so we only have sparc and x86 as examples. On sparc we only use SPARC and _LP64=1 to indicate things (and obviously in sparc specific files anything not in _LP64=1 is implicitly 32-bit). For x86 .... well x86 is a bit of a historical mess. So yes all those defines exist but the predominant form in shared code is X86 and AMD64 (as a synonym for LP64=1). IA32 exists but is barely used and arguably most of the places it remains are relics from before the 32-bit and 64-bit x86 code merge took place. So we have some historical baggage there. My main concern with the PPC, PPC32, PPC64 proposal is that the patch I saw: http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch seemed to use PPC32 in places I would not expect. I'm starting to feel that this is not 32 vs 64 per-se, but that PPC32 is being used as a way to flag "PPC Oracle" in a way that excludes it from use by the PPC64 port. If that is the case, and I can understand that it may well be given the existing PPC specific code was indeed put in place to support Oracle's PPC port, then perhaps we can look at ways of dealing with that without using what seems to me to be an artificial 32 vs 64-bit distinction? Aside: I would greatly prefer if ARM and PPC were never mentioned in the (existing) openjdk code, but that would require a level of refactoring in places that no-one unfortunately has the time to do. That said perhaps there are some places where a cleaner separation is possible. There are also places where compiler defines could be used to set string values rather than using the cpu ifdefs ie: #ifdef PPC #define CPU "ppc" etc David ----- > > #if defined(IA32) || defined(AMD64) > #define X86 > #define X86_ONLY(code) code > #define NOT_X86(code) > #else > #undef X86 > #define X86_ONLY(code) > #define NOT_X86(code) code > #endif > > It's just not that obvious as the names of these platforms > are messed up. On PPC I wanted to follow a clean approach. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 13. Juni 2013 04:46 > To: Lindenmaier, Goetz > Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Just adding my 2c from what was an internal discussion but is not in any > way confidential: > > We don't use 3 architecture designators on other platforms to > distinguish between "common", 32-bit and 64-bit, so why do we need to do > so for PPC ? > > The normal approach would be to add _LP64=1 specific ifdefs within an > architectural ifdef. > > This change (PPC32 usage) seems to be introducing unnecessary changes > and inconsistency with how 32-bit vs 64-bit is generally handled. > > Further, it is far from obvious from the patch that code now flagged as > PPC32 is indeed 32-bit specific rather than common! > > David > ----- > > On 13/06/2013 5:54 AM, Chris Plummer wrote: >> Hi Goetz, >> >> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >> make/linux/platform_ppc. >> >> There are a lot of PPC references in c1 that don't appear to have been >> addressed. >> >> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >> allowing you to use >> >> #ifdef PPC >> >> rather than >> >> #if defined(PPC32) || defined(PPC64) >> >> best regards, >> >> Chris >> >> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> With my recent changes I removed some of the problems Vladimir mentioned. >>> >>> I also added the patches queue I maintain into our jdk8/hotspot >>> repository, >>> at hotspot/ppc_patches. >>> Applied to the staging hotspot directory, the linuxppc and aixppc >>> hotspots >>> can be built. >>> >>> The queue contains the changes proposed by me before, with minor >>> changes due >>> to recent development: >>> >>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>> 101-107 C-interpreter improvements >>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>> performant ppc port. >>> Altogether currently 49 changes. >>> >>> Our plan was to propose the changes in the order of the queue for >>> review. I'm happy to create webrevs for any of them. >>> >>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>> are more complete. They include all later improvements by fixes or >>> adaptions in merge changes. >>> For why and where I renamed PPC to PPC32 see the second change in the >>> queue. >>> >>> Best regards, >>> Goetz. >>> >>> >>> PS: This can be used as the invokedynamic repository: >>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>> ppc-hotspot >>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>> stage-hotspot >>> cd stage-hotspot >>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>> hg qpush -a >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 11. Juni 2013 18:34 >>> To: Lindenmaier, Goetz >>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>> Subject: Re: JEP 175 - Review comments >>> >>> Here is result of my first attempt to build/test ppc changes together >>> with our closed sources. >>> >>> Small problems: >>> >>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>> >>> Build on MacOS: >>> >>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>> src/share/vm/opto/callGenerator.cpp:204: error: >>> 'zero_page_read_protected' is not a member of 'os' >>> >>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>> UNSUPPORTED_ARCH >>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>> UNSUPPORTED_ARCH >>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>> UNSUPPORTED_ARCH >>> >>> >>> We have several conflict with closed sources builds: >>> >>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>> signed and unsigned integer expressions >>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>> signed and unsigned integer expressions >>> >>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>> member function declared in class 'frame' >>> >>> error: no matching function for call to >>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>> >>> I think it is due to changes like next: >>> >>> -#ifdef PPC >>> +#ifdef PPC32 >>> oop* interpreter_frame_mirror_addr() const; >>> >>> >>> Next is easy fix in our closed sources but it requires efforts from our >>> side: >>> >>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>> void MethodHandles::generate_adapters()': >>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>> cannot be used as a function >>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>> cannot be used as a function >>> >>> >>> I would suggest to do such shared changes which affects different builds >>> later after initial push. >>> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>> Hi Vladimir, >>>> >>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>> tested it successfully. In case you experience any problems >>>> please tell me the details so I can fix them. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>> To: Simonis, Volker >>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>> Alan Bateman >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Volker, >>>> >>>> Can you or someone update >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>> I just tried to merge them and build Hotspot on x86 without success. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>> the >>>>> beginning to address a broader audience for the initial discussions. >>>>> >>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>> iris.clark at oracle.com >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> Sorry about this, one more thing about the JEP... >>>>> >>>>> I think that the "Discussion" list probably needs to be updated to be >>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>> as porters-dev. >>>>> >>>>> Thanks, >>>>> >>>>> iris >>>>> >>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi Iris, >>>>> >>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>> something better yesterday in the evening. >>>>> >>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>> it. >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>> >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> I've just updated the JEP according to your suggestions. >>>>> >>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>> repositories" in the revised title is not ideal: >>>>> >>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>> >>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>> >>>>> @@ -1,5 +1,5 @@ >>>>> >>>>> JEP: 175 >>>>> >>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>> >>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>> repositories >>>>> >>>>> Author: Volker Simonis >>>>> >>>>> Organization: SAP AG >>>>> >>>>> Created: 2013/1/11 >>>>> >>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>> about adding features to JDK Release Projects. There are lots of >>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>> additional details. >>>>> >>>>> Perhaps others have suggestions? >>>>> >>>>> Am I right with my assumption that the targeted release will still be >>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>> specified in the JEP specification)? >>>>> >>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>> index [1], see the third column. >>>>> >>>>> Thanks, >>>>> >>>>> Iris >>>>> >>>>> [1]: http://openjdk.java.net/jeps/0 >>>>> >>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>> *Subject:* RE: JEP 175 - Review comments >>>>> >>>>> Hi, >>>>> >>>>> I've just updated the JEP according to your suggestions. Please find >>>>> the new version attached to this mail (I haven't checked the new >>>>> version >>>>> in until now to give everybody a chance to comment on the changes). >>>>> >>>>> Am I right with my assumption that the targeted release will still be >>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>> specified in the JEP specification)? >>>>> >>>>> In addition to the changes proposed by you I've added the contents of >>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>> to the JEP. >>>>> >>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>> Azeems "PPCAIX plan" document. >>>>> >>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>> that page? >>>>> >>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>> operation:) If that doesn't work so easily, please let me know how I >>>>> could help. >>>>> >>>>> If there are no objections I plan to checkin the new version of the JEP >>>>> tomorrow after our telephone call. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> [2]: >>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>> Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>> ; Tim Ellison >>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>> Bateman; Vladimir Kozlov >>>>> *Subject:* JEP 175 - Review comments >>>>> >>>>> Hi, Volker. >>>>> >>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>> >>>>> http://openjdk.java.net/jeps/175 >>>>> >>>>> We're actively working to get your JEP to Funded. We had a few >>>>> comments: >>>>> >>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>> >>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>> only covering PPC/AIX. >>>>> >>>>> -Recommend that the second Motivation bullet be modified to make it >>>>> clear that it applies to Hotspot only. >>>>> >>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>> section at the bottom of JEP 1 [1].) >>>>> >>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>> be the JEP's reviewers. Once they're satisfied with your >>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>> line. >>>>> >>>>> Thanks, >>>>> >>>>> Iris Clark >>>>> >>>>> [1]: http://openjdk.java.net/jeps/1 >>>>> >> From mikael.gerdin at oracle.com Thu Jun 13 06:07:02 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 13 Jun 2013 15:07:02 +0200 Subject: RFR (S): [increase HeapBaseMinAddress for G1] 8012265: VM often crashes on solaris with a lot of memory In-Reply-To: <51B96D7E.7090201@oracle.com> References: <51B96D7E.7090201@oracle.com> Message-ID: <51B9C3F6.10509@oracle.com> Bengt, On 2013-06-13 08:58, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~brutisso/8012265/webrev.00/ this looks good to me. /Mikael > > Sending this to the broad hotspot list since it affects compressed oops, > which is a VM wide concern. > > Background: > > The G1 GC uses malloc extensively to allocate auxiliary data structures. > On Solaris malloc requires a consecutive chunk of memory for the C-heap. > It picks this chunk in the low addresses so when hotspot maps the Java > heap in the low addresses to get compressed oops we limit the available > memory for the C-heap on Solaris. > > For compressed oops the Java heap is mapped at HeapBaseMinAddress, which > by default is 2GB on all platforms except Solaris x86 where it is 256MB. > If we have a large Solaris x86 we get many GC worker threads and many G1 > heap regions. All of them requiring substantial C-heap allocations. > > The combination of a limited C-heap and a lot of mallocs for G1 may > cause us to run out of memory on large Solaris x86 machines, even with > our default settings. > > The long term solution is to change G1 to be more efficient about its > memory consumption and preferably use mapped memory instead of malloced > memory. This is a lot of work, but will definitely have to be done. > > A short term solution to reduce the risk of running out of memory is to > increase the default value of HeapBaseMinAddress for G1. That is what my > proposed patch does. > > This will reduce the maximum possible heap sizes for compressed oops > without a heap base. Shifted compressed oops will be reduced from almost > 32g to 31g and unshifted compressed oops from almost 4g to 3g. Still > more than on any other platform where HeapBaseMinAddress=2g by default. > It will only affect G1 and it can be overridden by explicitly setting > HeapBaseMinAddress on the command line. > > I've filed this enhancement in JBS to track the work to change back the > default value: > > JDK-8016505: G1: Revert back to use HeapBaseMinAddress=256m on Solaris x86 > > Thanks, > Bengt From coleen.phillimore at oracle.com Thu Jun 13 06:20:29 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 13 Jun 2013 09:20:29 -0400 Subject: RFR (S): [increase HeapBaseMinAddress for G1] 8012265: VM often crashes on solaris with a lot of memory In-Reply-To: <51B9C3F6.10509@oracle.com> References: <51B96D7E.7090201@oracle.com> <51B9C3F6.10509@oracle.com> Message-ID: <51B9C71D.80804@oracle.com> Looks good to me too. Coleen On 06/13/2013 09:07 AM, Mikael Gerdin wrote: > Bengt, > > On 2013-06-13 08:58, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of reviews for this change? >> >> http://cr.openjdk.java.net/~brutisso/8012265/webrev.00/ > > this looks good to me. > > /Mikael > >> >> Sending this to the broad hotspot list since it affects compressed oops, >> which is a VM wide concern. >> >> Background: >> >> The G1 GC uses malloc extensively to allocate auxiliary data structures. >> On Solaris malloc requires a consecutive chunk of memory for the C-heap. >> It picks this chunk in the low addresses so when hotspot maps the Java >> heap in the low addresses to get compressed oops we limit the available >> memory for the C-heap on Solaris. >> >> For compressed oops the Java heap is mapped at HeapBaseMinAddress, which >> by default is 2GB on all platforms except Solaris x86 where it is 256MB. >> If we have a large Solaris x86 we get many GC worker threads and many G1 >> heap regions. All of them requiring substantial C-heap allocations. >> >> The combination of a limited C-heap and a lot of mallocs for G1 may >> cause us to run out of memory on large Solaris x86 machines, even with >> our default settings. >> >> The long term solution is to change G1 to be more efficient about its >> memory consumption and preferably use mapped memory instead of malloced >> memory. This is a lot of work, but will definitely have to be done. >> >> A short term solution to reduce the risk of running out of memory is to >> increase the default value of HeapBaseMinAddress for G1. That is what my >> proposed patch does. >> >> This will reduce the maximum possible heap sizes for compressed oops >> without a heap base. Shifted compressed oops will be reduced from almost >> 32g to 31g and unshifted compressed oops from almost 4g to 3g. Still >> more than on any other platform where HeapBaseMinAddress=2g by default. >> It will only affect G1 and it can be overridden by explicitly setting >> HeapBaseMinAddress on the command line. >> >> I've filed this enhancement in JBS to track the work to change back the >> default value: >> >> JDK-8016505: G1: Revert back to use HeapBaseMinAddress=256m on >> Solaris x86 >> >> Thanks, >> Bengt From coleen.phillimore at oracle.com Thu Jun 13 06:31:31 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 13 Jun 2013 09:31:31 -0400 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> <51B9A9BD.1020205@oracle.com> Message-ID: <51B9C9B3.8020707@oracle.com> On 06/13/2013 08:18 AM, Volker Simonis wrote: > No, we haven't introduced a single "#if CORE" in the sources. Good! > > As Goetz wrote earlier, you can see all the changes in the Mercurial > patch queue at > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches. Wow... > > We used the CORE build to bootstrap our port. It doesn't mean that it > is minimal (in the sense that it doesn't contain unnecessary code). > But it creates a running, interpreter-only VM which can at least be > used to bootstrap the build. And it really required only minimal > shared code changes (see changes 0001... to 0008 in the patch queue). > Together with the ppc-specific files from change > '0009_linux_ppc_files.patch' this gives you a working c++ interpreter > VM on Linux/PPC64. > Okay, that is fine. Thanks, Coleen > Regards, > Volker > > > On Thu, Jun 13, 2013 at 1:15 PM, Coleen Phillimore > > > wrote: > > > This is only the makefile changes. Do you intend to sprinkle #if > CORE all over the shared sources again? > We were really happy when we took that out. > > Thanks, > Coleen > > > On 6/13/2013 5:53 AM, Lindenmaier, Goetz wrote: > > Hi, > > I fixed the jvmg target and prepared a webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ > > > Thanks for reviewing, Vladimir. > I need a second reviewer, please. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net > > [mailto:hotspot-dev-bounces at openjdk.java.net > ] On Behalf Of > Vladimir Kozlov > Sent: Donnerstag, 13. Juni 2013 00:58 > To: Volker Simonis > Cc: ppc-aix-port-dev at openjdk.java.net > ; Chris Plummer; > hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Hi, Volker > > 0001_fix_core_build.patch passed JPRT build/test run so it is > good, > consider reviewed (assuming you fix jvmgcore). > > Should we formalize the process to follow our normal openjdk > review > process? It will allow other people to see what is coming and > to comment > on it as you said and I agree. > > - I will file rfes and add Volker and Goetz to watch list so > you get > notifications (I hope) about rfes. > > - You submit webrev for reviews to ppc-aix-port-dev, > hotspot-dev mail > aliases. > > - We do reviews and small testing to make sure changes do not > break our > builds. > > - You prepare final patch with correct changeset header after > we agree > on changes. > > - I push it to staging repo. > > Is this acceptable to you? > > About changeset header: > > : > Summary: > Reviewed-by: + > Contributed-by: > > I don't think you need "Contributed-by:" since Volker could be > author. > But it is up to you if you want to mention other contributors. > > 8016476: PPC64 (part 1): reenable CORE build > Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 > Reviewed-by: kvn > > Thanks, > Vladimir > > PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. > Please, > check that you get notification. You are on watch list. > > > On 6/12/13 12:18 PM, Vladimir Kozlov wrote: > > Okay, I will add comment to the rfe that CORE target is > only used on > Linux/PPC64 and AIX/PPC64 and Oracle will not support it > (at least for > now). > > Vladimir > > On 6/12/13 11:51 AM, Volker Simonis wrote: > > On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov > > > wrote: > Thanks, Goetz > > I am perfectly fine with such granularity and I > can start generating > RFEs. > I filed first: > > 8016476: PPC64 (part 1): reenable CORE build > > > Thanks! > > > Are you sure that 0001_fix_core_build.patch is > complete? I can't > build it > on my Mac: > > > We haven't fixed the CORE build on all platforms. It > should wok on > Linux/PPC64 and AIX/PPC64 and not break anything else. > > This is the general approach we have taken. So I'm not > sure what will be > the best way for you to review the changes. But all of > the patches > from the > first series of changes (1-9) won't probably do > anything useful on > Linux/x86 and Solaris because we haven't fixed the > CORE build and the C++ > interpreter on that platforms. So building a CORE > build or the C++ > interpreter on Linux/x86, Solaris or Mac will probably > not succeed > (and was > not the scope of this project). > > I think the review for these patches should only make > sure that they > don't > break anything that worked before an any supported > platforms (and > trust us > that they are good for our platforms:). > > So in that sense "reenable CORE build" only means to > provide the > appropriate targets in the Makefiles and not the > required source code > fixes > on all platforms (although they may be > trivial/minimal). But if you'd > absolutely also want to have a core build on Linux/x86 > and Solaris, I can > have a look at it. > > gnumake[4]: *** No rule to make target `dtrace_stuff'. > Stop. > > gnumake[3]: *** [dtrace_stuff] Error 2 > gnumake[2]: *** [debugcore] Error 2 > gnumake[1]: *** [generic_buildcore] Error 2 > gnumake: *** [debugcore] Error 2 > > And on SPARC: > > src/share/vm/runtime/globals.**hpp", line 170: > Error: Multiple > declaration for pd_InlineSmallCode. > > And you should used debugcore instead of jvmgcore: > +all_debugcore: jvmgcore docs export_debug > > I want your changes be perfect from the start ;) > > You're right. The renaming of the 'jvmg' target to > 'debug' has happened > recently ( > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) > and > we haven't adapted it. We will fix this. > > > And I need to discuss with our embedded group about > 0002_PPC_defines.patch > because it affects them. It may take time. > > Thanks, > Vladimir > > > On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > yes, the plan is that each is self contained. > When I set up the > patches I > built and jckecked each. When I updated them I > only built them > selectively, > so there might be minor issues. I had planned > to assure this once I > make > webrevs from the patches. > > Some of them might apply in any order, but > others depend on previous > ones, > e.g., 0009 containing the ppc files will not > work without the changes > before. > > The patches work with hs25-b34. > > Please tell me if I can do anything to ease > your reviewing. > > Ah, I just saw your mail about closed code ... > I tried to keep > changes necessary to other platform code to a > minimum, but also tried > to avoid strange workarounds. Therefore I for > example did change 0002 > renaming the PPC defines, see the comment there. > > If you agree with the granularity of the > changes, it would be great > if you > could generate bug-ids for them. Maybe at > least for the changes > up to 0016? > > Best regards > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov > [mailto:vladimir.kozlov@ > **oracle.com > > > ] > Sent: Mittwoch, 12. Juni 2013 17:03 > To: Lindenmaier, Goetz > Cc: > ppc-aix-port-dev at openjdk.java.**net >; > hotspot-dev at openjdk.java.net > ; Volker > Simonis; Azeem Jiva; Chris Plummer > Subject: Re: JEP 175 - Review comments > > Thank you, Goetz. > > Can I review just 1 patch (for example, 1 from > first 1-9), merge it > with > jdk8 and build? Or I should do review all 1-9 > patches and merge them together into jdk8 to > be able build? In > short, is > each patch self-contain? > > Thanks, > Vladimir > > On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: > > Hi, > > With my recent changes I removed some of > the problems Vladimir > mentioned. > > I also added the patches queue I maintain > into our jdk8/hotspot > repository, > at hotspot/ppc_patches. > Applied to the staging hotspot directory, > the linuxppc and aixppc > hotspots > can be built. > > The queue contains the changes proposed by > me before, with minor > changes > due > to recent development: > > 1-9 linuxppc C-interpreter port (In > our plan milestone M2.1) > 11-15 aixppc C-interpreter port (In > our plan milestone M2.2) > 101-107 C-interpreter improvements > 111-122 ppc C2 compiler port leading to a > vm rudimentarily working > 200-217 C2 compiler fixes, extensions etc > needed for a stable and > performant ppc port. > Altogether currently 49 changes. > > Our plan was to propose the changes in the > order of the queue for > review. I'm happy to create webrevs for > any of them. > > Vladimir, maybe the queue simplifies > reviewing the port, as the > changes > are more complete. They include all later > improvements by fixes or > adaptions in merge changes. > For why and where I renamed PPC to PPC32 > see the second change in the > queue. > > Best regards, > Goetz. > > > PS: This can be used as the invokedynamic > repository: > hg clone > http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot > ppc-hotspot > hg clone > http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot > > cd stage-hotspot > ln -s .../ppc-hotspot/ppc_patches/ > .hg/patches > hg qpush -a > > > > > > -----Original Message----- > From: Vladimir Kozlov > [mailto:vladimir.kozlov@ > **oracle.com > > > ] > Sent: Dienstag, 11. Juni 2013 18:34 > To: Lindenmaier, Goetz > Cc: Volker Simonis; Azeem Jiva; Chris Plummer > Subject: Re: JEP 175 - Review comments > > Here is result of my first attempt to > build/test ppc changes together > with our closed sources. > > Small problems: > > src/share/vm/memory/**allocation.hpp:209: > Trailing whitespace > src/share/vm/memory/**allocation.inline.hpp:121: > Trailing whitespace > src/share/vm/opto/escape.cpp:**2207: > Trailing whitespace > src/share/vm/memory/**allocation.hpp:212: > Trailing whitespace > src/share/vm/opto/escape.cpp:**2214: > Trailing whitespace > > Build on MacOS: > > src/share/vm/opto/**callGenerator.cpp: In > member function 'virtual > JVMState* > VirtualCallGenerator::**generate(JVMState*)': > src/share/vm/opto/**callGenerator.cpp:204: > error: > 'zero_page_read_protected' is not a member > of 'os' > > agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: > error: #error > UNSUPPORTED_ARCH > agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: > error: #error > UNSUPPORTED_ARCH > agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: > error: #error > UNSUPPORTED_ARCH > > > We have several conflict with closed > sources builds: > > src/share/vm/utilities/**elfSymbolTable.cpp: > In member function 'bool > ElfSymbolTable::lookup(**unsigned char*, > int*, int*, int*)': > src/share/vm/utilities/**elfSymbolTable.cpp:97: > error: comparison > between > signed and unsigned integer expressions > src/share/vm/utilities/**elfSymbolTable.cpp:124: > error: comparison > between > signed and unsigned integer expressions > > error: no 'oopDesc** > frame::interpreter_frame_**mirror_addr() > const' > member function declared in class 'frame' > > error: no matching function for call to > 'SharedRuntime::c_calling_**convention(BasicType*&, > VMRegPair*&, > uint&)' > > I think it is due to changes like next: > > -#ifdef PPC > +#ifdef PPC32 > oop* > interpreter_frame_mirror_addr(**) const; > > > Next is easy fix in our closed sources but > it requires efforts from > our > side: > > src/share/vm/prims/**methodHandles.cpp: In > static member function > 'static > void MethodHandles::generate_**adapters()': > src/share/vm/prims/**methodHandles.cpp:68: > error: 'adapter_code_size' > cannot be used as a function > src/share/vm/prims/**methodHandles.cpp:70: > error: 'adapter_code_size' > cannot be used as a function > > > I would suggest to do such shared changes > which affects different > builds > later after initial push. > > > Thanks, > Vladimir > > On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > I updated the repo to jdk8-b92. Our > nightly tests built and > tested it successfully. In case you > experience any problems > please tell me the details so I can > fix them. > > Best regards, > Goetz. > > http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html > > > > > > -----Original Message----- > From: Vladimir Kozlov > [mailto:vladimir.kozlov@ > **oracle.com > > > ] > Sent: Dienstag, 4. Juni 2013 20:58 > To: Simonis, Volker > Cc: Iris Clark; Wintergerst, Michael; > Lindenmaier, Goetz; Bernard > Traversat; Jeannette Hung; Azeem Jiva; > David Therkelsen; Mikael > Vidstedt; > Neil Richards; Steve Poole; > luchsh at cn.ibm.com > ; Tim > Ellison; Alan > Bateman > Subject: Re: JEP 175 - Review comments > > Volker, > > Can you or someone update > http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto > match latest > sources in > http://hg.openjdk.java.net/**jdk8/jdk8/hotspot > > ? > I just tried to merge them and build > Hotspot on x86 without success. > > Thanks, > Vladimir > > On 6/4/13 7:04 AM, Simonis, Volker wrote: > > We intentionally used > 'porters-dev' rather > than'ppc-aix-port-dev' in > the > beginning to address a broader > audience for the initial discussions. > > But I'm happy to change that back > to 'ppc-aix-port-dev' now. > > Regards, > Volker > > > ------------------------------**------------------------------** > ------------ > *From:* Iris Clark > [iris.clark at oracle.com > ] > *Sent:* Tuesday, June 04, 2013 3:50 PM > *To:* Simonis, Volker; > Wintergerst, Michael; Lindenmaier, > Goetz; > Bernard > Traversat; Jeannette Hung; Azeem > Jiva; David Therkelsen; Mikael > Vidstedt; Neil Richards; Steve > Poole; luchsh at cn.ibm.com > ; Tim > Ellison; > iris.clark at oracle.com > > *Cc:* Alan Bateman; Vladimir Kozlov > *Subject:* RE: JEP 175 - Review > comments > > Hi, Volker. > > Sorry about this, one more thing > about the JEP... > > I think that the "Discussion" list > probably needs to be updated > to be > your Project's mailing list > (ppc-aix-port-dev). Right now it's > listed > as porters-dev. > > Thanks, > > iris > > *From:*Simonis, Volker > [mailto:volker.simonis at sap.com > **] > *Sent:* Tuesday, June 04, 2013 > 12:12 AM > *To:* Iris Clark; Wintergerst, > Michael; Lindenmaier, Goetz; Bernard > Traversat; Jeannette Hung; Azeem > Jiva; David Therkelsen; Mikael > Vidstedt; Neil Richards; Steve > Poole; luchsh at cn.ibm.com > ; Tim > Ellison > *Cc:* Alan Bateman; Vladimir Kozlov > *Subject:* RE: JEP 175 - Review > comments > > Hi Iris, > > you're right, the title is too > clumsy - I just couldn't come up with > something better yesterday in the > evening. > > "PowerPC/AIX Port" sounds good to > me. If nobody complains, I'll take > it. > > Thanks, > Volker > > ------------------------------**------------------------------** > ------------ > > *From:*Iris Clark > [iris.clark at oracle.com > ] > *Sent:* Tuesday, June 04, 2013 2:57 AM > *To:* Simonis, Volker; > Wintergerst, Michael; Lindenmaier, > Goetz; > Bernard > Traversat; Jeannette Hung; Azeem > Jiva; David Therkelsen; Mikael > Vidstedt; Neil Richards; Steve > Poole; luchsh at cn.ibm.com > > >; Tim > Ellison > *Cc:* Alan Bateman; Vladimir > Kozlov; iris.clark at oracle.com > > > > *Subject:* RE: JEP 175 - Review > comments > > Hi, Volker. > > I've just updated the JEP > according to your suggestions. > > I'm not a Reviewer however, I > think that the phrase "OpenJDK master > repositories" in the revised title > is not ideal: > > --- a/jep-175.md > Mon May 27 > 23:22:51 2013 +0400 > > +++ b/jep-175.md > Mon Jun 03 > 18:51:18 2013 +0200 > > @@ -1,5 +1,5 @@ > > JEP: 175 > > -Title: Integrate PowerPC/AIX Port > into JDK 8 > > +Title: Integrate the PowerPC/AIX > Port into the OpenJDK master > repositories > > Author: Volker Simonis > > Organization: SAP AG > > Created: 2013/1/11 > > Thinking out loud, what about just > "PowerPC/AIX Port"? JEPs are all > about adding features to JDK > Release Projects. There are lots of > examples of JEPs [1] which don't > begin with verbs, e.g. "133: > Unicode > 6.2", "148: Small VM", "172: > DocLint", etc. The JEP itself > contains > additional details. > > Perhaps others have suggestions? > > Am I right with my assumption that > the targeted release will > still be > JDK 8 (or 9/8u respectively) but > that the targeted release will > be set > in the "Release" header field of > the JEP by the OpenJDK Lead (as > specified in the JEP specification)? > > Yes. Once that field is > populated, the value will appear > in the JEP > index [1], see the third column. > > Thanks, > > Iris > > [1]: http://openjdk.java.net/jeps/0 > > *From:*Simonis, Volker > [mailto:volker.simonis at sap.com > **] > *Sent:* Monday, June 03, 2013 10:10 AM > *To:* Iris Clark; Wintergerst, > Michael; Lindenmaier, Goetz; Bernard > Traversat; Jeannette Hung; Azeem > Jiva; David Therkelsen; Mikael > Vidstedt; Neil Richards; Steve > Poole; luchsh at cn.ibm.com > > >; Tim > Ellison > *Cc:* Alan Bateman; Vladimir Kozlov > *Subject:* RE: JEP 175 - Review > comments > > Hi, > > I've just updated the JEP > according to your suggestions. Please > find > the new version attached to this > mail (I haven't checked the new > version > in until now to give everybody a > chance to comment on the changes). > > Am I right with my assumption that > the targeted release will > still be > JDK 8 (or 9/8u respectively) but > that the targeted release will > be set > in the "Release" header field of > the JEP by the OpenJDK Lead (as > specified in the JEP specification)? > > In addition to the changes > proposed by you I've added the > contents of > the "Approach" section from Azeems > "PPCAIX plan" to the > "Description" > section of the JEP. I've also > added links to the new "PowerPC/AIX > Port > Integration Plan" [2] of our > "PowerPC/AIX Port OpenJDK Wiki > Space" [3] > to the JEP. > > The "PowerPC/AIX Port Integration > Plan" in the Wiki is intended > to hold > Azeems "PPCAIX plan" document. > > @Iris: could you please somehow > arrange to give Azeem editing > rights to > that page? > > @Azeem: could you please be so > kind to past the contents of the > "PPCAIX > plan" into that page (once you > have the appropriate rights)? I > saw that > the document is created from an > Atlassian Confluence Wiki anyway > and in > my unlimited naivety I imagine > this could be a simple copy-and-paste > operation:) If that doesn't work > so easily, please let me know how I > could help. > > If there are no objections I plan > to checkin the new version of > the JEP > tomorrow after our telephone call. > > Thank you and best regards, > Volker > > [2]: > https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** > 13729959 > > [3]: > https://wiki.openjdk.java.net/**display/PPCAIXPort > > > ------------------------------**------------------------------** > ------------ > > *From:*Iris Clark > [iris.clark at oracle.com > ] > *Sent:* Friday, May 31, 2013 8:48 PM > *To:* Wintergerst, Michael; > Simonis, Volker; Lindenmaier, Goetz; > Bernard > Traversat; Jeannette Hung; Azeem > Jiva; David Therkelsen; Mikael > Vidstedt; Neil Richards; Steve > Poole; luchsh at cn.ibm.com > > >; Tim > Ellison > *Cc:* iris.clark at oracle.com > > >**; > Alan > Bateman; Vladimir Kozlov > *Subject:* JEP 175 - Review comments > > Hi, Volker. > > JEP 175: Integrate PowerPC/AIX > Port into JDK 8 > > http://openjdk.java.net/jeps/**175 > > > We're actively working to get your > JEP to Funded. We had a few > comments: > > -Recommend that "8" be removed > from the JEP title, etc. > > -Recommend that the first > Motivation bullet clearly indicate > that > it is > only covering PPC/AIX. > > -Recommend that the second > Motivation bullet be modified to > make it > clear that it applies to Hotspot only. > > (Instructions for editing the JEP > may be found in the "Mechanics" > section at the bottom of JEP 1 [1].) > > Vladimir Kozlov (VM) and Alan > Bateman (Core Libraries) are lined > up to > be the JEP's reviewers. Once > they're satisfied with your > changes/feedback they'll add > themselves to the JEP's "Reviewed-by" > line. > > Thanks, > > Iris Clark > > [1]: http://openjdk.java.net/jeps/1 > > > > From vladimir.kozlov at oracle.com Thu Jun 13 07:02:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2013 07:02:49 -0700 Subject: RFR (S): [increase HeapBaseMinAddress for G1] 8012265: VM often crashes on solaris with a lot of memory In-Reply-To: <51B96D7E.7090201@oracle.com> References: <51B96D7E.7090201@oracle.com> Message-ID: <51B9D109.3000007@oracle.com> Looks good. Vladimir On 6/12/13 11:58 PM, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~brutisso/8012265/webrev.00/ > > Sending this to the broad hotspot list since it affects compressed oops, which is a VM wide concern. > > Background: > > The G1 GC uses malloc extensively to allocate auxiliary data structures. On Solaris malloc requires a consecutive chunk > of memory for the C-heap. It picks this chunk in the low addresses so when hotspot maps the Java heap in the low > addresses to get compressed oops we limit the available memory for the C-heap on Solaris. > > For compressed oops the Java heap is mapped at HeapBaseMinAddress, which by default is 2GB on all platforms except > Solaris x86 where it is 256MB. If we have a large Solaris x86 we get many GC worker threads and many G1 heap regions. > All of them requiring substantial C-heap allocations. > > The combination of a limited C-heap and a lot of mallocs for G1 may cause us to run out of memory on large Solaris x86 > machines, even with our default settings. > > The long term solution is to change G1 to be more efficient about its memory consumption and preferably use mapped > memory instead of malloced memory. This is a lot of work, but will definitely have to be done. > > A short term solution to reduce the risk of running out of memory is to increase the default value of HeapBaseMinAddress > for G1. That is what my proposed patch does. > > This will reduce the maximum possible heap sizes for compressed oops without a heap base. Shifted compressed oops will > be reduced from almost 32g to 31g and unshifted compressed oops from almost 4g to 3g. Still more than on any other > platform where HeapBaseMinAddress=2g by default. It will only affect G1 and it can be overridden by explicitly setting > HeapBaseMinAddress on the command line. > > I've filed this enhancement in JBS to track the work to change back the default value: > > JDK-8016505: G1: Revert back to use HeapBaseMinAddress=256m on Solaris x86 > > Thanks, > Bengt From zhengyu.gu at oracle.com Thu Jun 13 07:41:02 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 13 Jun 2013 14:41:02 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130613144118.28F57481C7@hg.openjdk.java.net> Changeset: 2d9b536bb027 Author: zgu Date: 2013-06-12 20:35 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2d9b536bb027 8013651: NMT: reserve/release sequence id's in incorrect order due to race Summary: Fixed NMT race condition for realloc, uncommit and release Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 730eb43a23d8 Author: zgu Date: 2013-06-13 04:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/730eb43a23d8 Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp - src/share/vm/memory/klassInfoClosure.hpp ! src/share/vm/runtime/os.cpp Changeset: b43a5b3a4249 Author: zgu Date: 2013-06-13 04:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b43a5b3a4249 Merge From bengt.rutisson at oracle.com Thu Jun 13 07:53:32 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Jun 2013 16:53:32 +0200 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps Message-ID: <51B9DCEC.6050906@oracle.com> Hi everyone, Could I have a couple of review for this small change? http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ Sending this request to the broad hotspot dev mailing list since it touches code in vm/utilities. Background: In the constructor for the ConcurrentMark class in G1 we set up one bit map per worker thread: for (uint i = 0; i < _max_worker_id; ++i) { ... _count_card_bitmaps[i] = BitMap(card_bm_size, false); ... } Each of these bitmaps are malloced, which means that the amount of C-heap we require grows with the number of GC worker threads we have. On a machine with many CPUs we get many worker threads by default. For example, on scaaa007 I get 79 GC worker threads. The size of the bitmaps also scale with the heap size. Since this large machine has a lot of memory we get a large default heap as well. Here is the output from just running java -version with G1 on scaaa007: $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed mode) allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc We malloc 221MB just by starting the VM. Most of the large allocations are due to the BitMap allocations. My patch changes the BitMap allocations to use the ArrayAllocator instead. That class uses mmap on Solaris if the size is larger than 64K. With this patch the output looks like this: $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed mode) allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc We are down to 31MB. Note that the ArrayAllocator only has this effect on Solaris machines. Also note that I have not reduced the total amount of memory, just moved it from the C-heap to mapped memory. One complication with the fix is that the BitMap data structures get copied around quite a bit. The copies are shallow copies, so we don't risk re-doing the allocation. But since I am now embedding an ArrayAllocator in the BitMap structure the destructor for copies of the ArrayAllocator gets called every now and then. The BitMap explicitly frees up the allocated memory when it thinks it is necessary. So, rather than trying to refactor the code to avoid copying I made it optional to free the allocated memory in the ArrayAllocator desctructor. I do think it would be good to review the BitMap code. It seems a bit fishy that we pass around shallow copies. But I think my current change keeps the same behavior as before. Thanks, Bengt From staffan.larsen at oracle.com Thu Jun 13 09:16:32 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 13 Jun 2013 16:16:32 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8005849: JEP 167: Event-Based JVM Tracing Message-ID: <20130613161640.8BE48481CF@hg.openjdk.java.net> Changeset: f2110083203d Author: sla Date: 2013-06-10 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f2110083203d 8005849: JEP 167: Event-Based JVM Tracing Reviewed-by: acorn, coleenp, sla Contributed-by: Karen Kinnear , Bengt Rutisson , Calvin Cheung , Erik Gahlin , Erik Helin , Jesper Wilhelmsson , Keith McGuigan , Mattias Tobiasson , Markus Gronlund , Mikael Auno , Nils Eliasson , Nils Loodin , Rickard Backman , Staffan Larsen , Stefan Karlsson , Yekaterina Kantserova ! make/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/minimal1.make ! make/bsd/makefiles/top.make + make/bsd/makefiles/trace.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/excludeSrc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/minimal1.make ! make/linux/makefiles/top.make + make/linux/makefiles/trace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/top.make + make/solaris/makefiles/trace.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/generated.make ! make/windows/makefiles/projectcreator.make + make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_share_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp + src/share/vm/gc_implementation/g1/evacuationInfo.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp + src/share/vm/gc_implementation/g1/g1YCTypes.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp + src/share/vm/gc_implementation/shared/copyFailedInfo.hpp + src/share/vm/gc_implementation/shared/gcHeapSummary.hpp + src/share/vm/gc_implementation/shared/gcTimer.cpp + src/share/vm/gc_implementation/shared/gcTimer.hpp + src/share/vm/gc_implementation/shared/gcTrace.cpp + src/share/vm/gc_implementation/shared/gcTrace.hpp + src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.hpp + src/share/vm/gc_implementation/shared/gcWhen.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp + src/share/vm/gc_interface/allocTracer.cpp + src/share/vm/gc_interface/allocTracer.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp + src/share/vm/gc_interface/gcName.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp + src/share/vm/memory/klassInfoClosure.hpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp + src/share/vm/memory/referenceProcessorStats.hpp + src/share/vm/memory/referenceType.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp + src/share/vm/opto/phasetype.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGen.java ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/memBaseline.cpp + src/share/vm/trace/noTraceBackend.hpp + src/share/vm/trace/trace.dtd + src/share/vm/trace/trace.xml + src/share/vm/trace/traceBackend.hpp + src/share/vm/trace/traceDataTypes.hpp + src/share/vm/trace/traceEvent.hpp + src/share/vm/trace/traceEventClasses.xsl + src/share/vm/trace/traceEventIds.xsl - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/traceStream.hpp + src/share/vm/trace/traceTime.hpp + src/share/vm/trace/traceTypes.xsl + src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/tracing.hpp + src/share/vm/trace/xinclude.mod + src/share/vm/trace/xsl_util.xsl ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp From staffan.larsen at oracle.com Thu Jun 13 09:15:05 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 13 Jun 2013 16:15:05 +0000 Subject: hg: hsx/hotspot-main/jdk: 8005008: Add Java Flight Recorder Phase II Message-ID: <20130613161552.8F196481CD@hg.openjdk.java.net> Changeset: e7ece2dbdc70 Author: sla Date: 2013-06-10 11:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7ece2dbdc70 8005008: Add Java Flight Recorder Phase II Reviewed-by: erikj Contributed-by: Karen Kinnear , Bengt Rutisson , Calvin Cheung , Erik Gahlin , Erik Helin , Jesper Wilhelmsson , Keith McGuigan , Mattias Tobiasson , Markus Gronlund , Mikael Auno , Nils Eliasson , Nils Loodin , Rickard Backman , Staffan Larsen , Stefan Karlsson , Yekaterina Kantserova ! make/com/oracle/jfr/Makefile ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/mapfiles/libjfr/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! 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 From vladimir.kozlov at oracle.com Thu Jun 13 10:24:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2013 10:24:09 -0700 Subject: JEP 175 - Review comments In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDB890@DEWDFEMB12A.global.corp.sap> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> <51B93259.7060206@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> <51B99E7D.5010605@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB890@DEWDFEMB12A.global.corp.sap> Message-ID: <51BA0039.2050807@oracle.com> Hi, With next changes in make/linux/platform_ppc -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32 g++ still doesn't like it: /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1: error: "PPC" redefined : error: this is the location of the previous definition I have to do next changes in macros.hpp to pass it: #if defined(PPC32) || defined(PPC64) +#ifndef PPC #define PPC +#endif #define PPC_ONLY(code) code #define NOT_PPC(code) #else +#undef PPC #define PPC_ONLY(code) #define NOT_PPC(code) code #endif Please, fix your patch accordingly (it is all open sources). Thanks, Vladimir On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote: > Hi David, > > I understand there are three cases: > 1.) A real 32-bit processor/instruction set > 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. > 3.) A 64-bit processor/instruction set using 32-bit addresses etc. Is 3) theoretical combination or you are doing it? > > My naming is the following: > 1.) PPC32 > 2.) PPC64 & LP64 > 3.) PPC64 & !LP64. > PPC should be valid for all. > > I understood your port is of kind 1., but I really don?t know that. > Thus I changed the existing PPC guards to PPC32 where we don't > need the guarded code. > > This distinction seems to me to fit well in > os_bsd_zero.hpp > os_linux_zero.hpp > sharedRuntime.cpp > sharedRuntime.hpp > vm_version.cpp / FLOAT_ARCH_STR > > You are right for the defines in > frame.hpp/frame.cpp > Here I guard what is probably an implementation detail of your port and > not a restriction of the architecture. But maybe you can clean up this > piece of code, or tell me by what else I should guard this. > > In patch 0008 you see the libarch adaption: > LIBARCH/ppc64 = ppc64 > LIBARCH/ppc = ppc > I'm happy to adapt the naming of your port however you want to. > > Best regards, > Goetz. > > > > > > > > yes, I changed PPC to PPC32 wherever we don't need the > special case in our port. I do not know why you implemented > the special cases, and maybe you need a define that is more > verbose about the reason. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 13. Juni 2013 12:27 > To: Lindenmaier, Goetz > Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Hi Goetz, > > On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> @Chris: -DPPC32 needs to be set in make//platform_ppc32. > > I think BUILD_ARCH would also need to be ppc32 to pick that up - but > then we would need to change LIB_ARCH back to ppc. Is the 64-bit port > using ppc64 as the LIB_ARCH? > >> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, >> and in macros.hpp you find > > Okay I confess, it was a bad idea to generalize that given that out of > the four platforms we support in the Oracle JDK, two are 32-bit only, so > we only have sparc and x86 as examples. On sparc we only use SPARC and > _LP64=1 to indicate things (and obviously in sparc specific files > anything not in _LP64=1 is implicitly 32-bit). > > For x86 .... well x86 is a bit of a historical mess. So yes all those > defines exist but the predominant form in shared code is X86 and AMD64 > (as a synonym for LP64=1). IA32 exists but is barely used and arguably > most of the places it remains are relics from before the 32-bit and > 64-bit x86 code merge took place. So we have some historical baggage there. > > My main concern with the PPC, PPC32, PPC64 proposal is that the patch I > saw: > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch > > seemed to use PPC32 in places I would not expect. I'm starting to feel > that this is not 32 vs 64 per-se, but that PPC32 is being used as a way > to flag "PPC Oracle" in a way that excludes it from use by the PPC64 > port. If that is the case, and I can understand that it may well be > given the existing PPC specific code was indeed put in place to support > Oracle's PPC port, then perhaps we can look at ways of dealing with that > without using what seems to me to be an artificial 32 vs 64-bit distinction? > > Aside: I would greatly prefer if ARM and PPC were never mentioned in the > (existing) openjdk code, but that would require a level of refactoring > in places that no-one unfortunately has the time to do. That said > perhaps there are some places where a cleaner separation is possible. > There are also places where compiler defines could be used to set string > values rather than using the cpu ifdefs ie: > > #ifdef PPC > #define CPU "ppc" > etc > > David > ----- > >> >> #if defined(IA32) || defined(AMD64) >> #define X86 >> #define X86_ONLY(code) code >> #define NOT_X86(code) >> #else >> #undef X86 >> #define X86_ONLY(code) >> #define NOT_X86(code) code >> #endif >> >> It's just not that obvious as the names of these platforms >> are messed up. On PPC I wanted to follow a clean approach. >> >> Best regards, >> Goetz. >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 13. Juni 2013 04:46 >> To: Lindenmaier, Goetz >> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Just adding my 2c from what was an internal discussion but is not in any >> way confidential: >> >> We don't use 3 architecture designators on other platforms to >> distinguish between "common", 32-bit and 64-bit, so why do we need to do >> so for PPC ? >> >> The normal approach would be to add _LP64=1 specific ifdefs within an >> architectural ifdef. >> >> This change (PPC32 usage) seems to be introducing unnecessary changes >> and inconsistency with how 32-bit vs 64-bit is generally handled. >> >> Further, it is far from obvious from the patch that code now flagged as >> PPC32 is indeed 32-bit specific rather than common! >> >> David >> ----- >> >> On 13/06/2013 5:54 AM, Chris Plummer wrote: >>> Hi Goetz, >>> >>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >>> make/linux/platform_ppc. >>> >>> There are a lot of PPC references in c1 that don't appear to have been >>> addressed. >>> >>> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >>> allowing you to use >>> >>> #ifdef PPC >>> >>> rather than >>> >>> #if defined(PPC32) || defined(PPC64) >>> >>> best regards, >>> >>> Chris >>> >>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> With my recent changes I removed some of the problems Vladimir mentioned. >>>> >>>> I also added the patches queue I maintain into our jdk8/hotspot >>>> repository, >>>> at hotspot/ppc_patches. >>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>> hotspots >>>> can be built. >>>> >>>> The queue contains the changes proposed by me before, with minor >>>> changes due >>>> to recent development: >>>> >>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>> 101-107 C-interpreter improvements >>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>> performant ppc port. >>>> Altogether currently 49 changes. >>>> >>>> Our plan was to propose the changes in the order of the queue for >>>> review. I'm happy to create webrevs for any of them. >>>> >>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>>> are more complete. They include all later improvements by fixes or >>>> adaptions in merge changes. >>>> For why and where I renamed PPC to PPC32 see the second change in the >>>> queue. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> PS: This can be used as the invokedynamic repository: >>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>>> ppc-hotspot >>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>>> stage-hotspot >>>> cd stage-hotspot >>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>> hg qpush -a >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>> To: Lindenmaier, Goetz >>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Here is result of my first attempt to build/test ppc changes together >>>> with our closed sources. >>>> >>>> Small problems: >>>> >>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>>> >>>> Build on MacOS: >>>> >>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>>> src/share/vm/opto/callGenerator.cpp:204: error: >>>> 'zero_page_read_protected' is not a member of 'os' >>>> >>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>>> UNSUPPORTED_ARCH >>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>>> UNSUPPORTED_ARCH >>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>>> UNSUPPORTED_ARCH >>>> >>>> >>>> We have several conflict with closed sources builds: >>>> >>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>>> signed and unsigned integer expressions >>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>>> signed and unsigned integer expressions >>>> >>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>>> member function declared in class 'frame' >>>> >>>> error: no matching function for call to >>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>>> >>>> I think it is due to changes like next: >>>> >>>> -#ifdef PPC >>>> +#ifdef PPC32 >>>> oop* interpreter_frame_mirror_addr() const; >>>> >>>> >>>> Next is easy fix in our closed sources but it requires efforts from our >>>> side: >>>> >>>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>>> void MethodHandles::generate_adapters()': >>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>>> cannot be used as a function >>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>>> cannot be used as a function >>>> >>>> >>>> I would suggest to do such shared changes which affects different builds >>>> later after initial push. >>>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>> Hi Vladimir, >>>>> >>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>> tested it successfully. In case you experience any problems >>>>> please tell me the details so I can fix them. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>> To: Simonis, Volker >>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>> Alan Bateman >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Volker, >>>>> >>>>> Can you or someone update >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>> the >>>>>> beginning to address a broader audience for the initial discussions. >>>>>> >>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>> iris.clark at oracle.com >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> Sorry about this, one more thing about the JEP... >>>>>> >>>>>> I think that the "Discussion" list probably needs to be updated to be >>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>>> as porters-dev. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> iris >>>>>> >>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi Iris, >>>>>> >>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>> something better yesterday in the evening. >>>>>> >>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>> it. >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>> >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> I've just updated the JEP according to your suggestions. >>>>>> >>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>> repositories" in the revised title is not ideal: >>>>>> >>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>> >>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>> >>>>>> @@ -1,5 +1,5 @@ >>>>>> >>>>>> JEP: 175 >>>>>> >>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>> >>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>> repositories >>>>>> >>>>>> Author: Volker Simonis >>>>>> >>>>>> Organization: SAP AG >>>>>> >>>>>> Created: 2013/1/11 >>>>>> >>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>> about adding features to JDK Release Projects. There are lots of >>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>> additional details. >>>>>> >>>>>> Perhaps others have suggestions? >>>>>> >>>>>> Am I right with my assumption that the targeted release will still be >>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>> specified in the JEP specification)? >>>>>> >>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>> index [1], see the third column. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Iris >>>>>> >>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>> >>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, >>>>>> >>>>>> I've just updated the JEP according to your suggestions. Please find >>>>>> the new version attached to this mail (I haven't checked the new >>>>>> version >>>>>> in until now to give everybody a chance to comment on the changes). >>>>>> >>>>>> Am I right with my assumption that the targeted release will still be >>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>> specified in the JEP specification)? >>>>>> >>>>>> In addition to the changes proposed by you I've added the contents of >>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>>> to the JEP. >>>>>> >>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>>> Azeems "PPCAIX plan" document. >>>>>> >>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>>> that page? >>>>>> >>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>> could help. >>>>>> >>>>>> If there are no objections I plan to checkin the new version of the JEP >>>>>> tomorrow after our telephone call. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> [2]: >>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>>> Bateman; Vladimir Kozlov >>>>>> *Subject:* JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>> >>>>>> http://openjdk.java.net/jeps/175 >>>>>> >>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>> comments: >>>>>> >>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>> >>>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>>> only covering PPC/AIX. >>>>>> >>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>> clear that it applies to Hotspot only. >>>>>> >>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>> section at the bottom of JEP 1 [1].) >>>>>> >>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>> line. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Iris Clark >>>>>> >>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>> >>> From christian.thalinger at oracle.com Thu Jun 13 10:51:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Jun 2013 10:51:40 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> <51B794E9.2040405@oracle.com> Message-ID: On Jun 11, 2013, at 7:16 PM, Christian Thalinger wrote: > > On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev wrote: > >> On 06/11/2013 10:24 PM, Christian Thalinger wrote: >>> >>> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev wrote: >>> >>>> On 06/11/2013 08:06 PM, Christian Thalinger wrote: >>>>> Anyway, let's push this. >>>> >>>> Do you want me any other testing done? vm.mlvm.testlist is OK, but I >>>> haven't done the full JPRT test cycle, only the build one. >>> >>> You could do a full Nashorn 262 run. That would shake out bugs. >> >> Done. Linux x86_64/release passes test262parallel with either clean or >> patched build. > > Thanks for verifying. I'll push your change tomorrow. While preparing the push I noticed the new code gives a warning: src/share/classes/java/lang/invoke/MethodType.java:1106: warning: [unchecked] unchecked cast T that = ((WeakEntry) obj).get(); ^ required: WeakEntry found: Object where T is a type-variable: T extends Object declared in class WeakEntry 1 warning Could you fix that, please? -- Chris > > -- Chris > >> >> -Aleksey. >> > From aleksey.shipilev at oracle.com Thu Jun 13 12:09:28 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 13 Jun 2013 23:09:28 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> <51B794E9.2040405@oracle.com> Message-ID: <51BA18E8.50806@oracle.com> On 06/13/2013 09:51 PM, Christian Thalinger wrote: > While preparing the push I noticed the new code gives a warning: > > src/share/classes/java/lang/invoke/MethodType.java:1106: warning: [unchecked] unchecked cast > T that = ((WeakEntry) obj).get(); > ^ > required: WeakEntry > found: Object > where T is a type-variable: > T extends Object declared in class WeakEntry > 1 warning > > Could you fix that, please? Can't reproduce that warning in my builds (are you having -Xlint:unchecked enabled in the new build system somehow?), but good catch! There is the preceding instanceof check that ought to make this cast safe now. Also we don't need to declare locals as T in equals(). Please try this: http://cr.openjdk.java.net/~shade/7177472/webrev.03/ This seems a trivial change, so I only tested java/lang/invoke regression tests afterwards, those are OK. -Aleksey. From chris.plummer at oracle.com Thu Jun 13 12:25:14 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 13 Jun 2013 12:25:14 -0700 Subject: JEP 175 - Review comments In-Reply-To: <51BA0039.2050807@oracle.com> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> <51B93259.7060206@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> <51B99E7D.5010605@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB890@DEWDFEMB12A.global.corp.sap> <51BA0039.2050807@oracle.com> Message-ID: <51BA1C9A.8050000@oracle.com> Do you think maybe the #define PPC in macros.hpp should be removed and instead should be done in sysdefs for both platform_ppc and platform_ppc64? Chris On 6/13/13 10:24 AM, Vladimir Kozlov wrote: > Hi, > > With next changes in make/linux/platform_ppc > > -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC > +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32 > > g++ still doesn't like it: > > /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1: > error: "PPC" redefined > : error: this is the location of the previous definition > > I have to do next changes in macros.hpp to pass it: > > #if defined(PPC32) || defined(PPC64) > +#ifndef PPC > #define PPC > +#endif > #define PPC_ONLY(code) code > #define NOT_PPC(code) > #else > +#undef PPC > #define PPC_ONLY(code) > #define NOT_PPC(code) code > #endif > > Please, fix your patch accordingly (it is all open sources). > > Thanks, > Vladimir > > On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I understand there are three cases: >> 1.) A real 32-bit processor/instruction set >> 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. >> 3.) A 64-bit processor/instruction set using 32-bit addresses etc. > > Is 3) theoretical combination or you are doing it? > >> >> My naming is the following: >> 1.) PPC32 >> 2.) PPC64 & LP64 >> 3.) PPC64 & !LP64. >> PPC should be valid for all. >> >> I understood your port is of kind 1., but I really don?t know that. >> Thus I changed the existing PPC guards to PPC32 where we don't >> need the guarded code. >> >> This distinction seems to me to fit well in >> os_bsd_zero.hpp >> os_linux_zero.hpp >> sharedRuntime.cpp >> sharedRuntime.hpp >> vm_version.cpp / FLOAT_ARCH_STR >> >> You are right for the defines in >> frame.hpp/frame.cpp >> Here I guard what is probably an implementation detail of your port and >> not a restriction of the architecture. But maybe you can clean up this >> piece of code, or tell me by what else I should guard this. >> >> In patch 0008 you see the libarch adaption: >> LIBARCH/ppc64 = ppc64 >> LIBARCH/ppc = ppc >> I'm happy to adapt the naming of your port however you want to. >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> yes, I changed PPC to PPC32 wherever we don't need the >> special case in our port. I do not know why you implemented >> the special cases, and maybe you need a define that is more >> verbose about the reason. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 13. Juni 2013 12:27 >> To: Lindenmaier, Goetz >> Cc: Chris Plummer; Vladimir Kozlov; >> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Hi Goetz, >> >> On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> @Chris: -DPPC32 needs to be set in make//platform_ppc32. >> >> I think BUILD_ARCH would also need to be ppc32 to pick that up - but >> then we would need to change LIB_ARCH back to ppc. Is the 64-bit port >> using ppc64 as the LIB_ARCH? >> >>> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 >>> sets -DAMD64, >>> and in macros.hpp you find >> >> Okay I confess, it was a bad idea to generalize that given that out of >> the four platforms we support in the Oracle JDK, two are 32-bit only, so >> we only have sparc and x86 as examples. On sparc we only use SPARC and >> _LP64=1 to indicate things (and obviously in sparc specific files >> anything not in _LP64=1 is implicitly 32-bit). >> >> For x86 .... well x86 is a bit of a historical mess. So yes all those >> defines exist but the predominant form in shared code is X86 and AMD64 >> (as a synonym for LP64=1). IA32 exists but is barely used and arguably >> most of the places it remains are relics from before the 32-bit and >> 64-bit x86 code merge took place. So we have some historical baggage >> there. >> >> My main concern with the PPC, PPC32, PPC64 proposal is that the patch I >> saw: >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch >> >> >> seemed to use PPC32 in places I would not expect. I'm starting to feel >> that this is not 32 vs 64 per-se, but that PPC32 is being used as a way >> to flag "PPC Oracle" in a way that excludes it from use by the PPC64 >> port. If that is the case, and I can understand that it may well be >> given the existing PPC specific code was indeed put in place to support >> Oracle's PPC port, then perhaps we can look at ways of dealing with that >> without using what seems to me to be an artificial 32 vs 64-bit >> distinction? >> >> Aside: I would greatly prefer if ARM and PPC were never mentioned in the >> (existing) openjdk code, but that would require a level of refactoring >> in places that no-one unfortunately has the time to do. That said >> perhaps there are some places where a cleaner separation is possible. >> There are also places where compiler defines could be used to set string >> values rather than using the cpu ifdefs ie: >> >> #ifdef PPC >> #define CPU "ppc" >> etc >> >> David >> ----- >> >>> >>> #if defined(IA32) || defined(AMD64) >>> #define X86 >>> #define X86_ONLY(code) code >>> #define NOT_X86(code) >>> #else >>> #undef X86 >>> #define X86_ONLY(code) >>> #define NOT_X86(code) code >>> #endif >>> >>> It's just not that obvious as the names of these platforms >>> are messed up. On PPC I wanted to follow a clean approach. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 13. Juni 2013 04:46 >>> To: Lindenmaier, Goetz >>> Cc: Chris Plummer; Vladimir Kozlov; >>> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: JEP 175 - Review comments >>> >>> Just adding my 2c from what was an internal discussion but is not in >>> any >>> way confidential: >>> >>> We don't use 3 architecture designators on other platforms to >>> distinguish between "common", 32-bit and 64-bit, so why do we need >>> to do >>> so for PPC ? >>> >>> The normal approach would be to add _LP64=1 specific ifdefs within an >>> architectural ifdef. >>> >>> This change (PPC32 usage) seems to be introducing unnecessary changes >>> and inconsistency with how 32-bit vs 64-bit is generally handled. >>> >>> Further, it is far from obvious from the patch that code now flagged as >>> PPC32 is indeed 32-bit specific rather than common! >>> >>> David >>> ----- >>> >>> On 13/06/2013 5:54 AM, Chris Plummer wrote: >>>> Hi Goetz, >>>> >>>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't >>>> see >>>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >>>> make/linux/platform_ppc. >>>> >>>> There are a lot of PPC references in c1 that don't appear to have been >>>> addressed. >>>> >>>> Is there a reason that PPC is not also defined for both PPC32 and >>>> PPC64, >>>> allowing you to use >>>> >>>> #ifdef PPC >>>> >>>> rather than >>>> >>>> #if defined(PPC32) || defined(PPC64) >>>> >>>> best regards, >>>> >>>> Chris >>>> >>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> With my recent changes I removed some of the problems Vladimir >>>>> mentioned. >>>>> >>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>> repository, >>>>> at hotspot/ppc_patches. >>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>> hotspots >>>>> can be built. >>>>> >>>>> The queue contains the changes proposed by me before, with minor >>>>> changes due >>>>> to recent development: >>>>> >>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>> 101-107 C-interpreter improvements >>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>> performant ppc port. >>>>> Altogether currently 49 changes. >>>>> >>>>> Our plan was to propose the changes in the order of the queue for >>>>> review. I'm happy to create webrevs for any of them. >>>>> >>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>> changes >>>>> are more complete. They include all later improvements by fixes or >>>>> adaptions in merge changes. >>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>> queue. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> PS: This can be used as the invokedynamic repository: >>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>>>> ppc-hotspot >>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>>>> stage-hotspot >>>>> cd stage-hotspot >>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>> hg qpush -a >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Here is result of my first attempt to build/test ppc changes together >>>>> with our closed sources. >>>>> >>>>> Small problems: >>>>> >>>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>>>> >>>>> Build on MacOS: >>>>> >>>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>>>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>>>> src/share/vm/opto/callGenerator.cpp:204: error: >>>>> 'zero_page_read_protected' is not a member of 'os' >>>>> >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> >>>>> >>>>> We have several conflict with closed sources builds: >>>>> >>>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison >>>>> between >>>>> signed and unsigned integer expressions >>>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison >>>>> between >>>>> signed and unsigned integer expressions >>>>> >>>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>>>> member function declared in class 'frame' >>>>> >>>>> error: no matching function for call to >>>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, >>>>> uint&)' >>>>> >>>>> I think it is due to changes like next: >>>>> >>>>> -#ifdef PPC >>>>> +#ifdef PPC32 >>>>> oop* interpreter_frame_mirror_addr() const; >>>>> >>>>> >>>>> Next is easy fix in our closed sources but it requires efforts >>>>> from our >>>>> side: >>>>> >>>>> src/share/vm/prims/methodHandles.cpp: In static member function >>>>> 'static >>>>> void MethodHandles::generate_adapters()': >>>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> >>>>> >>>>> I would suggest to do such shared changes which affects different >>>>> builds >>>>> later after initial push. >>>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>> tested it successfully. In case you experience any problems >>>>>> please tell me the details so I can fix them. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>> To: Simonis, Volker >>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>> Ellison; >>>>>> Alan Bateman >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Volker, >>>>>> >>>>>> Can you or someone update >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>> We intentionally used 'porters-dev' rather >>>>>>> than'ppc-aix-port-dev' in >>>>>>> the >>>>>>> beginning to address a broader audience for the initial >>>>>>> discussions. >>>>>>> >>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>> Ellison; >>>>>>> iris.clark at oracle.com >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> Sorry about this, one more thing about the JEP... >>>>>>> >>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>> to be >>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>> listed >>>>>>> as porters-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> iris >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>> Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi Iris, >>>>>>> >>>>>>> you're right, the title is too clumsy - I just couldn't come up >>>>>>> with >>>>>>> something better yesterday in the evening. >>>>>>> >>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll >>>>>>> take >>>>>>> it. >>>>>>> >>>>>>> Thanks, >>>>>>> Volker >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>> >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. >>>>>>> >>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>> repositories" in the revised title is not ideal: >>>>>>> >>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>> >>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>> >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> >>>>>>> JEP: 175 >>>>>>> >>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>> repositories >>>>>>> >>>>>>> Author: Volker Simonis >>>>>>> >>>>>>> Organization: SAP AG >>>>>>> >>>>>>> Created: 2013/1/11 >>>>>>> >>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are >>>>>>> all >>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>> Unicode >>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself >>>>>>> contains >>>>>>> additional details. >>>>>>> >>>>>>> Perhaps others have suggestions? >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will >>>>>>> still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>> be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> Yes. Once that field is populated, the value will appear in the >>>>>>> JEP >>>>>>> index [1], see the third column. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>> find >>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>> version >>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will >>>>>>> still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>> be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> In addition to the changes proposed by you I've added the >>>>>>> contents of >>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>> "Description" >>>>>>> section of the JEP. I've also added links to the new >>>>>>> "PowerPC/AIX Port >>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>> Space" [3] >>>>>>> to the JEP. >>>>>>> >>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>> to hold >>>>>>> Azeems "PPCAIX plan" document. >>>>>>> >>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>> rights to >>>>>>> that page? >>>>>>> >>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>> "PPCAIX >>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>> saw that >>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>> and in >>>>>>> my unlimited naivety I imagine this could be a simple >>>>>>> copy-and-paste >>>>>>> operation:) If that doesn't work so easily, please let me know >>>>>>> how I >>>>>>> could help. >>>>>>> >>>>>>> If there are no objections I plan to checkin the new version of >>>>>>> the JEP >>>>>>> tomorrow after our telephone call. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> [2]: >>>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>>>> Bateman; Vladimir Kozlov >>>>>>> *Subject:* JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> http://openjdk.java.net/jeps/175 >>>>>>> >>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>> comments: >>>>>>> >>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>> >>>>>>> -Recommend that the first Motivation bullet clearly indicate >>>>>>> that it is >>>>>>> only covering PPC/AIX. >>>>>>> >>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>> clear that it applies to Hotspot only. >>>>>>> >>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>> section at the bottom of JEP 1 [1].) >>>>>>> >>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>> up to >>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>> line. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris Clark >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>> >>>> From christian.thalinger at oracle.com Thu Jun 13 12:30:19 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Jun 2013 12:30:19 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51BA18E8.50806@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> <51B794E9.2040405@oracle.com> <51BA18E8.50806@oracle.com> Message-ID: <7F418E0A-03EF-49C8-A3C7-63331C0CDC1B@oracle.com> On Jun 13, 2013, at 12:09 PM, Aleksey Shipilev wrote: > On 06/13/2013 09:51 PM, Christian Thalinger wrote: >> While preparing the push I noticed the new code gives a warning: >> >> src/share/classes/java/lang/invoke/MethodType.java:1106: warning: [unchecked] unchecked cast >> T that = ((WeakEntry) obj).get(); >> ^ >> required: WeakEntry >> found: Object >> where T is a type-variable: >> T extends Object declared in class WeakEntry >> 1 warning >> >> Could you fix that, please? > > Can't reproduce that warning in my builds (are you having > -Xlint:unchecked enabled in the new build system somehow?) More or less. I'm only building java/lang/invoke plus friends and use -Xlint:unchecked. > , but good > catch! There is the preceding instanceof check that ought to make this > cast safe now. Also we don't need to declare locals as T in equals(). > > Please try this: > http://cr.openjdk.java.net/~shade/7177472/webrev.03/ > > This seems a trivial change, so I only tested java/lang/invoke > regression tests afterwards, those are OK. Looks good now. Thanks for the quick turnaround. -- Chris > > -Aleksey. From serguei.spitsyn at oracle.com Thu Jun 13 12:44:36 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 13 Jun 2013 12:44:36 -0700 Subject: Review Request (S) 6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description Message-ID: <51BA2124.6060809@oracle.com> Please, review a 1-line JVMTI doc fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=6493116 jbs: https://jbs.oracle.com/bugs/browse/JDK-6493116 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/6493116-JVMTI-DOC.1 Summary: A typo in the parameter spelling, a bound update missed when the parameter was renamed Testing: Manual build of the JVMTI docs Thanks, Serguei From bengt.rutisson at oracle.com Thu Jun 13 13:03:54 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Jun 2013 22:03:54 +0200 Subject: RFR (S): [increase HeapBaseMinAddress for G1] 8012265: VM often crashes on solaris with a lot of memory In-Reply-To: <51B9D109.3000007@oracle.com> References: <51B96D7E.7090201@oracle.com> <51B9D109.3000007@oracle.com> Message-ID: <51BA25AA.7090907@oracle.com> Thanks Mikael, Coleen and Vladimir for the reviews! Bengt On 6/13/13 4:02 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 6/12/13 11:58 PM, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of reviews for this change? >> >> http://cr.openjdk.java.net/~brutisso/8012265/webrev.00/ >> >> Sending this to the broad hotspot list since it affects compressed >> oops, which is a VM wide concern. >> >> Background: >> >> The G1 GC uses malloc extensively to allocate auxiliary data >> structures. On Solaris malloc requires a consecutive chunk >> of memory for the C-heap. It picks this chunk in the low addresses so >> when hotspot maps the Java heap in the low >> addresses to get compressed oops we limit the available memory for >> the C-heap on Solaris. >> >> For compressed oops the Java heap is mapped at HeapBaseMinAddress, >> which by default is 2GB on all platforms except >> Solaris x86 where it is 256MB. If we have a large Solaris x86 we get >> many GC worker threads and many G1 heap regions. >> All of them requiring substantial C-heap allocations. >> >> The combination of a limited C-heap and a lot of mallocs for G1 may >> cause us to run out of memory on large Solaris x86 >> machines, even with our default settings. >> >> The long term solution is to change G1 to be more efficient about its >> memory consumption and preferably use mapped >> memory instead of malloced memory. This is a lot of work, but will >> definitely have to be done. >> >> A short term solution to reduce the risk of running out of memory is >> to increase the default value of HeapBaseMinAddress >> for G1. That is what my proposed patch does. >> >> This will reduce the maximum possible heap sizes for compressed oops >> without a heap base. Shifted compressed oops will >> be reduced from almost 32g to 31g and unshifted compressed oops from >> almost 4g to 3g. Still more than on any other >> platform where HeapBaseMinAddress=2g by default. It will only affect >> G1 and it can be overridden by explicitly setting >> HeapBaseMinAddress on the command line. >> >> I've filed this enhancement in JBS to track the work to change back >> the default value: >> >> JDK-8016505: G1: Revert back to use HeapBaseMinAddress=256m on >> Solaris x86 >> >> Thanks, >> Bengt From goetz.lindenmaier at sap.com Thu Jun 13 13:25:31 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Jun 2013 20:25:31 +0000 Subject: JEP 175 - Review comments In-Reply-To: <51BA0039.2050807@oracle.com> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> <51B93259.7060206@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> <51B99E7D.5010605@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB890@DEWDFEMB12A.global.corp.sap> <51BA0039.2050807@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFDF741@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I made a webrev with the changes you proposed: http://cr.openjdk.java.net/~goetz/webrevs/PPC_defines/ Unfortunately I didn't get the JBS mail with the bugid yet. If I have that, I'll update the webrev change message. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, June 13, 2013 7:24 PM To: Lindenmaier, Goetz Cc: David Holmes; Chris Plummer; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: JEP 175 - Review comments Hi, With next changes in make/linux/platform_ppc -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32 g++ still doesn't like it: /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1: error: "PPC" redefined : error: this is the location of the previous definition I have to do next changes in macros.hpp to pass it: #if defined(PPC32) || defined(PPC64) +#ifndef PPC #define PPC +#endif #define PPC_ONLY(code) code #define NOT_PPC(code) #else +#undef PPC #define PPC_ONLY(code) #define NOT_PPC(code) code #endif Please, fix your patch accordingly (it is all open sources). Thanks, Vladimir On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote: > Hi David, > > I understand there are three cases: > 1.) A real 32-bit processor/instruction set > 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. > 3.) A 64-bit processor/instruction set using 32-bit addresses etc. Is 3) theoretical combination or you are doing it? > > My naming is the following: > 1.) PPC32 > 2.) PPC64 & LP64 > 3.) PPC64 & !LP64. > PPC should be valid for all. > > I understood your port is of kind 1., but I really don?t know that. > Thus I changed the existing PPC guards to PPC32 where we don't > need the guarded code. > > This distinction seems to me to fit well in > os_bsd_zero.hpp > os_linux_zero.hpp > sharedRuntime.cpp > sharedRuntime.hpp > vm_version.cpp / FLOAT_ARCH_STR > > You are right for the defines in > frame.hpp/frame.cpp > Here I guard what is probably an implementation detail of your port and > not a restriction of the architecture. But maybe you can clean up this > piece of code, or tell me by what else I should guard this. > > In patch 0008 you see the libarch adaption: > LIBARCH/ppc64 = ppc64 > LIBARCH/ppc = ppc > I'm happy to adapt the naming of your port however you want to. > > Best regards, > Goetz. > > > > > > > > yes, I changed PPC to PPC32 wherever we don't need the > special case in our port. I do not know why you implemented > the special cases, and maybe you need a define that is more > verbose about the reason. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 13. Juni 2013 12:27 > To: Lindenmaier, Goetz > Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Hi Goetz, > > On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> @Chris: -DPPC32 needs to be set in make//platform_ppc32. > > I think BUILD_ARCH would also need to be ppc32 to pick that up - but > then we would need to change LIB_ARCH back to ppc. Is the 64-bit port > using ppc64 as the LIB_ARCH? > >> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, >> and in macros.hpp you find > > Okay I confess, it was a bad idea to generalize that given that out of > the four platforms we support in the Oracle JDK, two are 32-bit only, so > we only have sparc and x86 as examples. On sparc we only use SPARC and > _LP64=1 to indicate things (and obviously in sparc specific files > anything not in _LP64=1 is implicitly 32-bit). > > For x86 .... well x86 is a bit of a historical mess. So yes all those > defines exist but the predominant form in shared code is X86 and AMD64 > (as a synonym for LP64=1). IA32 exists but is barely used and arguably > most of the places it remains are relics from before the 32-bit and > 64-bit x86 code merge took place. So we have some historical baggage there. > > My main concern with the PPC, PPC32, PPC64 proposal is that the patch I > saw: > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch > > seemed to use PPC32 in places I would not expect. I'm starting to feel > that this is not 32 vs 64 per-se, but that PPC32 is being used as a way > to flag "PPC Oracle" in a way that excludes it from use by the PPC64 > port. If that is the case, and I can understand that it may well be > given the existing PPC specific code was indeed put in place to support > Oracle's PPC port, then perhaps we can look at ways of dealing with that > without using what seems to me to be an artificial 32 vs 64-bit distinction? > > Aside: I would greatly prefer if ARM and PPC were never mentioned in the > (existing) openjdk code, but that would require a level of refactoring > in places that no-one unfortunately has the time to do. That said > perhaps there are some places where a cleaner separation is possible. > There are also places where compiler defines could be used to set string > values rather than using the cpu ifdefs ie: > > #ifdef PPC > #define CPU "ppc" > etc > > David > ----- > >> >> #if defined(IA32) || defined(AMD64) >> #define X86 >> #define X86_ONLY(code) code >> #define NOT_X86(code) >> #else >> #undef X86 >> #define X86_ONLY(code) >> #define NOT_X86(code) code >> #endif >> >> It's just not that obvious as the names of these platforms >> are messed up. On PPC I wanted to follow a clean approach. >> >> Best regards, >> Goetz. >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 13. Juni 2013 04:46 >> To: Lindenmaier, Goetz >> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Just adding my 2c from what was an internal discussion but is not in any >> way confidential: >> >> We don't use 3 architecture designators on other platforms to >> distinguish between "common", 32-bit and 64-bit, so why do we need to do >> so for PPC ? >> >> The normal approach would be to add _LP64=1 specific ifdefs within an >> architectural ifdef. >> >> This change (PPC32 usage) seems to be introducing unnecessary changes >> and inconsistency with how 32-bit vs 64-bit is generally handled. >> >> Further, it is far from obvious from the patch that code now flagged as >> PPC32 is indeed 32-bit specific rather than common! >> >> David >> ----- >> >> On 13/06/2013 5:54 AM, Chris Plummer wrote: >>> Hi Goetz, >>> >>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >>> make/linux/platform_ppc. >>> >>> There are a lot of PPC references in c1 that don't appear to have been >>> addressed. >>> >>> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >>> allowing you to use >>> >>> #ifdef PPC >>> >>> rather than >>> >>> #if defined(PPC32) || defined(PPC64) >>> >>> best regards, >>> >>> Chris >>> >>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> With my recent changes I removed some of the problems Vladimir mentioned. >>>> >>>> I also added the patches queue I maintain into our jdk8/hotspot >>>> repository, >>>> at hotspot/ppc_patches. >>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>> hotspots >>>> can be built. >>>> >>>> The queue contains the changes proposed by me before, with minor >>>> changes due >>>> to recent development: >>>> >>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>> 101-107 C-interpreter improvements >>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>> performant ppc port. >>>> Altogether currently 49 changes. >>>> >>>> Our plan was to propose the changes in the order of the queue for >>>> review. I'm happy to create webrevs for any of them. >>>> >>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>>> are more complete. They include all later improvements by fixes or >>>> adaptions in merge changes. >>>> For why and where I renamed PPC to PPC32 see the second change in the >>>> queue. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> PS: This can be used as the invokedynamic repository: >>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>>> ppc-hotspot >>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>>> stage-hotspot >>>> cd stage-hotspot >>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>> hg qpush -a >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>> To: Lindenmaier, Goetz >>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Here is result of my first attempt to build/test ppc changes together >>>> with our closed sources. >>>> >>>> Small problems: >>>> >>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>>> >>>> Build on MacOS: >>>> >>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>>> src/share/vm/opto/callGenerator.cpp:204: error: >>>> 'zero_page_read_protected' is not a member of 'os' >>>> >>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>>> UNSUPPORTED_ARCH >>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>>> UNSUPPORTED_ARCH >>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>>> UNSUPPORTED_ARCH >>>> >>>> >>>> We have several conflict with closed sources builds: >>>> >>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>>> signed and unsigned integer expressions >>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>>> signed and unsigned integer expressions >>>> >>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>>> member function declared in class 'frame' >>>> >>>> error: no matching function for call to >>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>>> >>>> I think it is due to changes like next: >>>> >>>> -#ifdef PPC >>>> +#ifdef PPC32 >>>> oop* interpreter_frame_mirror_addr() const; >>>> >>>> >>>> Next is easy fix in our closed sources but it requires efforts from our >>>> side: >>>> >>>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>>> void MethodHandles::generate_adapters()': >>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>>> cannot be used as a function >>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>>> cannot be used as a function >>>> >>>> >>>> I would suggest to do such shared changes which affects different builds >>>> later after initial push. >>>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>> Hi Vladimir, >>>>> >>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>> tested it successfully. In case you experience any problems >>>>> please tell me the details so I can fix them. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>> To: Simonis, Volker >>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>> Alan Bateman >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Volker, >>>>> >>>>> Can you or someone update >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>> the >>>>>> beginning to address a broader audience for the initial discussions. >>>>>> >>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>> iris.clark at oracle.com >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> Sorry about this, one more thing about the JEP... >>>>>> >>>>>> I think that the "Discussion" list probably needs to be updated to be >>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>>> as porters-dev. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> iris >>>>>> >>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi Iris, >>>>>> >>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>> something better yesterday in the evening. >>>>>> >>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>> it. >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>> >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> I've just updated the JEP according to your suggestions. >>>>>> >>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>> repositories" in the revised title is not ideal: >>>>>> >>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>> >>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>> >>>>>> @@ -1,5 +1,5 @@ >>>>>> >>>>>> JEP: 175 >>>>>> >>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>> >>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>> repositories >>>>>> >>>>>> Author: Volker Simonis >>>>>> >>>>>> Organization: SAP AG >>>>>> >>>>>> Created: 2013/1/11 >>>>>> >>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>> about adding features to JDK Release Projects. There are lots of >>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>> additional details. >>>>>> >>>>>> Perhaps others have suggestions? >>>>>> >>>>>> Am I right with my assumption that the targeted release will still be >>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>> specified in the JEP specification)? >>>>>> >>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>> index [1], see the third column. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Iris >>>>>> >>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>> >>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>> >>>>>> Hi, >>>>>> >>>>>> I've just updated the JEP according to your suggestions. Please find >>>>>> the new version attached to this mail (I haven't checked the new >>>>>> version >>>>>> in until now to give everybody a chance to comment on the changes). >>>>>> >>>>>> Am I right with my assumption that the targeted release will still be >>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>> specified in the JEP specification)? >>>>>> >>>>>> In addition to the changes proposed by you I've added the contents of >>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>>> to the JEP. >>>>>> >>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>>> Azeems "PPCAIX plan" document. >>>>>> >>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>>> that page? >>>>>> >>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>> could help. >>>>>> >>>>>> If there are no objections I plan to checkin the new version of the JEP >>>>>> tomorrow after our telephone call. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> [2]: >>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>> Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>> ; Tim Ellison >>>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>>> Bateman; Vladimir Kozlov >>>>>> *Subject:* JEP 175 - Review comments >>>>>> >>>>>> Hi, Volker. >>>>>> >>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>> >>>>>> http://openjdk.java.net/jeps/175 >>>>>> >>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>> comments: >>>>>> >>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>> >>>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>>> only covering PPC/AIX. >>>>>> >>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>> clear that it applies to Hotspot only. >>>>>> >>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>> section at the bottom of JEP 1 [1].) >>>>>> >>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>> line. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Iris Clark >>>>>> >>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>> >>> From vladimir.kozlov at oracle.com Thu Jun 13 14:11:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2013 14:11:19 -0700 Subject: JEP 175 - Review comments In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDF741@DEWDFEMB12A.global.corp.sap> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> , <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> <51B8D212.1050204@oracle.com> <51B93259.7060206@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB79E@DEWDFEMB12A.global.corp.sap> <51B99E7D.5010605@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDB890@DEWDFEMB12A.global.corp.sap> <51BA0039.2050807@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDF741@DEWDFEMB12A.global.corp.sap> Message-ID: <51BA3577.60201@oracle.com> On 6/13/13 1:25 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I made a webrev with the changes you proposed: > http://cr.openjdk.java.net/~goetz/webrevs/PPC_defines/ I am not sure about what is the best solution for #define PPC, with #ifdef check in macros.hpp or, as Chris suggested, remove it from macros.hpp and add -DPPC in platform_ppc and platform_ppc64. And we need to wait what David can suggest for frame.cpp (may be comment should be enough). > Unfortunately I didn't get the JBS mail with the bugid yet. > If I have that, I'll update the webrev change message. Sorry. It means I have to send Bug ID each time I created one :( For this one it is: 8016491: PPC64 (part 2): Clean up PPC defines. Please, resend request for review in separate mail as you did for first 8016476. I also filed next bug: 8016586: PPC64 (part 3): basic changes for PPC64 Thanks, Vladimir > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, June 13, 2013 7:24 PM > To: Lindenmaier, Goetz > Cc: David Holmes; Chris Plummer; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Hi, > > With next changes in make/linux/platform_ppc > > -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC > +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32 > > g++ still doesn't like it: > > /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1: > error: "PPC" redefined > : error: this is the location of the previous definition > > I have to do next changes in macros.hpp to pass it: > > #if defined(PPC32) || defined(PPC64) > +#ifndef PPC > #define PPC > +#endif > #define PPC_ONLY(code) code > #define NOT_PPC(code) > #else > +#undef PPC > #define PPC_ONLY(code) > #define NOT_PPC(code) code > #endif > > Please, fix your patch accordingly (it is all open sources). > > Thanks, > Vladimir > > On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I understand there are three cases: >> 1.) A real 32-bit processor/instruction set >> 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. >> 3.) A 64-bit processor/instruction set using 32-bit addresses etc. > > Is 3) theoretical combination or you are doing it? > >> >> My naming is the following: >> 1.) PPC32 >> 2.) PPC64 & LP64 >> 3.) PPC64 & !LP64. >> PPC should be valid for all. >> >> I understood your port is of kind 1., but I really don?t know that. >> Thus I changed the existing PPC guards to PPC32 where we don't >> need the guarded code. >> >> This distinction seems to me to fit well in >> os_bsd_zero.hpp >> os_linux_zero.hpp >> sharedRuntime.cpp >> sharedRuntime.hpp >> vm_version.cpp / FLOAT_ARCH_STR >> >> You are right for the defines in >> frame.hpp/frame.cpp >> Here I guard what is probably an implementation detail of your port and >> not a restriction of the architecture. But maybe you can clean up this >> piece of code, or tell me by what else I should guard this. >> >> In patch 0008 you see the libarch adaption: >> LIBARCH/ppc64 = ppc64 >> LIBARCH/ppc = ppc >> I'm happy to adapt the naming of your port however you want to. >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> yes, I changed PPC to PPC32 wherever we don't need the >> special case in our port. I do not know why you implemented >> the special cases, and maybe you need a define that is more >> verbose about the reason. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 13. Juni 2013 12:27 >> To: Lindenmaier, Goetz >> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Hi Goetz, >> >> On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> @Chris: -DPPC32 needs to be set in make//platform_ppc32. >> >> I think BUILD_ARCH would also need to be ppc32 to pick that up - but >> then we would need to change LIB_ARCH back to ppc. Is the 64-bit port >> using ppc64 as the LIB_ARCH? >> >>> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, >>> and in macros.hpp you find >> >> Okay I confess, it was a bad idea to generalize that given that out of >> the four platforms we support in the Oracle JDK, two are 32-bit only, so >> we only have sparc and x86 as examples. On sparc we only use SPARC and >> _LP64=1 to indicate things (and obviously in sparc specific files >> anything not in _LP64=1 is implicitly 32-bit). >> >> For x86 .... well x86 is a bit of a historical mess. So yes all those >> defines exist but the predominant form in shared code is X86 and AMD64 >> (as a synonym for LP64=1). IA32 exists but is barely used and arguably >> most of the places it remains are relics from before the 32-bit and >> 64-bit x86 code merge took place. So we have some historical baggage there. >> >> My main concern with the PPC, PPC32, PPC64 proposal is that the patch I >> saw: >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch >> >> seemed to use PPC32 in places I would not expect. I'm starting to feel >> that this is not 32 vs 64 per-se, but that PPC32 is being used as a way >> to flag "PPC Oracle" in a way that excludes it from use by the PPC64 >> port. If that is the case, and I can understand that it may well be >> given the existing PPC specific code was indeed put in place to support >> Oracle's PPC port, then perhaps we can look at ways of dealing with that >> without using what seems to me to be an artificial 32 vs 64-bit distinction? >> >> Aside: I would greatly prefer if ARM and PPC were never mentioned in the >> (existing) openjdk code, but that would require a level of refactoring >> in places that no-one unfortunately has the time to do. That said >> perhaps there are some places where a cleaner separation is possible. >> There are also places where compiler defines could be used to set string >> values rather than using the cpu ifdefs ie: >> >> #ifdef PPC >> #define CPU "ppc" >> etc >> >> David >> ----- >> >>> >>> #if defined(IA32) || defined(AMD64) >>> #define X86 >>> #define X86_ONLY(code) code >>> #define NOT_X86(code) >>> #else >>> #undef X86 >>> #define X86_ONLY(code) >>> #define NOT_X86(code) code >>> #endif >>> >>> It's just not that obvious as the names of these platforms >>> are messed up. On PPC I wanted to follow a clean approach. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 13. Juni 2013 04:46 >>> To: Lindenmaier, Goetz >>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: JEP 175 - Review comments >>> >>> Just adding my 2c from what was an internal discussion but is not in any >>> way confidential: >>> >>> We don't use 3 architecture designators on other platforms to >>> distinguish between "common", 32-bit and 64-bit, so why do we need to do >>> so for PPC ? >>> >>> The normal approach would be to add _LP64=1 specific ifdefs within an >>> architectural ifdef. >>> >>> This change (PPC32 usage) seems to be introducing unnecessary changes >>> and inconsistency with how 32-bit vs 64-bit is generally handled. >>> >>> Further, it is far from obvious from the patch that code now flagged as >>> PPC32 is indeed 32-bit specific rather than common! >>> >>> David >>> ----- >>> >>> On 13/06/2013 5:54 AM, Chris Plummer wrote: >>>> Hi Goetz, >>>> >>>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >>>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >>>> make/linux/platform_ppc. >>>> >>>> There are a lot of PPC references in c1 that don't appear to have been >>>> addressed. >>>> >>>> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >>>> allowing you to use >>>> >>>> #ifdef PPC >>>> >>>> rather than >>>> >>>> #if defined(PPC32) || defined(PPC64) >>>> >>>> best regards, >>>> >>>> Chris >>>> >>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> With my recent changes I removed some of the problems Vladimir mentioned. >>>>> >>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>> repository, >>>>> at hotspot/ppc_patches. >>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>> hotspots >>>>> can be built. >>>>> >>>>> The queue contains the changes proposed by me before, with minor >>>>> changes due >>>>> to recent development: >>>>> >>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>> 101-107 C-interpreter improvements >>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>> performant ppc port. >>>>> Altogether currently 49 changes. >>>>> >>>>> Our plan was to propose the changes in the order of the queue for >>>>> review. I'm happy to create webrevs for any of them. >>>>> >>>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>>>> are more complete. They include all later improvements by fixes or >>>>> adaptions in merge changes. >>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>> queue. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> PS: This can be used as the invokedynamic repository: >>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>>>> ppc-hotspot >>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>>>> stage-hotspot >>>>> cd stage-hotspot >>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>> hg qpush -a >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Here is result of my first attempt to build/test ppc changes together >>>>> with our closed sources. >>>>> >>>>> Small problems: >>>>> >>>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>>>> >>>>> Build on MacOS: >>>>> >>>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>>>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>>>> src/share/vm/opto/callGenerator.cpp:204: error: >>>>> 'zero_page_read_protected' is not a member of 'os' >>>>> >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> >>>>> >>>>> We have several conflict with closed sources builds: >>>>> >>>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>>>> signed and unsigned integer expressions >>>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>>>> signed and unsigned integer expressions >>>>> >>>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>>>> member function declared in class 'frame' >>>>> >>>>> error: no matching function for call to >>>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>>>> >>>>> I think it is due to changes like next: >>>>> >>>>> -#ifdef PPC >>>>> +#ifdef PPC32 >>>>> oop* interpreter_frame_mirror_addr() const; >>>>> >>>>> >>>>> Next is easy fix in our closed sources but it requires efforts from our >>>>> side: >>>>> >>>>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>>>> void MethodHandles::generate_adapters()': >>>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> >>>>> >>>>> I would suggest to do such shared changes which affects different builds >>>>> later after initial push. >>>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>> tested it successfully. In case you experience any problems >>>>>> please tell me the details so I can fix them. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>> To: Simonis, Volker >>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>> Alan Bateman >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Volker, >>>>>> >>>>>> Can you or someone update >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>> the >>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>> >>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>>> iris.clark at oracle.com >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> Sorry about this, one more thing about the JEP... >>>>>>> >>>>>>> I think that the "Discussion" list probably needs to be updated to be >>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>>>> as porters-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> iris >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi Iris, >>>>>>> >>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>> something better yesterday in the evening. >>>>>>> >>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>> it. >>>>>>> >>>>>>> Thanks, >>>>>>> Volker >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>> >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. >>>>>>> >>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>> repositories" in the revised title is not ideal: >>>>>>> >>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>> >>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>> >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> >>>>>>> JEP: 175 >>>>>>> >>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>> repositories >>>>>>> >>>>>>> Author: Volker Simonis >>>>>>> >>>>>>> Organization: SAP AG >>>>>>> >>>>>>> Created: 2013/1/11 >>>>>>> >>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>> additional details. >>>>>>> >>>>>>> Perhaps others have suggestions? >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>> index [1], see the third column. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. Please find >>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>> version >>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> In addition to the changes proposed by you I've added the contents of >>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>>>> to the JEP. >>>>>>> >>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>>>> Azeems "PPCAIX plan" document. >>>>>>> >>>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>>>> that page? >>>>>>> >>>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>> could help. >>>>>>> >>>>>>> If there are no objections I plan to checkin the new version of the JEP >>>>>>> tomorrow after our telephone call. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> [2]: >>>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>>>> Bateman; Vladimir Kozlov >>>>>>> *Subject:* JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> http://openjdk.java.net/jeps/175 >>>>>>> >>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>> comments: >>>>>>> >>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>> >>>>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>>>> only covering PPC/AIX. >>>>>>> >>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>> clear that it applies to Hotspot only. >>>>>>> >>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>> section at the bottom of JEP 1 [1].) >>>>>>> >>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>> line. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris Clark >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>> >>>> From goetz.lindenmaier at sap.com Thu Jun 13 14:36:42 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Jun 2013 21:36:42 +0000 Subject: RFR(S): 8016491: PPC64 (part 2): Clean up PPC defines. Message-ID: <4295855A5C1DE049A61835A1887419CC0CFE37E1@DEWDFEMB12A.global.corp.sap> Hi, Thanks for the bugid, Vladimir, I updated the webrev. http://cr.openjdk.java.net/~goetz/webrevs/8016491-PPC_defines/ I think defining PPC in macro.hpp makes it a bit more clear that it's meant for all, as it's coded in the #if. Also if I read code, I would more easily find it there than in platform_ppcXX. But the other way is OK, too. The #ifndef is not nice, I agree. Maybe a general #undef PPC before the #if? Best regards, Goetz. PS: About the JBS, I got the mail for the first change, but not for the second. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, June 13, 2013 11:11 PM To: Lindenmaier, Goetz Cc: 'David Holmes'; 'Chris Plummer'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: JEP 175 - Review comments On 6/13/13 1:25 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I made a webrev with the changes you proposed: > http://cr.openjdk.java.net/~goetz/webrevs/PPC_defines/ I am not sure about what is the best solution for #define PPC, with #ifdef check in macros.hpp or, as Chris suggested, remove it from macros.hpp and add -DPPC in platform_ppc and platform_ppc64. And we need to wait what David can suggest for frame.cpp (may be comment should be enough). > Unfortunately I didn't get the JBS mail with the bugid yet. > If I have that, I'll update the webrev change message. Sorry. It means I have to send Bug ID each time I created one :( For this one it is: 8016491: PPC64 (part 2): Clean up PPC defines. Please, resend request for review in separate mail as you did for first 8016476. I also filed next bug: 8016586: PPC64 (part 3): basic changes for PPC64 Thanks, Vladimir > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, June 13, 2013 7:24 PM > To: Lindenmaier, Goetz > Cc: David Holmes; Chris Plummer; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: JEP 175 - Review comments > > Hi, > > With next changes in make/linux/platform_ppc > > -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC > +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32 > > g++ still doesn't like it: > > /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1: > error: "PPC" redefined > : error: this is the location of the previous definition > > I have to do next changes in macros.hpp to pass it: > > #if defined(PPC32) || defined(PPC64) > +#ifndef PPC > #define PPC > +#endif > #define PPC_ONLY(code) code > #define NOT_PPC(code) > #else > +#undef PPC > #define PPC_ONLY(code) > #define NOT_PPC(code) code > #endif > > Please, fix your patch accordingly (it is all open sources). > > Thanks, > Vladimir > > On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I understand there are three cases: >> 1.) A real 32-bit processor/instruction set >> 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. >> 3.) A 64-bit processor/instruction set using 32-bit addresses etc. > > Is 3) theoretical combination or you are doing it? > >> >> My naming is the following: >> 1.) PPC32 >> 2.) PPC64 & LP64 >> 3.) PPC64 & !LP64. >> PPC should be valid for all. >> >> I understood your port is of kind 1., but I really don?t know that. >> Thus I changed the existing PPC guards to PPC32 where we don't >> need the guarded code. >> >> This distinction seems to me to fit well in >> os_bsd_zero.hpp >> os_linux_zero.hpp >> sharedRuntime.cpp >> sharedRuntime.hpp >> vm_version.cpp / FLOAT_ARCH_STR >> >> You are right for the defines in >> frame.hpp/frame.cpp >> Here I guard what is probably an implementation detail of your port and >> not a restriction of the architecture. But maybe you can clean up this >> piece of code, or tell me by what else I should guard this. >> >> In patch 0008 you see the libarch adaption: >> LIBARCH/ppc64 = ppc64 >> LIBARCH/ppc = ppc >> I'm happy to adapt the naming of your port however you want to. >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> yes, I changed PPC to PPC32 wherever we don't need the >> special case in our port. I do not know why you implemented >> the special cases, and maybe you need a define that is more >> verbose about the reason. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 13. Juni 2013 12:27 >> To: Lindenmaier, Goetz >> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Hi Goetz, >> >> On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> @Chris: -DPPC32 needs to be set in make//platform_ppc32. >> >> I think BUILD_ARCH would also need to be ppc32 to pick that up - but >> then we would need to change LIB_ARCH back to ppc. Is the 64-bit port >> using ppc64 as the LIB_ARCH? >> >>> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, >>> and in macros.hpp you find >> >> Okay I confess, it was a bad idea to generalize that given that out of >> the four platforms we support in the Oracle JDK, two are 32-bit only, so >> we only have sparc and x86 as examples. On sparc we only use SPARC and >> _LP64=1 to indicate things (and obviously in sparc specific files >> anything not in _LP64=1 is implicitly 32-bit). >> >> For x86 .... well x86 is a bit of a historical mess. So yes all those >> defines exist but the predominant form in shared code is X86 and AMD64 >> (as a synonym for LP64=1). IA32 exists but is barely used and arguably >> most of the places it remains are relics from before the 32-bit and >> 64-bit x86 code merge took place. So we have some historical baggage there. >> >> My main concern with the PPC, PPC32, PPC64 proposal is that the patch I >> saw: >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch >> >> seemed to use PPC32 in places I would not expect. I'm starting to feel >> that this is not 32 vs 64 per-se, but that PPC32 is being used as a way >> to flag "PPC Oracle" in a way that excludes it from use by the PPC64 >> port. If that is the case, and I can understand that it may well be >> given the existing PPC specific code was indeed put in place to support >> Oracle's PPC port, then perhaps we can look at ways of dealing with that >> without using what seems to me to be an artificial 32 vs 64-bit distinction? >> >> Aside: I would greatly prefer if ARM and PPC were never mentioned in the >> (existing) openjdk code, but that would require a level of refactoring >> in places that no-one unfortunately has the time to do. That said >> perhaps there are some places where a cleaner separation is possible. >> There are also places where compiler defines could be used to set string >> values rather than using the cpu ifdefs ie: >> >> #ifdef PPC >> #define CPU "ppc" >> etc >> >> David >> ----- >> >>> >>> #if defined(IA32) || defined(AMD64) >>> #define X86 >>> #define X86_ONLY(code) code >>> #define NOT_X86(code) >>> #else >>> #undef X86 >>> #define X86_ONLY(code) >>> #define NOT_X86(code) code >>> #endif >>> >>> It's just not that obvious as the names of these platforms >>> are messed up. On PPC I wanted to follow a clean approach. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 13. Juni 2013 04:46 >>> To: Lindenmaier, Goetz >>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: JEP 175 - Review comments >>> >>> Just adding my 2c from what was an internal discussion but is not in any >>> way confidential: >>> >>> We don't use 3 architecture designators on other platforms to >>> distinguish between "common", 32-bit and 64-bit, so why do we need to do >>> so for PPC ? >>> >>> The normal approach would be to add _LP64=1 specific ifdefs within an >>> architectural ifdef. >>> >>> This change (PPC32 usage) seems to be introducing unnecessary changes >>> and inconsistency with how 32-bit vs 64-bit is generally handled. >>> >>> Further, it is far from obvious from the patch that code now flagged as >>> PPC32 is indeed 32-bit specific rather than common! >>> >>> David >>> ----- >>> >>> On 13/06/2013 5:54 AM, Chris Plummer wrote: >>>> Hi Goetz, >>>> >>>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >>>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >>>> make/linux/platform_ppc. >>>> >>>> There are a lot of PPC references in c1 that don't appear to have been >>>> addressed. >>>> >>>> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >>>> allowing you to use >>>> >>>> #ifdef PPC >>>> >>>> rather than >>>> >>>> #if defined(PPC32) || defined(PPC64) >>>> >>>> best regards, >>>> >>>> Chris >>>> >>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> With my recent changes I removed some of the problems Vladimir mentioned. >>>>> >>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>> repository, >>>>> at hotspot/ppc_patches. >>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>> hotspots >>>>> can be built. >>>>> >>>>> The queue contains the changes proposed by me before, with minor >>>>> changes due >>>>> to recent development: >>>>> >>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>> 101-107 C-interpreter improvements >>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>> performant ppc port. >>>>> Altogether currently 49 changes. >>>>> >>>>> Our plan was to propose the changes in the order of the queue for >>>>> review. I'm happy to create webrevs for any of them. >>>>> >>>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>>>> are more complete. They include all later improvements by fixes or >>>>> adaptions in merge changes. >>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>> queue. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> PS: This can be used as the invokedynamic repository: >>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>>>> ppc-hotspot >>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>>>> stage-hotspot >>>>> cd stage-hotspot >>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>> hg qpush -a >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Here is result of my first attempt to build/test ppc changes together >>>>> with our closed sources. >>>>> >>>>> Small problems: >>>>> >>>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>>>> >>>>> Build on MacOS: >>>>> >>>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>>>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>>>> src/share/vm/opto/callGenerator.cpp:204: error: >>>>> 'zero_page_read_protected' is not a member of 'os' >>>>> >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>>>> UNSUPPORTED_ARCH >>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>>>> UNSUPPORTED_ARCH >>>>> >>>>> >>>>> We have several conflict with closed sources builds: >>>>> >>>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>>>> signed and unsigned integer expressions >>>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>>>> signed and unsigned integer expressions >>>>> >>>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>>>> member function declared in class 'frame' >>>>> >>>>> error: no matching function for call to >>>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>>>> >>>>> I think it is due to changes like next: >>>>> >>>>> -#ifdef PPC >>>>> +#ifdef PPC32 >>>>> oop* interpreter_frame_mirror_addr() const; >>>>> >>>>> >>>>> Next is easy fix in our closed sources but it requires efforts from our >>>>> side: >>>>> >>>>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>>>> void MethodHandles::generate_adapters()': >>>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>>>> cannot be used as a function >>>>> >>>>> >>>>> I would suggest to do such shared changes which affects different builds >>>>> later after initial push. >>>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>> tested it successfully. In case you experience any problems >>>>>> please tell me the details so I can fix them. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>> To: Simonis, Volker >>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>> Alan Bateman >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Volker, >>>>>> >>>>>> Can you or someone update >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>> the >>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>> >>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>>> iris.clark at oracle.com >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> Sorry about this, one more thing about the JEP... >>>>>>> >>>>>>> I think that the "Discussion" list probably needs to be updated to be >>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>>>> as porters-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> iris >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi Iris, >>>>>>> >>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>> something better yesterday in the evening. >>>>>>> >>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>> it. >>>>>>> >>>>>>> Thanks, >>>>>>> Volker >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>> >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. >>>>>>> >>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>> repositories" in the revised title is not ideal: >>>>>>> >>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>> >>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>> >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> >>>>>>> JEP: 175 >>>>>>> >>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>> repositories >>>>>>> >>>>>>> Author: Volker Simonis >>>>>>> >>>>>>> Organization: SAP AG >>>>>>> >>>>>>> Created: 2013/1/11 >>>>>>> >>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>> additional details. >>>>>>> >>>>>>> Perhaps others have suggestions? >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>> index [1], see the third column. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>> >>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've just updated the JEP according to your suggestions. Please find >>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>> version >>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>> >>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>> specified in the JEP specification)? >>>>>>> >>>>>>> In addition to the changes proposed by you I've added the contents of >>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>>>> to the JEP. >>>>>>> >>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>>>> Azeems "PPCAIX plan" document. >>>>>>> >>>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>>>> that page? >>>>>>> >>>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>> could help. >>>>>>> >>>>>>> If there are no objections I plan to checkin the new version of the JEP >>>>>>> tomorrow after our telephone call. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> [2]: >>>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>> Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>> ; Tim Ellison >>>>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>>>> Bateman; Vladimir Kozlov >>>>>>> *Subject:* JEP 175 - Review comments >>>>>>> >>>>>>> Hi, Volker. >>>>>>> >>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>> >>>>>>> http://openjdk.java.net/jeps/175 >>>>>>> >>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>> comments: >>>>>>> >>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>> >>>>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>>>> only covering PPC/AIX. >>>>>>> >>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>> clear that it applies to Hotspot only. >>>>>>> >>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>> section at the bottom of JEP 1 [1].) >>>>>>> >>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>> line. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Iris Clark >>>>>>> >>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>> >>>> From vladimir.kozlov at oracle.com Thu Jun 13 14:42:33 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2013 14:42:33 -0700 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: <51B9A34F.8080702@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> <51B9A34F.8080702@oracle.com> Message-ID: <51BA3CC9.8040100@oracle.com> On 6/13/13 3:47 AM, David Holmes wrote: > On 13/06/2013 7:53 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I fixed the jvmg target and prepared a webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ >> >> Thanks for reviewing, Vladimir. >> I need a second reviewer, please. > > So to clarify, this restores the old core targets but will only actually > work on the new ports? If so do we want to validate that in > generic_buildcore similar to the way we validate in generic_buildminimal1? It would be nice to have such validation but on other hand we don't have it for zero and shark, platforms which Oracle does not support. And core will not be in our official builds or supported. thanks, Vladimir > > There is a huge amount of cleanup I'd like to do in this makefile to > remove all the copy'n'paste duplication. :( > > Thanks, > David > >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >> Kozlov >> Sent: Donnerstag, 13. Juni 2013 00:58 >> To: Volker Simonis >> Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; >> hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Hi, Volker >> >> 0001_fix_core_build.patch passed JPRT build/test run so it is good, >> consider reviewed (assuming you fix jvmgcore). >> >> Should we formalize the process to follow our normal openjdk review >> process? It will allow other people to see what is coming and to comment >> on it as you said and I agree. >> >> - I will file rfes and add Volker and Goetz to watch list so you get >> notifications (I hope) about rfes. >> >> - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail >> aliases. >> >> - We do reviews and small testing to make sure changes do not break our >> builds. >> >> - You prepare final patch with correct changeset header after we agree >> on changes. >> >> - I push it to staging repo. >> >> Is this acceptable to you? >> >> About changeset header: >> >> : >> Summary: >> Reviewed-by: + >> Contributed-by: >> >> I don't think you need "Contributed-by:" since Volker could be author. >> But it is up to you if you want to mention other contributors. >> >> 8016476: PPC64 (part 1): reenable CORE build >> Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 >> Reviewed-by: kvn >> >> Thanks, >> Vladimir >> >> PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, >> check that you get notification. You are on watch list. >> >> >> On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >>> Okay, I will add comment to the rfe that CORE target is only used on >>> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >>> now). >>> >>> Vladimir >>> >>> On 6/12/13 11:51 AM, Volker Simonis wrote: >>>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>>> >>>> wrote: >>>> >>>>> Thanks, Goetz >>>>> >>>>> I am perfectly fine with such granularity and I can start generating >>>>> RFEs. >>>>> I filed first: >>>>> >>>>> 8016476: PPC64 (part 1): reenable CORE build >>>>> >>>>> >>>> Thanks! >>>> >>>> >>>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>>> build it >>>>> on my Mac: >>>>> >>>>> >>>> We haven't fixed the CORE build on all platforms. It should wok on >>>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>>> >>>> This is the general approach we have taken. So I'm not sure what >>>> will be >>>> the best way for you to review the changes. But all of the patches >>>> from the >>>> first series of changes (1-9) won't probably do anything useful on >>>> Linux/x86 and Solaris because we haven't fixed the CORE build and >>>> the C++ >>>> interpreter on that platforms. So building a CORE build or the C++ >>>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>>> (and was >>>> not the scope of this project). >>>> >>>> I think the review for these patches should only make sure that they >>>> don't >>>> break anything that worked before an any supported platforms (and >>>> trust us >>>> that they are good for our platforms:). >>>> >>>> So in that sense "reenable CORE build" only means to provide the >>>> appropriate targets in the Makefiles and not the required source code >>>> fixes >>>> on all platforms (although they may be trivial/minimal). But if you'd >>>> absolutely also want to have a core build on Linux/x86 and Solaris, >>>> I can >>>> have a look at it. >>>> >>>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>>> gnumake[2]: *** [debugcore] Error 2 >>>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>>> gnumake: *** [debugcore] Error 2 >>>>> >>>>> And on SPARC: >>>>> >>>>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>>>> declaration for pd_InlineSmallCode. >>>>> >>>>> And you should used debugcore instead of jvmgcore: >>>>> +all_debugcore: jvmgcore docs export_debug >>>>> >>>>> I want your changes be perfect from the start ;) >>>>> >>>> >>>> You're right. The renaming of the 'jvmg' target to 'debug' has happened >>>> recently ( >>>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >>>> >>>> we haven't adapted it. We will fix this. >>>> >>>> >>>>> And I need to discuss with our embedded group about >>>>> 0002_PPC_defines.patch >>>>> because it affects them. It may take time. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi Vladimir, >>>>>> >>>>>> yes, the plan is that each is self contained. When I set up the >>>>>> patches I >>>>>> built and jckecked each. When I updated them I only built them >>>>>> selectively, >>>>>> so there might be minor issues. I had planned to assure this once I >>>>>> make >>>>>> webrevs from the patches. >>>>>> >>>>>> Some of them might apply in any order, but others depend on previous >>>>>> ones, >>>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>>> before. >>>>>> >>>>>> The patches work with hs25-b34. >>>>>> >>>>>> Please tell me if I can do anything to ease your reviewing. >>>>>> >>>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>>> changes necessary to other platform code to a minimum, but also tried >>>>>> to avoid strange workarounds. Therefore I for example did change >>>>>> 0002 >>>>>> renaming the PPC defines, see the comment there. >>>>>> >>>>>> If you agree with the granularity of the changes, it would be great >>>>>> if you >>>>>> could generate bug-ids for them. Maybe at least for the changes >>>>>> up to 0016? >>>>>> >>>>>> Best regards >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov >>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>> ] >>>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: >>>>>> ppc-aix-port-dev at openjdk.java.**net; >>>>>> >>>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris >>>>>> Plummer >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Thank you, Goetz. >>>>>> >>>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>>> with >>>>>> jdk8 and build? Or I should do review all 1-9 >>>>>> patches and merge them together into jdk8 to be able build? In >>>>>> short, is >>>>>> each patch self-contain? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> With my recent changes I removed some of the problems Vladimir >>>>>>> mentioned. >>>>>>> >>>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>>> repository, >>>>>>> at hotspot/ppc_patches. >>>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>>> hotspots >>>>>>> can be built. >>>>>>> >>>>>>> The queue contains the changes proposed by me before, with minor >>>>>>> changes >>>>>>> due >>>>>>> to recent development: >>>>>>> >>>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>>> 101-107 C-interpreter improvements >>>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>>> performant ppc port. >>>>>>> Altogether currently 49 changes. >>>>>>> >>>>>>> Our plan was to propose the changes in the order of the queue for >>>>>>> review. I'm happy to create webrevs for any of them. >>>>>>> >>>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>>> changes >>>>>>> are more complete. They include all later improvements by fixes or >>>>>>> adaptions in merge changes. >>>>>>> For why and where I renamed PPC to PPC32 see the second change in >>>>>>> the >>>>>>> queue. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> PS: This can be used as the invokedynamic repository: >>>>>>> hg clone >>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>>>> >>>>>>> ppc-hotspot >>>>>>> hg clone >>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>>>> >>>>>>> >>>>>>> cd stage-hotspot >>>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>>> hg qpush -a >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov >>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>> ] >>>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Here is result of my first attempt to build/test ppc changes >>>>>>> together >>>>>>> with our closed sources. >>>>>>> >>>>>>> Small problems: >>>>>>> >>>>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>>>> >>>>>>> Build on MacOS: >>>>>>> >>>>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>>> >>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> >>>>>>> >>>>>>> We have several conflict with closed sources builds: >>>>>>> >>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function >>>>>>> 'bool >>>>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>>>> between >>>>>>> signed and unsigned integer expressions >>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>>>> between >>>>>>> signed and unsigned integer expressions >>>>>>> >>>>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>>>> member function declared in class 'frame' >>>>>>> >>>>>>> error: no matching function for call to >>>>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>>>> uint&)' >>>>>>> >>>>>>> I think it is due to changes like next: >>>>>>> >>>>>>> -#ifdef PPC >>>>>>> +#ifdef PPC32 >>>>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>>>> >>>>>>> >>>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>>> our >>>>>>> side: >>>>>>> >>>>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>>>> 'static >>>>>>> void MethodHandles::generate_**adapters()': >>>>>>> src/share/vm/prims/**methodHandles.cpp:68: error: >>>>>>> 'adapter_code_size' >>>>>>> cannot be used as a function >>>>>>> src/share/vm/prims/**methodHandles.cpp:70: error: >>>>>>> 'adapter_code_size' >>>>>>> cannot be used as a function >>>>>>> >>>>>>> >>>>>>> I would suggest to do such shared changes which affects different >>>>>>> builds >>>>>>> later after initial push. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>>> tested it successfully. In case you experience any problems >>>>>>>> please tell me the details so I can fix them. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov >>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>> ] >>>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>>> To: Simonis, Volker >>>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; >>>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>>> Bateman >>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>> >>>>>>>> Volker, >>>>>>>> >>>>>>>> Can you or someone update >>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>>>> >>>>>>>> match latest >>>>>>>> sources in >>>>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>>>> >>>>>>>> >>>>>>>> ? >>>>>>>> I just tried to merge them and build Hotspot on x86 without >>>>>>>> success. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> We intentionally used 'porters-dev' rather >>>>>>>>> than'ppc-aix-port-dev' in >>>>>>>>> the >>>>>>>>> beginning to address a broader audience for the initial >>>>>>>>> discussions. >>>>>>>>> >>>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------**------------------------------** >>>>>>>>> ------------ >>>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>> Ellison; >>>>>>>>> iris.clark at oracle.com >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>>> >>>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>>> to be >>>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>>> listed >>>>>>>>> as porters-dev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> iris >>>>>>>>> >>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>> Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi Iris, >>>>>>>>> >>>>>>>>> you're right, the title is too clumsy - I just couldn't come up >>>>>>>>> with >>>>>>>>> something better yesterday in the evening. >>>>>>>>> >>>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll >>>>>>>>> take >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> ------------------------------**------------------------------** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>>> >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>>> >>>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK >>>>>>>>> master >>>>>>>>> repositories" in the revised title is not ideal: >>>>>>>>> >>>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>>> >>>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>>> >>>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>>> >>>>>>>>> JEP: 175 >>>>>>>>> >>>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>> >>>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>>> repositories >>>>>>>>> >>>>>>>>> Author: Volker Simonis >>>>>>>>> >>>>>>>>> Organization: SAP AG >>>>>>>>> >>>>>>>>> Created: 2013/1/11 >>>>>>>>> >>>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs >>>>>>>>> are all >>>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>>> Unicode >>>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself >>>>>>>>> contains >>>>>>>>> additional details. >>>>>>>>> >>>>>>>>> Perhaps others have suggestions? >>>>>>>>> >>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>> still be >>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>> be set >>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>> specified in the JEP specification)? >>>>>>>>> >>>>>>>>> Yes. Once that field is populated, the value will appear in >>>>>>>>> the JEP >>>>>>>>> index [1], see the third column. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Iris >>>>>>>>> >>>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>>> >>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>>> find >>>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>>> version >>>>>>>>> in until now to give everybody a chance to comment on the >>>>>>>>> changes). >>>>>>>>> >>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>> still be >>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>> be set >>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>> specified in the JEP specification)? >>>>>>>>> >>>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>>> contents of >>>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>>> "Description" >>>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>>> Port >>>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>>> Space" [3] >>>>>>>>> to the JEP. >>>>>>>>> >>>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>>> to hold >>>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>>> >>>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>>> rights to >>>>>>>>> that page? >>>>>>>>> >>>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>>> "PPCAIX >>>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>>> saw that >>>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>>> and in >>>>>>>>> my unlimited naivety I imagine this could be a simple >>>>>>>>> copy-and-paste >>>>>>>>> operation:) If that doesn't work so easily, please let me know >>>>>>>>> how I >>>>>>>>> could help. >>>>>>>>> >>>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>>> the JEP >>>>>>>>> tomorrow after our telephone call. >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> [2]: >>>>>>>>> https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>>>> 13729959 >>>>>>>>> >>>>>>>>> >>>>>>>>> [3]: >>>>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------**------------------------------** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>>>> Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>> >>>>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>>>> >>>>>>>>> >>>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>>> comments: >>>>>>>>> >>>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>>> >>>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>>> it is >>>>>>>>> only covering PPC/AIX. >>>>>>>>> >>>>>>>>> -Recommend that the second Motivation bullet be modified to >>>>>>>>> make it >>>>>>>>> clear that it applies to Hotspot only. >>>>>>>>> >>>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>>> >>>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>>> up to >>>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>>> line. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Iris Clark >>>>>>>>> >>>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>>> >>>>>>>>> From alejandro.murillo at oracle.com Thu Jun 13 15:15:42 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 13 Jun 2013 22:15:42 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130613221551.C29AA481E4@hg.openjdk.java.net> Changeset: aa8623d58971 Author: katleman Date: 2013-06-12 19:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aa8623d58971 Added tag jdk7u40-b29 for changeset d74376b0f20b ! .hgtags Changeset: 88e43f47a8da Author: amurillo Date: 2013-06-13 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/88e43f47a8da Merge - src/share/vm/memory/klassInfoClosure.hpp Changeset: 241ab36a8b84 Author: amurillo Date: 2013-06-13 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/241ab36a8b84 Added tag hs24-b49 for changeset 88e43f47a8da ! .hgtags From goetz.lindenmaier at sap.com Thu Jun 13 15:38:25 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Jun 2013 22:38:25 +0000 Subject: RFR(M): 8016586: PPC64 (part 3): basic changes for PPC64 Message-ID: <4295855A5C1DE049A61835A1887419CC0CFE3818@DEWDFEMB12A.global.corp.sap> Hi, http://cr.openjdk.java.net/~goetz/webrevs/8016586-inlcudes/ This change contains the #includes we need for the linuxppc64 port, and some other minor changes. It decides about the file names in the cpu/ppc directory. We changed some of your #includes to use _32 extension, basically where they are guarded by TARGET_ARCH_MODEL... . I think it would make sense to set TARGET_ARCH_MODEL_ppc_32 instead of TARGET_ARCH_MODEL_ppc in your port, and name all files used within that define with extension _32. In the webrev this is changed consistently (not so in the patch). What are your politics about ordering the includes here? Most other includes are alpha sorted, but the platforms here are not at all. If you wish to, I'll establish a certain order. The changes in compileBroker.cpp and globals.hpp/EnableInvokeDynamic are preliminary. They'll be reverted in later changes. I would be glad if you could review this change, Best regards & thanks, Goetz. From alejandro.murillo at oracle.com Thu Jun 13 18:28:23 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 14 Jun 2013 01:28:23 +0000 Subject: hg: hsx/hsx24/hotspot: 8016566: new hotspot build - hs24-b50 Message-ID: <20130614012828.55945481EC@hg.openjdk.java.net> Changeset: 9ba4f38e3000 Author: amurillo Date: 2013-06-13 11:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9ba4f38e3000 8016566: new hotspot build - hs24-b50 Reviewed-by: jcoomes ! make/hotspot_version From john.r.rose at oracle.com Thu Jun 13 18:55:28 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Jun 2013 18:55:28 -0700 Subject: Class verifier issues with unboxing method handles In-Reply-To: <51A5E59F.9040007@oracle.com> References: <51A5543B.10506@talios.com> <51A55E5E.4020605@oracle.com> <51A5E59F.9040007@oracle.com> Message-ID: A REF_newInvokeSpecial method handle constant refers to a void-returning method named , but its bytecode behavior returns a reference to the constructed object. This may require special checks, such as with 'actualReturnType' in AbstractValidatingLambdaMetafactory.java. There is a missing check in InnerClassLambdaMetafactory.java. Here is a suggested fix (which I have not tested). ? John diff --git a/src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java b/src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java --- a/src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java +++ b/src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java @@ -112,7 +112,10 @@ implMethodDesc = implMethodType.toMethodDescriptorString(); Type implMethodAsmType = Type.getMethodType(implMethodDesc); implMethodArgumentTypes = implMethodAsmType.getArgumentTypes(); - implMethodReturnType = implMethodAsmType.getReturnType(); + if (implKind == MethodHandleInfo.REF_newInvokeSpecial) + implMethodReturnType = Type.getType(implMethodClassName); + else + implMethodReturnType = implMethodAsmType.getReturnType(); constructorType = invokedType.changeReturnType(Void.TYPE); constructorDesc = constructorType.toMethodDescriptorString(); lambdaClassName = targetClass.getName().replace('.', '/') + "$$Lambda$" + counter.incrementAndGet(); On May 29, 2013, at 4:25 AM, Maurizio Cimadamore wrote: > David, Mark, > a minimal test case to reproduce the issue is this: > > interface IntFunction { > int m(X x); > } > > class Test { > public static void main(String[] args) { > IntFunction s = Integer::new; > } > } > > > Looking at the javap output, in particular at the indy call details, we > find this: > > BootstrapMethods: > 0: #15 invokestatic > java/lang/invoke/LambdaMetafactory.metaFactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > Method arguments: > #16 invokeinterface IntFunction.m:(Ljava/lang/Object;)I > #17 newinvokespecial > java/lang/Integer."":(Ljava/lang/String;)V > #18 (Ljava/lang/String;)I > > > This seems correct; however, judging from the runtime error, it seems > like the metafactory is not unboxing the Integer instance back to int > (which is the expected return value of the implemented method). Hence > the 292 link failure. Robert, Brian can you confirm? > > Maurizio > > > On 29/05/13 02:48, David Holmes wrote: >> Hi Mark, >> >> cc'ing lambda-dev. This may be a bug, a version mismatch, or something >> else. The lambda-dev folk will know. >> >> David >> >> On 29/05/2013 11:04 AM, Mark Derricutt wrote: >>> Hi all, >>> >>> Mark Reinhold suggested I posted this question/bug report to hotspot-dev >>> rather than jdk8-dev so here goes. >>> >>> I have a fairly simple test case using the new streams API: >>> >>> public static void main(String[] args) { >>> List strings = Arrays.asList("1", "2", "3", "4", "5"); >>> strings.stream() >>> .mapToInt(s -> new Integer(s)) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> } >>> >>> >>> which compiles, runs, and prints out what I expect: >>> >>> int 1 >>> int 2 >>> int 3 >>> int 4 >>> int 5 >>> >>> >>> Given that mapToInt() is returning an IntegerStream wrapping primitive >>> ints, the result of my closure is successfully autoboxed down to an int >>> and all is happy with the world. >>> >>> If I change this code to be: >>> >>> strings.stream() >>> .mapToInt(Integer::parseInt) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> >>> Again, everything works as expected as Integer::parseInt returns an int, >>> so there's no boxing. >>> >>> Changing this once again to: >>> >>> strings.stream() >>> .mapToInt(Integer::valueOf) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> >>> I also see the expected result, Integer::valueOf returns an Integer >>> which is then being boxed down to an int. >>> >>> However, if I change the code to: >>> >>> strings.stream() >>> .mapToInt(Integer::new) >>> .forEach(i -> System.out.println(String.format("int %d", i))); >>> >>> which, if I understand correctly - Integer::new should be returning a >>> method handle to the constructor. IntelliJ IDEA 13 autocompletes this >>> for me, and hyperlinks to the Integer(String s) constructor, javac >>> successfully compiles the code so my -assumption- is that the >>> constructor would be called, returning an Integer which is then boxed >>> down to an int, however, this is what I get: >>> >>> Exception in thread "main" java.lang.BootstrapMethodError: call site >>> initialization exception >>> at java.lang.invoke.CallSite.makeSite(CallSite.java:298) >>> at >>> java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:294) >>> >>> at com.talios.test.TestJdk.main(TestJdk.java:12) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:491) >>> at >>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >>> Caused by: java.lang.VerifyError: Bad type on operand stack >>> Exception Details: >>> Location: >>> com/talios/test/TestJdk$$Lambda$1.applyAsInt(Ljava/lang/Object;)I >>> @11: ireturn >>> Reason: >>> Type 'java/lang/Integer' (current frame, stack[0]) is not >>> assignable to integer >>> Current Frame: >>> bci: @11 >>> flags: { } >>> locals: { 'com/talios/test/TestJdk$$Lambda$1', 'java/lang/Object' } >>> stack: { 'java/lang/Integer' } >>> Bytecode: >>> 0000000: bb00 0e59 2bc0 0010 b700 13ac >>> >>> at java.lang.Class.getDeclaredConstructors0(Native Method) >>> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2536) >>> at java.lang.Class.getDeclaredConstructors(Class.java:1928) >>> at >>> java.lang.invoke.InnerClassLambdaMetafactory$1.run(InnerClassLambdaMetafactory.java:147) >>> >>> at >>> java.lang.invoke.InnerClassLambdaMetafactory$1.run(InnerClassLambdaMetafactory.java:144) >>> >>> at java.security.AccessController.doPrivileged(Native Method) >>> at >>> java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite(InnerClassLambdaMetafactory.java:143) >>> >>> at >>> java.lang.invoke.LambdaMetafactory.metaFactory(LambdaMetafactory.java:191) >>> at java.lang.invoke.CallSite.makeSite(CallSite.java:283) >>> ... 7 more >>> >>> This is on OSX Mountain Lion, with JDK 8 Build 91. >>> >>> Have I walked in an obscure corner case of method handle breakage and >>> found something new, or is this a new problem? >>> >>> Cheers, >>> Mark >>> > > From david.holmes at oracle.com Thu Jun 13 23:07:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Jun 2013 16:07:32 +1000 Subject: RFR(S): 8016491: PPC64 (part 2): Clean up PPC defines. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE37E1@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE37E1@DEWDFEMB12A.global.corp.sap> Message-ID: <51BAB324.3060708@oracle.com> Hi Goetz, I think having platform_ppc define PPC32, and platform_ppc64 define PPC64, with macros.hpp doing #if defined(PPC32) | defined(PPC64) #infdef PPC #define PPC is the right way to do this. It echoes what we do for x86. I was concerned that ppc32 was going to propagate everywhere but it appears that we would still use "ppc" to reflect a 32-bit PPC build eg as the ARCH and BUILD_ARCH value, in platform_ppc, and in TARGET_ARCH_ppc etc. I assume your port (I hate this 'yours', 'ours' business :( ) uses ppc64 ? A few places where PPC has become PPC32 indicate where cleanup is needed anyway: - os_xxx.cpp: the cpu_arch[] strings should not be hardwired in the file given they represent values we already define in the platform_xxx file. - vm_version.cpp. The #define for CPU again should be handled via a variable passed by make; or at a minimum could be inside the platform specific vm_version_xxx.hpp files! The FLOAT_ARCH strings are superfluous now as we always set FLOAT_ARCH via the build - this should be cleaned up. The change in os_xxx_zero.hpp seems unnecessary but harmless. The change in frame.h/cpp is indeed strange. I have no idea why our PPC port needs to do something in a completely different way to our other 3 platforms. I will raise this with the team and see what can be done. Similarly for sharedRuntime.h/cpp. I would expect this to be conditional on the FP support. So this all seems okay to me. Thanks, David On 14/06/2013 7:36 AM, Lindenmaier, Goetz wrote: > Hi, > > Thanks for the bugid, Vladimir, I updated the webrev. > http://cr.openjdk.java.net/~goetz/webrevs/8016491-PPC_defines/ > > I think defining PPC in macro.hpp makes it a bit more clear that > it's meant for all, as it's coded in the #if. Also if I read code, I would > more easily find it there than in platform_ppcXX. > But the other way is OK, too. > The #ifndef is not nice, I agree. Maybe a general #undef PPC > before the #if? > > Best regards, > Goetz. > > PS: About the JBS, I got the mail for the first change, but not for > the second. > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, June 13, 2013 11:11 PM > To: Lindenmaier, Goetz > Cc: 'David Holmes'; 'Chris Plummer'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: JEP 175 - Review comments > > On 6/13/13 1:25 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I made a webrev with the changes you proposed: >> http://cr.openjdk.java.net/~goetz/webrevs/PPC_defines/ > > I am not sure about what is the best solution for #define PPC, with > #ifdef check in macros.hpp or, as Chris suggested, remove it from > macros.hpp and add -DPPC in platform_ppc and platform_ppc64. > > And we need to wait what David can suggest for frame.cpp (may be comment > should be enough). > >> Unfortunately I didn't get the JBS mail with the bugid yet. >> If I have that, I'll update the webrev change message. > > Sorry. It means I have to send Bug ID each time I created one :( > For this one it is: > > 8016491: PPC64 (part 2): Clean up PPC defines. > > Please, resend request for review in separate mail as you did for first > 8016476. > > I also filed next bug: > > 8016586: PPC64 (part 3): basic changes for PPC64 > > Thanks, > Vladimir > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, June 13, 2013 7:24 PM >> To: Lindenmaier, Goetz >> Cc: David Holmes; Chris Plummer; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: JEP 175 - Review comments >> >> Hi, >> >> With next changes in make/linux/platform_ppc >> >> -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC >> +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32 >> >> g++ still doesn't like it: >> >> /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1: >> error: "PPC" redefined >> : error: this is the location of the previous definition >> >> I have to do next changes in macros.hpp to pass it: >> >> #if defined(PPC32) || defined(PPC64) >> +#ifndef PPC >> #define PPC >> +#endif >> #define PPC_ONLY(code) code >> #define NOT_PPC(code) >> #else >> +#undef PPC >> #define PPC_ONLY(code) >> #define NOT_PPC(code) code >> #endif >> >> Please, fix your patch accordingly (it is all open sources). >> >> Thanks, >> Vladimir >> >> On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> I understand there are three cases: >>> 1.) A real 32-bit processor/instruction set >>> 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. >>> 3.) A 64-bit processor/instruction set using 32-bit addresses etc. >> >> Is 3) theoretical combination or you are doing it? >> >>> >>> My naming is the following: >>> 1.) PPC32 >>> 2.) PPC64 & LP64 >>> 3.) PPC64 & !LP64. >>> PPC should be valid for all. >>> >>> I understood your port is of kind 1., but I really don?t know that. >>> Thus I changed the existing PPC guards to PPC32 where we don't >>> need the guarded code. >>> >>> This distinction seems to me to fit well in >>> os_bsd_zero.hpp >>> os_linux_zero.hpp >>> sharedRuntime.cpp >>> sharedRuntime.hpp >>> vm_version.cpp / FLOAT_ARCH_STR >>> >>> You are right for the defines in >>> frame.hpp/frame.cpp >>> Here I guard what is probably an implementation detail of your port and >>> not a restriction of the architecture. But maybe you can clean up this >>> piece of code, or tell me by what else I should guard this. >>> >>> In patch 0008 you see the libarch adaption: >>> LIBARCH/ppc64 = ppc64 >>> LIBARCH/ppc = ppc >>> I'm happy to adapt the naming of your port however you want to. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> yes, I changed PPC to PPC32 wherever we don't need the >>> special case in our port. I do not know why you implemented >>> the special cases, and maybe you need a define that is more >>> verbose about the reason. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 13. Juni 2013 12:27 >>> To: Lindenmaier, Goetz >>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: JEP 175 - Review comments >>> >>> Hi Goetz, >>> >>> On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> @Chris: -DPPC32 needs to be set in make//platform_ppc32. >>> >>> I think BUILD_ARCH would also need to be ppc32 to pick that up - but >>> then we would need to change LIB_ARCH back to ppc. Is the 64-bit port >>> using ppc64 as the LIB_ARCH? >>> >>>> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, >>>> and in macros.hpp you find >>> >>> Okay I confess, it was a bad idea to generalize that given that out of >>> the four platforms we support in the Oracle JDK, two are 32-bit only, so >>> we only have sparc and x86 as examples. On sparc we only use SPARC and >>> _LP64=1 to indicate things (and obviously in sparc specific files >>> anything not in _LP64=1 is implicitly 32-bit). >>> >>> For x86 .... well x86 is a bit of a historical mess. So yes all those >>> defines exist but the predominant form in shared code is X86 and AMD64 >>> (as a synonym for LP64=1). IA32 exists but is barely used and arguably >>> most of the places it remains are relics from before the 32-bit and >>> 64-bit x86 code merge took place. So we have some historical baggage there. >>> >>> My main concern with the PPC, PPC32, PPC64 proposal is that the patch I >>> saw: >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch >>> >>> seemed to use PPC32 in places I would not expect. I'm starting to feel >>> that this is not 32 vs 64 per-se, but that PPC32 is being used as a way >>> to flag "PPC Oracle" in a way that excludes it from use by the PPC64 >>> port. If that is the case, and I can understand that it may well be >>> given the existing PPC specific code was indeed put in place to support >>> Oracle's PPC port, then perhaps we can look at ways of dealing with that >>> without using what seems to me to be an artificial 32 vs 64-bit distinction? >>> >>> Aside: I would greatly prefer if ARM and PPC were never mentioned in the >>> (existing) openjdk code, but that would require a level of refactoring >>> in places that no-one unfortunately has the time to do. That said >>> perhaps there are some places where a cleaner separation is possible. >>> There are also places where compiler defines could be used to set string >>> values rather than using the cpu ifdefs ie: >>> >>> #ifdef PPC >>> #define CPU "ppc" >>> etc >>> >>> David >>> ----- >>> >>>> >>>> #if defined(IA32) || defined(AMD64) >>>> #define X86 >>>> #define X86_ONLY(code) code >>>> #define NOT_X86(code) >>>> #else >>>> #undef X86 >>>> #define X86_ONLY(code) >>>> #define NOT_X86(code) code >>>> #endif >>>> >>>> It's just not that obvious as the names of these platforms >>>> are messed up. On PPC I wanted to follow a clean approach. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 13. Juni 2013 04:46 >>>> To: Lindenmaier, Goetz >>>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Just adding my 2c from what was an internal discussion but is not in any >>>> way confidential: >>>> >>>> We don't use 3 architecture designators on other platforms to >>>> distinguish between "common", 32-bit and 64-bit, so why do we need to do >>>> so for PPC ? >>>> >>>> The normal approach would be to add _LP64=1 specific ifdefs within an >>>> architectural ifdef. >>>> >>>> This change (PPC32 usage) seems to be introducing unnecessary changes >>>> and inconsistency with how 32-bit vs 64-bit is generally handled. >>>> >>>> Further, it is far from obvious from the patch that code now flagged as >>>> PPC32 is indeed 32-bit specific rather than common! >>>> >>>> David >>>> ----- >>>> >>>> On 13/06/2013 5:54 AM, Chris Plummer wrote: >>>>> Hi Goetz, >>>>> >>>>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >>>>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >>>>> make/linux/platform_ppc. >>>>> >>>>> There are a lot of PPC references in c1 that don't appear to have been >>>>> addressed. >>>>> >>>>> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >>>>> allowing you to use >>>>> >>>>> #ifdef PPC >>>>> >>>>> rather than >>>>> >>>>> #if defined(PPC32) || defined(PPC64) >>>>> >>>>> best regards, >>>>> >>>>> Chris >>>>> >>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> With my recent changes I removed some of the problems Vladimir mentioned. >>>>>> >>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>> repository, >>>>>> at hotspot/ppc_patches. >>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>> hotspots >>>>>> can be built. >>>>>> >>>>>> The queue contains the changes proposed by me before, with minor >>>>>> changes due >>>>>> to recent development: >>>>>> >>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>> 101-107 C-interpreter improvements >>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>> performant ppc port. >>>>>> Altogether currently 49 changes. >>>>>> >>>>>> Our plan was to propose the changes in the order of the queue for >>>>>> review. I'm happy to create webrevs for any of them. >>>>>> >>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>>>>> are more complete. They include all later improvements by fixes or >>>>>> adaptions in merge changes. >>>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>>> queue. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> PS: This can be used as the invokedynamic repository: >>>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>>>>> ppc-hotspot >>>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>>>>> stage-hotspot >>>>>> cd stage-hotspot >>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>> hg qpush -a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>> Subject: Re: JEP 175 - Review comments >>>>>> >>>>>> Here is result of my first attempt to build/test ppc changes together >>>>>> with our closed sources. >>>>>> >>>>>> Small problems: >>>>>> >>>>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>>>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>>>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>>>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>>>>> >>>>>> Build on MacOS: >>>>>> >>>>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>>>>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>>>>> src/share/vm/opto/callGenerator.cpp:204: error: >>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>> >>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>>>>> UNSUPPORTED_ARCH >>>>>> >>>>>> >>>>>> We have several conflict with closed sources builds: >>>>>> >>>>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>>>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>>>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>>>>> signed and unsigned integer expressions >>>>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>>>>> signed and unsigned integer expressions >>>>>> >>>>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>>>>> member function declared in class 'frame' >>>>>> >>>>>> error: no matching function for call to >>>>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>>>>> >>>>>> I think it is due to changes like next: >>>>>> >>>>>> -#ifdef PPC >>>>>> +#ifdef PPC32 >>>>>> oop* interpreter_frame_mirror_addr() const; >>>>>> >>>>>> >>>>>> Next is easy fix in our closed sources but it requires efforts from our >>>>>> side: >>>>>> >>>>>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>>>>> void MethodHandles::generate_adapters()': >>>>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>>>>> cannot be used as a function >>>>>> >>>>>> >>>>>> I would suggest to do such shared changes which affects different builds >>>>>> later after initial push. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>> tested it successfully. In case you experience any problems >>>>>>> please tell me the details so I can fix them. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>> To: Simonis, Volker >>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>>> Alan Bateman >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Volker, >>>>>>> >>>>>>> Can you or someone update >>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>>> the >>>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>>> >>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>>>> iris.clark at oracle.com >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>> >>>>>>>> I think that the "Discussion" list probably needs to be updated to be >>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>>>>> as porters-dev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> iris >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi Iris, >>>>>>>> >>>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>>> something better yesterday in the evening. >>>>>>>> >>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>>> it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Volker >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>> >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>> >>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>>> repositories" in the revised title is not ideal: >>>>>>>> >>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>> >>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>> >>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>> >>>>>>>> JEP: 175 >>>>>>>> >>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>> repositories >>>>>>>> >>>>>>>> Author: Volker Simonis >>>>>>>> >>>>>>>> Organization: SAP AG >>>>>>>> >>>>>>>> Created: 2013/1/11 >>>>>>>> >>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>>> additional details. >>>>>>>> >>>>>>>> Perhaps others have suggestions? >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>>> index [1], see the third column. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>> >>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've just updated the JEP according to your suggestions. Please find >>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>> version >>>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>>> >>>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>> specified in the JEP specification)? >>>>>>>> >>>>>>>> In addition to the changes proposed by you I've added the contents of >>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>>>>> to the JEP. >>>>>>>> >>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>> >>>>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>>>>> that page? >>>>>>>> >>>>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>>> could help. >>>>>>>> >>>>>>>> If there are no objections I plan to checkin the new version of the JEP >>>>>>>> tomorrow after our telephone call. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> [2]: >>>>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>> Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>> ; Tim Ellison >>>>>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>>>>> Bateman; Vladimir Kozlov >>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>> >>>>>>>> Hi, Volker. >>>>>>>> >>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>> >>>>>>>> http://openjdk.java.net/jeps/175 >>>>>>>> >>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>> comments: >>>>>>>> >>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>> >>>>>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>>>>> only covering PPC/AIX. >>>>>>>> >>>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>>> clear that it applies to Hotspot only. >>>>>>>> >>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>> >>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>> line. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Iris Clark >>>>>>>> >>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>> >>>>> From vladimir.kozlov at oracle.com Thu Jun 13 23:37:04 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2013 23:37:04 -0700 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: <51BA3CC9.8040100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> <51B9A34F.8080702@oracle.com> <51BA3CC9.8040100@oracle.com> Message-ID: <51BABA10.50805@oracle.com> Hi, Goetz I talked with David and we want you to add OS checks as generic_buildminimal1 does to avoid a confusion in future if someone (as I did) try to build CORE on other platforms. CORE was one of our supported builds and someone can think that this change will reenable it on all platforms which is not true. Thanks, Vladimir On 6/13/13 2:42 PM, Vladimir Kozlov wrote: > On 6/13/13 3:47 AM, David Holmes wrote: >> On 13/06/2013 7:53 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I fixed the jvmg target and prepared a webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ >>> >>> Thanks for reviewing, Vladimir. >>> I need a second reviewer, please. >> >> So to clarify, this restores the old core targets but will only actually >> work on the new ports? If so do we want to validate that in >> generic_buildcore similar to the way we validate in generic_buildminimal1? > > It would be nice to have such validation but on other hand we don't have it for zero and shark, platforms which Oracle > does not support. And core will not be in our official builds or supported. > > thanks, > Vladimir > >> >> There is a huge amount of cleanup I'd like to do in this makefile to >> remove all the copy'n'paste duplication. :( >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: hotspot-dev-bounces at openjdk.java.net >>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >>> Kozlov >>> Sent: Donnerstag, 13. Juni 2013 00:58 >>> To: Volker Simonis >>> Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: JEP 175 - Review comments >>> >>> Hi, Volker >>> >>> 0001_fix_core_build.patch passed JPRT build/test run so it is good, >>> consider reviewed (assuming you fix jvmgcore). >>> >>> Should we formalize the process to follow our normal openjdk review >>> process? It will allow other people to see what is coming and to comment >>> on it as you said and I agree. >>> >>> - I will file rfes and add Volker and Goetz to watch list so you get >>> notifications (I hope) about rfes. >>> >>> - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail >>> aliases. >>> >>> - We do reviews and small testing to make sure changes do not break our >>> builds. >>> >>> - You prepare final patch with correct changeset header after we agree >>> on changes. >>> >>> - I push it to staging repo. >>> >>> Is this acceptable to you? >>> >>> About changeset header: >>> >>> : >>> Summary: >>> Reviewed-by: + >>> Contributed-by: >>> >>> I don't think you need "Contributed-by:" since Volker could be author. >>> But it is up to you if you want to mention other contributors. >>> >>> 8016476: PPC64 (part 1): reenable CORE build >>> Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 >>> Reviewed-by: kvn >>> >>> Thanks, >>> Vladimir >>> >>> PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, >>> check that you get notification. You are on watch list. >>> >>> >>> On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >>>> Okay, I will add comment to the rfe that CORE target is only used on >>>> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >>>> now). >>>> >>>> Vladimir >>>> >>>> On 6/12/13 11:51 AM, Volker Simonis wrote: >>>>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>>>> >>>>> wrote: >>>>> >>>>>> Thanks, Goetz >>>>>> >>>>>> I am perfectly fine with such granularity and I can start generating >>>>>> RFEs. >>>>>> I filed first: >>>>>> >>>>>> 8016476: PPC64 (part 1): reenable CORE build >>>>>> >>>>>> >>>>> Thanks! >>>>> >>>>> >>>>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>>>> build it >>>>>> on my Mac: >>>>>> >>>>>> >>>>> We haven't fixed the CORE build on all platforms. It should wok on >>>>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>>>> >>>>> This is the general approach we have taken. So I'm not sure what >>>>> will be >>>>> the best way for you to review the changes. But all of the patches >>>>> from the >>>>> first series of changes (1-9) won't probably do anything useful on >>>>> Linux/x86 and Solaris because we haven't fixed the CORE build and >>>>> the C++ >>>>> interpreter on that platforms. So building a CORE build or the C++ >>>>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>>>> (and was >>>>> not the scope of this project). >>>>> >>>>> I think the review for these patches should only make sure that they >>>>> don't >>>>> break anything that worked before an any supported platforms (and >>>>> trust us >>>>> that they are good for our platforms:). >>>>> >>>>> So in that sense "reenable CORE build" only means to provide the >>>>> appropriate targets in the Makefiles and not the required source code >>>>> fixes >>>>> on all platforms (although they may be trivial/minimal). But if you'd >>>>> absolutely also want to have a core build on Linux/x86 and Solaris, >>>>> I can >>>>> have a look at it. >>>>> >>>>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>>>> gnumake[2]: *** [debugcore] Error 2 >>>>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>>>> gnumake: *** [debugcore] Error 2 >>>>>> >>>>>> And on SPARC: >>>>>> >>>>>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>>>>> declaration for pd_InlineSmallCode. >>>>>> >>>>>> And you should used debugcore instead of jvmgcore: >>>>>> +all_debugcore: jvmgcore docs export_debug >>>>>> >>>>>> I want your changes be perfect from the start ;) >>>>>> >>>>> >>>>> You're right. The renaming of the 'jvmg' target to 'debug' has happened >>>>> recently ( >>>>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >>>>> >>>>> we haven't adapted it. We will fix this. >>>>> >>>>> >>>>>> And I need to discuss with our embedded group about >>>>>> 0002_PPC_defines.patch >>>>>> because it affects them. It may take time. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> yes, the plan is that each is self contained. When I set up the >>>>>>> patches I >>>>>>> built and jckecked each. When I updated them I only built them >>>>>>> selectively, >>>>>>> so there might be minor issues. I had planned to assure this once I >>>>>>> make >>>>>>> webrevs from the patches. >>>>>>> >>>>>>> Some of them might apply in any order, but others depend on previous >>>>>>> ones, >>>>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>>>> before. >>>>>>> >>>>>>> The patches work with hs25-b34. >>>>>>> >>>>>>> Please tell me if I can do anything to ease your reviewing. >>>>>>> >>>>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>>>> changes necessary to other platform code to a minimum, but also tried >>>>>>> to avoid strange workarounds. Therefore I for example did change >>>>>>> 0002 >>>>>>> renaming the PPC defines, see the comment there. >>>>>>> >>>>>>> If you agree with the granularity of the changes, it would be great >>>>>>> if you >>>>>>> could generate bug-ids for them. Maybe at least for the changes >>>>>>> up to 0016? >>>>>>> >>>>>>> Best regards >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov >>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>> ] >>>>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: >>>>>>> ppc-aix-port-dev at openjdk.java.**net; >>>>>>> >>>>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris >>>>>>> Plummer >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Thank you, Goetz. >>>>>>> >>>>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>>>> with >>>>>>> jdk8 and build? Or I should do review all 1-9 >>>>>>> patches and merge them together into jdk8 to be able build? In >>>>>>> short, is >>>>>>> each patch self-contain? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> With my recent changes I removed some of the problems Vladimir >>>>>>>> mentioned. >>>>>>>> >>>>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>>>> repository, >>>>>>>> at hotspot/ppc_patches. >>>>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>>>> hotspots >>>>>>>> can be built. >>>>>>>> >>>>>>>> The queue contains the changes proposed by me before, with minor >>>>>>>> changes >>>>>>>> due >>>>>>>> to recent development: >>>>>>>> >>>>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>>>> 101-107 C-interpreter improvements >>>>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>>>> performant ppc port. >>>>>>>> Altogether currently 49 changes. >>>>>>>> >>>>>>>> Our plan was to propose the changes in the order of the queue for >>>>>>>> review. I'm happy to create webrevs for any of them. >>>>>>>> >>>>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>>>> changes >>>>>>>> are more complete. They include all later improvements by fixes or >>>>>>>> adaptions in merge changes. >>>>>>>> For why and where I renamed PPC to PPC32 see the second change in >>>>>>>> the >>>>>>>> queue. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> PS: This can be used as the invokedynamic repository: >>>>>>>> hg clone >>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>>>>> >>>>>>>> ppc-hotspot >>>>>>>> hg clone >>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cd stage-hotspot >>>>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>>>> hg qpush -a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov >>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>> ] >>>>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>> >>>>>>>> Here is result of my first attempt to build/test ppc changes >>>>>>>> together >>>>>>>> with our closed sources. >>>>>>>> >>>>>>>> Small problems: >>>>>>>> >>>>>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>>>>> >>>>>>>> Build on MacOS: >>>>>>>> >>>>>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>>>> >>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>>>>> UNSUPPORTED_ARCH >>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>>>>> UNSUPPORTED_ARCH >>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>>>>> UNSUPPORTED_ARCH >>>>>>>> >>>>>>>> >>>>>>>> We have several conflict with closed sources builds: >>>>>>>> >>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function >>>>>>>> 'bool >>>>>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>>>>> between >>>>>>>> signed and unsigned integer expressions >>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>>>>> between >>>>>>>> signed and unsigned integer expressions >>>>>>>> >>>>>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>>>>> member function declared in class 'frame' >>>>>>>> >>>>>>>> error: no matching function for call to >>>>>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>>>>> uint&)' >>>>>>>> >>>>>>>> I think it is due to changes like next: >>>>>>>> >>>>>>>> -#ifdef PPC >>>>>>>> +#ifdef PPC32 >>>>>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>>>>> >>>>>>>> >>>>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>>>> our >>>>>>>> side: >>>>>>>> >>>>>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>>>>> 'static >>>>>>>> void MethodHandles::generate_**adapters()': >>>>>>>> src/share/vm/prims/**methodHandles.cpp:68: error: >>>>>>>> 'adapter_code_size' >>>>>>>> cannot be used as a function >>>>>>>> src/share/vm/prims/**methodHandles.cpp:70: error: >>>>>>>> 'adapter_code_size' >>>>>>>> cannot be used as a function >>>>>>>> >>>>>>>> >>>>>>>> I would suggest to do such shared changes which affects different >>>>>>>> builds >>>>>>>> later after initial push. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>>>> tested it successfully. In case you experience any problems >>>>>>>>> please tell me the details so I can fix them. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Vladimir Kozlov >>>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>>> ] >>>>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>>>> To: Simonis, Volker >>>>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; >>>>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>>>> Bateman >>>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Volker, >>>>>>>>> >>>>>>>>> Can you or someone update >>>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>>>>> >>>>>>>>> match latest >>>>>>>>> sources in >>>>>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>>>>> >>>>>>>>> >>>>>>>>> ? >>>>>>>>> I just tried to merge them and build Hotspot on x86 without >>>>>>>>> success. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> We intentionally used 'porters-dev' rather >>>>>>>>>> than'ppc-aix-port-dev' in >>>>>>>>>> the >>>>>>>>>> beginning to address a broader audience for the initial >>>>>>>>>> discussions. >>>>>>>>>> >>>>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>> ------------ >>>>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>>> Ellison; >>>>>>>>>> iris.clark at oracle.com >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, Volker. >>>>>>>>>> >>>>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>>>> >>>>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>>>> to be >>>>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>>>> listed >>>>>>>>>> as porters-dev. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> iris >>>>>>>>>> >>>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>>> Ellison >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi Iris, >>>>>>>>>> >>>>>>>>>> you're right, the title is too clumsy - I just couldn't come up >>>>>>>>>> with >>>>>>>>>> something better yesterday in the evening. >>>>>>>>>> >>>>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll >>>>>>>>>> take >>>>>>>>>> it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>> ; Tim Ellison >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>>>> >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, Volker. >>>>>>>>>> >>>>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>>>> >>>>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK >>>>>>>>>> master >>>>>>>>>> repositories" in the revised title is not ideal: >>>>>>>>>> >>>>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>>>> >>>>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>>>> >>>>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>>>> >>>>>>>>>> JEP: 175 >>>>>>>>>> >>>>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>>> >>>>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>>>> repositories >>>>>>>>>> >>>>>>>>>> Author: Volker Simonis >>>>>>>>>> >>>>>>>>>> Organization: SAP AG >>>>>>>>>> >>>>>>>>>> Created: 2013/1/11 >>>>>>>>>> >>>>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs >>>>>>>>>> are all >>>>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>>>> Unicode >>>>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself >>>>>>>>>> contains >>>>>>>>>> additional details. >>>>>>>>>> >>>>>>>>>> Perhaps others have suggestions? >>>>>>>>>> >>>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>>> still be >>>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>>> be set >>>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>>> specified in the JEP specification)? >>>>>>>>>> >>>>>>>>>> Yes. Once that field is populated, the value will appear in >>>>>>>>>> the JEP >>>>>>>>>> index [1], see the third column. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Iris >>>>>>>>>> >>>>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>>>> >>>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>> ; Tim Ellison >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>>>> find >>>>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>>>> version >>>>>>>>>> in until now to give everybody a chance to comment on the >>>>>>>>>> changes). >>>>>>>>>> >>>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>>> still be >>>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>>> be set >>>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>>> specified in the JEP specification)? >>>>>>>>>> >>>>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>>>> contents of >>>>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>>>> "Description" >>>>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>>>> Port >>>>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>>>> Space" [3] >>>>>>>>>> to the JEP. >>>>>>>>>> >>>>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>>>> to hold >>>>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>>>> >>>>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>>>> rights to >>>>>>>>>> that page? >>>>>>>>>> >>>>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>>>> "PPCAIX >>>>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>>>> saw that >>>>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>>>> and in >>>>>>>>>> my unlimited naivety I imagine this could be a simple >>>>>>>>>> copy-and-paste >>>>>>>>>> operation:) If that doesn't work so easily, please let me know >>>>>>>>>> how I >>>>>>>>>> could help. >>>>>>>>>> >>>>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>>>> the JEP >>>>>>>>>> tomorrow after our telephone call. >>>>>>>>>> >>>>>>>>>> Thank you and best regards, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> [2]: >>>>>>>>>> https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>>>>> 13729959 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [3]: >>>>>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>> ; Tim Ellison >>>>>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>>>>> Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, Volker. >>>>>>>>>> >>>>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>>> >>>>>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>>>> comments: >>>>>>>>>> >>>>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>>>> >>>>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>>>> it is >>>>>>>>>> only covering PPC/AIX. >>>>>>>>>> >>>>>>>>>> -Recommend that the second Motivation bullet be modified to >>>>>>>>>> make it >>>>>>>>>> clear that it applies to Hotspot only. >>>>>>>>>> >>>>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>>>> >>>>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>>>> up to >>>>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>>>> line. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Iris Clark >>>>>>>>>> >>>>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>>>> >>>>>>>>>> From goetz.lindenmaier at sap.com Fri Jun 14 00:49:38 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 14 Jun 2013 07:49:38 +0000 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: <51BABA10.50805@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> <51B9A34F.8080702@oracle.com> <51BA3CC9.8040100@oracle.com> <51BABA10.50805@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFE58F9@DEWDFEMB12A.global.corp.sap> Hi, I updated the webrev accordingly. I'm checking for "ppc" and "64" now. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, June 14, 2013 8:37 AM To: David Holmes; Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8016476: PPC64 (part 1): reenable CORE build Hi, Goetz I talked with David and we want you to add OS checks as generic_buildminimal1 does to avoid a confusion in future if someone (as I did) try to build CORE on other platforms. CORE was one of our supported builds and someone can think that this change will reenable it on all platforms which is not true. Thanks, Vladimir On 6/13/13 2:42 PM, Vladimir Kozlov wrote: > On 6/13/13 3:47 AM, David Holmes wrote: >> On 13/06/2013 7:53 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I fixed the jvmg target and prepared a webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ >>> >>> Thanks for reviewing, Vladimir. >>> I need a second reviewer, please. >> >> So to clarify, this restores the old core targets but will only actually >> work on the new ports? If so do we want to validate that in >> generic_buildcore similar to the way we validate in generic_buildminimal1? > > It would be nice to have such validation but on other hand we don't have it for zero and shark, platforms which Oracle > does not support. And core will not be in our official builds or supported. > > thanks, > Vladimir > >> >> There is a huge amount of cleanup I'd like to do in this makefile to >> remove all the copy'n'paste duplication. :( >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: hotspot-dev-bounces at openjdk.java.net >>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >>> Kozlov >>> Sent: Donnerstag, 13. Juni 2013 00:58 >>> To: Volker Simonis >>> Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: JEP 175 - Review comments >>> >>> Hi, Volker >>> >>> 0001_fix_core_build.patch passed JPRT build/test run so it is good, >>> consider reviewed (assuming you fix jvmgcore). >>> >>> Should we formalize the process to follow our normal openjdk review >>> process? It will allow other people to see what is coming and to comment >>> on it as you said and I agree. >>> >>> - I will file rfes and add Volker and Goetz to watch list so you get >>> notifications (I hope) about rfes. >>> >>> - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail >>> aliases. >>> >>> - We do reviews and small testing to make sure changes do not break our >>> builds. >>> >>> - You prepare final patch with correct changeset header after we agree >>> on changes. >>> >>> - I push it to staging repo. >>> >>> Is this acceptable to you? >>> >>> About changeset header: >>> >>> : >>> Summary: >>> Reviewed-by: + >>> Contributed-by: >>> >>> I don't think you need "Contributed-by:" since Volker could be author. >>> But it is up to you if you want to mention other contributors. >>> >>> 8016476: PPC64 (part 1): reenable CORE build >>> Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 >>> Reviewed-by: kvn >>> >>> Thanks, >>> Vladimir >>> >>> PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, >>> check that you get notification. You are on watch list. >>> >>> >>> On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >>>> Okay, I will add comment to the rfe that CORE target is only used on >>>> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >>>> now). >>>> >>>> Vladimir >>>> >>>> On 6/12/13 11:51 AM, Volker Simonis wrote: >>>>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>>>> >>>>> wrote: >>>>> >>>>>> Thanks, Goetz >>>>>> >>>>>> I am perfectly fine with such granularity and I can start generating >>>>>> RFEs. >>>>>> I filed first: >>>>>> >>>>>> 8016476: PPC64 (part 1): reenable CORE build >>>>>> >>>>>> >>>>> Thanks! >>>>> >>>>> >>>>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>>>> build it >>>>>> on my Mac: >>>>>> >>>>>> >>>>> We haven't fixed the CORE build on all platforms. It should wok on >>>>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>>>> >>>>> This is the general approach we have taken. So I'm not sure what >>>>> will be >>>>> the best way for you to review the changes. But all of the patches >>>>> from the >>>>> first series of changes (1-9) won't probably do anything useful on >>>>> Linux/x86 and Solaris because we haven't fixed the CORE build and >>>>> the C++ >>>>> interpreter on that platforms. So building a CORE build or the C++ >>>>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>>>> (and was >>>>> not the scope of this project). >>>>> >>>>> I think the review for these patches should only make sure that they >>>>> don't >>>>> break anything that worked before an any supported platforms (and >>>>> trust us >>>>> that they are good for our platforms:). >>>>> >>>>> So in that sense "reenable CORE build" only means to provide the >>>>> appropriate targets in the Makefiles and not the required source code >>>>> fixes >>>>> on all platforms (although they may be trivial/minimal). But if you'd >>>>> absolutely also want to have a core build on Linux/x86 and Solaris, >>>>> I can >>>>> have a look at it. >>>>> >>>>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>>>> gnumake[2]: *** [debugcore] Error 2 >>>>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>>>> gnumake: *** [debugcore] Error 2 >>>>>> >>>>>> And on SPARC: >>>>>> >>>>>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>>>>> declaration for pd_InlineSmallCode. >>>>>> >>>>>> And you should used debugcore instead of jvmgcore: >>>>>> +all_debugcore: jvmgcore docs export_debug >>>>>> >>>>>> I want your changes be perfect from the start ;) >>>>>> >>>>> >>>>> You're right. The renaming of the 'jvmg' target to 'debug' has happened >>>>> recently ( >>>>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >>>>> >>>>> we haven't adapted it. We will fix this. >>>>> >>>>> >>>>>> And I need to discuss with our embedded group about >>>>>> 0002_PPC_defines.patch >>>>>> because it affects them. It may take time. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> yes, the plan is that each is self contained. When I set up the >>>>>>> patches I >>>>>>> built and jckecked each. When I updated them I only built them >>>>>>> selectively, >>>>>>> so there might be minor issues. I had planned to assure this once I >>>>>>> make >>>>>>> webrevs from the patches. >>>>>>> >>>>>>> Some of them might apply in any order, but others depend on previous >>>>>>> ones, >>>>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>>>> before. >>>>>>> >>>>>>> The patches work with hs25-b34. >>>>>>> >>>>>>> Please tell me if I can do anything to ease your reviewing. >>>>>>> >>>>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>>>> changes necessary to other platform code to a minimum, but also tried >>>>>>> to avoid strange workarounds. Therefore I for example did change >>>>>>> 0002 >>>>>>> renaming the PPC defines, see the comment there. >>>>>>> >>>>>>> If you agree with the granularity of the changes, it would be great >>>>>>> if you >>>>>>> could generate bug-ids for them. Maybe at least for the changes >>>>>>> up to 0016? >>>>>>> >>>>>>> Best regards >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov >>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>> ] >>>>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: >>>>>>> ppc-aix-port-dev at openjdk.java.**net; >>>>>>> >>>>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris >>>>>>> Plummer >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Thank you, Goetz. >>>>>>> >>>>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>>>> with >>>>>>> jdk8 and build? Or I should do review all 1-9 >>>>>>> patches and merge them together into jdk8 to be able build? In >>>>>>> short, is >>>>>>> each patch self-contain? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> With my recent changes I removed some of the problems Vladimir >>>>>>>> mentioned. >>>>>>>> >>>>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>>>> repository, >>>>>>>> at hotspot/ppc_patches. >>>>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>>>> hotspots >>>>>>>> can be built. >>>>>>>> >>>>>>>> The queue contains the changes proposed by me before, with minor >>>>>>>> changes >>>>>>>> due >>>>>>>> to recent development: >>>>>>>> >>>>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>>>> 101-107 C-interpreter improvements >>>>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>>>> performant ppc port. >>>>>>>> Altogether currently 49 changes. >>>>>>>> >>>>>>>> Our plan was to propose the changes in the order of the queue for >>>>>>>> review. I'm happy to create webrevs for any of them. >>>>>>>> >>>>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>>>> changes >>>>>>>> are more complete. They include all later improvements by fixes or >>>>>>>> adaptions in merge changes. >>>>>>>> For why and where I renamed PPC to PPC32 see the second change in >>>>>>>> the >>>>>>>> queue. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> PS: This can be used as the invokedynamic repository: >>>>>>>> hg clone >>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>>>>> >>>>>>>> ppc-hotspot >>>>>>>> hg clone >>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cd stage-hotspot >>>>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>>>> hg qpush -a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov >>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>> ] >>>>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>> >>>>>>>> Here is result of my first attempt to build/test ppc changes >>>>>>>> together >>>>>>>> with our closed sources. >>>>>>>> >>>>>>>> Small problems: >>>>>>>> >>>>>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>>>>> >>>>>>>> Build on MacOS: >>>>>>>> >>>>>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>>>> >>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>>>>> UNSUPPORTED_ARCH >>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>>>>> UNSUPPORTED_ARCH >>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>>>>> UNSUPPORTED_ARCH >>>>>>>> >>>>>>>> >>>>>>>> We have several conflict with closed sources builds: >>>>>>>> >>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function >>>>>>>> 'bool >>>>>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>>>>> between >>>>>>>> signed and unsigned integer expressions >>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>>>>> between >>>>>>>> signed and unsigned integer expressions >>>>>>>> >>>>>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>>>>> member function declared in class 'frame' >>>>>>>> >>>>>>>> error: no matching function for call to >>>>>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>>>>> uint&)' >>>>>>>> >>>>>>>> I think it is due to changes like next: >>>>>>>> >>>>>>>> -#ifdef PPC >>>>>>>> +#ifdef PPC32 >>>>>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>>>>> >>>>>>>> >>>>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>>>> our >>>>>>>> side: >>>>>>>> >>>>>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>>>>> 'static >>>>>>>> void MethodHandles::generate_**adapters()': >>>>>>>> src/share/vm/prims/**methodHandles.cpp:68: error: >>>>>>>> 'adapter_code_size' >>>>>>>> cannot be used as a function >>>>>>>> src/share/vm/prims/**methodHandles.cpp:70: error: >>>>>>>> 'adapter_code_size' >>>>>>>> cannot be used as a function >>>>>>>> >>>>>>>> >>>>>>>> I would suggest to do such shared changes which affects different >>>>>>>> builds >>>>>>>> later after initial push. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>>>> tested it successfully. In case you experience any problems >>>>>>>>> please tell me the details so I can fix them. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Vladimir Kozlov >>>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>>> ] >>>>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>>>> To: Simonis, Volker >>>>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; >>>>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>>>> Bateman >>>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Volker, >>>>>>>>> >>>>>>>>> Can you or someone update >>>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>>>>> >>>>>>>>> match latest >>>>>>>>> sources in >>>>>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>>>>> >>>>>>>>> >>>>>>>>> ? >>>>>>>>> I just tried to merge them and build Hotspot on x86 without >>>>>>>>> success. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> We intentionally used 'porters-dev' rather >>>>>>>>>> than'ppc-aix-port-dev' in >>>>>>>>>> the >>>>>>>>>> beginning to address a broader audience for the initial >>>>>>>>>> discussions. >>>>>>>>>> >>>>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>> ------------ >>>>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>>> Ellison; >>>>>>>>>> iris.clark at oracle.com >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, Volker. >>>>>>>>>> >>>>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>>>> >>>>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>>>> to be >>>>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>>>> listed >>>>>>>>>> as porters-dev. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> iris >>>>>>>>>> >>>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>>> Ellison >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi Iris, >>>>>>>>>> >>>>>>>>>> you're right, the title is too clumsy - I just couldn't come up >>>>>>>>>> with >>>>>>>>>> something better yesterday in the evening. >>>>>>>>>> >>>>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll >>>>>>>>>> take >>>>>>>>>> it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>> ; Tim Ellison >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>>>> >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, Volker. >>>>>>>>>> >>>>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>>>> >>>>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK >>>>>>>>>> master >>>>>>>>>> repositories" in the revised title is not ideal: >>>>>>>>>> >>>>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>>>> >>>>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>>>> >>>>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>>>> >>>>>>>>>> JEP: 175 >>>>>>>>>> >>>>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>>> >>>>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>>>> repositories >>>>>>>>>> >>>>>>>>>> Author: Volker Simonis >>>>>>>>>> >>>>>>>>>> Organization: SAP AG >>>>>>>>>> >>>>>>>>>> Created: 2013/1/11 >>>>>>>>>> >>>>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs >>>>>>>>>> are all >>>>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>>>> Unicode >>>>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself >>>>>>>>>> contains >>>>>>>>>> additional details. >>>>>>>>>> >>>>>>>>>> Perhaps others have suggestions? >>>>>>>>>> >>>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>>> still be >>>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>>> be set >>>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>>> specified in the JEP specification)? >>>>>>>>>> >>>>>>>>>> Yes. Once that field is populated, the value will appear in >>>>>>>>>> the JEP >>>>>>>>>> index [1], see the third column. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Iris >>>>>>>>>> >>>>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>>>> >>>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>> ; Tim Ellison >>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>>>> find >>>>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>>>> version >>>>>>>>>> in until now to give everybody a chance to comment on the >>>>>>>>>> changes). >>>>>>>>>> >>>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>>> still be >>>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>>> be set >>>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>>> specified in the JEP specification)? >>>>>>>>>> >>>>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>>>> contents of >>>>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>>>> "Description" >>>>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>>>> Port >>>>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>>>> Space" [3] >>>>>>>>>> to the JEP. >>>>>>>>>> >>>>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>>>> to hold >>>>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>>>> >>>>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>>>> rights to >>>>>>>>>> that page? >>>>>>>>>> >>>>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>>>> "PPCAIX >>>>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>>>> saw that >>>>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>>>> and in >>>>>>>>>> my unlimited naivety I imagine this could be a simple >>>>>>>>>> copy-and-paste >>>>>>>>>> operation:) If that doesn't work so easily, please let me know >>>>>>>>>> how I >>>>>>>>>> could help. >>>>>>>>>> >>>>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>>>> the JEP >>>>>>>>>> tomorrow after our telephone call. >>>>>>>>>> >>>>>>>>>> Thank you and best regards, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> [2]: >>>>>>>>>> https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>>>>> 13729959 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [3]: >>>>>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>>>> Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>> ; Tim Ellison >>>>>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>>>>> Bateman; Vladimir Kozlov >>>>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Hi, Volker. >>>>>>>>>> >>>>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>>> >>>>>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>>>> comments: >>>>>>>>>> >>>>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>>>> >>>>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>>>> it is >>>>>>>>>> only covering PPC/AIX. >>>>>>>>>> >>>>>>>>>> -Recommend that the second Motivation bullet be modified to >>>>>>>>>> make it >>>>>>>>>> clear that it applies to Hotspot only. >>>>>>>>>> >>>>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>>>> >>>>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>>>> up to >>>>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>>>> line. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Iris Clark >>>>>>>>>> >>>>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>>>> >>>>>>>>>> From staffan.larsen at oracle.com Fri Jun 14 02:11:15 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 14 Jun 2013 11:11:15 +0200 Subject: Review Request (S) 6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description In-Reply-To: <51BA2124.6060809@oracle.com> References: <51BA2124.6060809@oracle.com> Message-ID: <4EBDFAC1-541F-4907-BA2A-EF1A8A68123D@oracle.com> Looks good. /Staffan On 13 jun 2013, at 21:44, serguei.spitsyn at oracle.com wrote: > Please, review a 1-line JVMTI doc fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=6493116 > jbs: https://jbs.oracle.com/bugs/browse/JDK-6493116 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/6493116-JVMTI-DOC.1 > > Summary: > A typo in the parameter spelling, a bound update missed when the parameter was renamed > > > Testing: Manual build of the JVMTI docs > > Thanks, > Serguei From thomas.schatzl at oracle.com Fri Jun 14 05:27:02 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 14 Jun 2013 14:27:02 +0200 Subject: RFR (S): 8016556: G1: Use ArrayAllocator for BitMaps In-Reply-To: <51B9DCEC.6050906@oracle.com> References: <51B9DCEC.6050906@oracle.com> Message-ID: <1371212822.2690.26.camel@cirrus> [added the CR number in the subject line] Hi, On Thu, 2013-06-13 at 16:53 +0200, Bengt Rutisson wrote: > Hi everyone, > > Could I have a couple of review for this small change? > http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ > Looks good. A few minor comments which are free to ignore: - the code in the ArrayAllocator constructor/destructor is now more than a line. Some additional spacing between them may help readability. > One complication with the fix is that the BitMap data structures get > copied around quite a bit. The copies are shallow copies, so we don't > risk re-doing the allocation. But since I am now embedding an > ArrayAllocator in the BitMap structure the destructor for copies of the > ArrayAllocator gets called every now and then. The BitMap explicitly > frees up the allocated memory when it thinks it is necessary. So, rather > than trying to refactor the code to avoid copying I made it optional to > free the allocated memory in the ArrayAllocator desctructor. - instead of the "free_in_destructor" name I would prefer something like "owner"; but this is really just my personal opinion. > I do think it would be good to review the BitMap code. It seems a bit > fishy that we pass around shallow copies. But I think my current change > keeps the same behavior as before. I agree about both things :) Thanks, Thomas From volker.simonis at gmail.com Fri Jun 14 05:36:54 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 14 Jun 2013 14:36:54 +0200 Subject: hg: hsx/hsx24/hotspot: 2 new changesets In-Reply-To: <20130521210556.E193348C1A@hg.openjdk.java.net> References: <20130521210556.E193348C1A@hg.openjdk.java.net> Message-ID: Hi Erik, could you please explain how it could happen that this change has been pushed two times? http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=8011891 It seems that, even if not wrong, the code is now at least not optimal, because save_heap_summary() will now be called two times. Thank you and best regards, Volker Changeset: c78ea7137c06 Author: ehelin Date: 2013-05-17 15:28 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c78ea7137c06 8011891: The vm/gc/heap/heap_summary_after_gc event for CMS contains old data Reviewed-by: brutisso, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 3e38b7096830 Author: ehelin Date: 2013-05-20 14:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3e38b7096830 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp On Tue, May 21, 2013 at 11:05 PM, wrote: > Changeset: 97eb1ea6bae8 > Author: ehelin > Date: 2013-05-21 20:29 +0200 > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/97eb1ea6bae8 > > 8011891: The vm/gc/heap/heap_summary_after_gc event for CMS contains old > data > Reviewed-by: brutisso, stefank > > ! > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > Changeset: cea88a661227 > Author: ehelin > Date: 2013-05-21 20:46 +0200 > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cea88a661227 > > Merge > > > From bengt.rutisson at oracle.com Fri Jun 14 06:03:24 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 14 Jun 2013 15:03:24 +0200 Subject: RFR (S): 8016556: G1: Use ArrayAllocator for BitMaps In-Reply-To: <1371212822.2690.26.camel@cirrus> References: <51B9DCEC.6050906@oracle.com> <1371212822.2690.26.camel@cirrus> Message-ID: <51BB149C.5060305@oracle.com> Hi Thomas, On 6/14/13 2:27 PM, Thomas Schatzl wrote: > [added the CR number in the subject line] Thanks! :) > > Hi, > > On Thu, 2013-06-13 at 16:53 +0200, Bengt Rutisson wrote: >> Hi everyone, >> >> Could I have a couple of review for this small change? >> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >> > Looks good. Thanks for looking at this! > > A few minor comments which are free to ignore: > > - the code in the ArrayAllocator constructor/destructor is now more than > a line. Some additional spacing between them may help readability. Good point. Added the line breaks. > >> One complication with the fix is that the BitMap data structures get >> copied around quite a bit. The copies are shallow copies, so we don't >> risk re-doing the allocation. But since I am now embedding an >> ArrayAllocator in the BitMap structure the destructor for copies of the >> ArrayAllocator gets called every now and then. The BitMap explicitly >> frees up the allocated memory when it thinks it is necessary. So, rather >> than trying to refactor the code to avoid copying I made it optional to >> free the allocated memory in the ArrayAllocator desctructor. > - instead of the "free_in_destructor" name I would prefer something like > "owner"; but this is really just my personal opinion. I see your point, but I actually prefer "free_in_destructor". To me "owner" suggests a bit too much responsibility. With the current implementation it is the BitMap that will own the memory and is responsible for calling free() on the ArrayAllocator. I'm open for a better name than "free_in_destructor" but I can't really come up with one. > >> I do think it would be good to review the BitMap code. It seems a bit >> fishy that we pass around shallow copies. But I think my current change >> keeps the same behavior as before. > I agree about both things :) :) Thanks again for looking at this! Bengt > > Thanks, > Thomas > > From erik.helin at oracle.com Fri Jun 14 06:36:35 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 14 Jun 2013 15:36:35 +0200 Subject: hg: hsx/hsx24/hotspot: 2 new changesets In-Reply-To: References: <20130521210556.E193348C1A@hg.openjdk.java.net> Message-ID: <20130614133635.GC2023@ehelin-thinkpad> Hi Volker, On 2013-06-14, Volker Simonis wrote: > Hi Erik, > > could you please explain how it could happen that this change has been > pushed two times? it looks like I pushed this change twice. There is nothing preventing us from pushing the same change twice and I must have made a mistake. In most cases, the merge that mercurial automatically does would not be successful. However, in this case the second merge, changeset cea88a661227, unfortunately succeeds even though the first push has already been done. Thanks for finding this! On 2013-06-14, Volker Simonis wrote: > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=8011891 > > It seems that, even if not wrong, the code is now at least not optimal, > because save_heap_summary() will now be called two times. You are correct. The extra call to save_heap_summary will not cause any correctness problems but will, of course, make CMS slower. I will create a patch and send it out for review on hotspot-gc-dev at openjdk.java.net that removes the extra, unnecessary, if statement. Again, thank you for finding this! Erik > Thank you and best regards, > Volker > > > Changeset: c78ea7137c06 > Author: ehelin > Date: 2013-05-17 15:28 +0200 > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c78ea7137c06 > > 8011891: The vm/gc/heap/heap_summary_after_gc event for CMS contains old > data > Reviewed-by: brutisso, stefank > > ! > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > Changeset: 3e38b7096830 > Author: ehelin > Date: 2013-05-20 14:18 +0200 > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3e38b7096830 > > Merge > > ! > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > > On Tue, May 21, 2013 at 11:05 PM, wrote: > > > Changeset: 97eb1ea6bae8 > > Author: ehelin > > Date: 2013-05-21 20:29 +0200 > > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/97eb1ea6bae8 > > > > 8011891: The vm/gc/heap/heap_summary_after_gc event for CMS contains old > > data > > Reviewed-by: brutisso, stefank > > > > ! > > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > > > Changeset: cea88a661227 > > Author: ehelin > > Date: 2013-05-21 20:46 +0200 > > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cea88a661227 > > > > Merge > > > > > > From volker.simonis at gmail.com Fri Jun 14 07:10:06 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 14 Jun 2013 16:10:06 +0200 Subject: hg: hsx/hsx24/hotspot: 2 new changesets In-Reply-To: <20130614133635.GC2023@ehelin-thinkpad> References: <20130521210556.E193348C1A@hg.openjdk.java.net> <20130614133635.GC2023@ehelin-thinkpad> Message-ID: I never found it a good idea to allow duplicate bug ids in the hsxXX repositories but others argued that it is necassary to allow them because of the way the repo is branched and how changes are integrated from different open and closed repositories into it. I think this mistake could not have happened in the hotspot-main repo because it checks for a valid bug ids. Regards, Volker On Fri, Jun 14, 2013 at 3:36 PM, Erik Helin wrote: > Hi Volker, > > On 2013-06-14, Volker Simonis wrote: > > Hi Erik, > > > > could you please explain how it could happen that this change has been > > pushed two times? > > it looks like I pushed this change twice. There is nothing preventing us > from pushing the same change twice and I must have made a mistake. In > most cases, the merge that mercurial automatically does would not be > successful. However, in this case the second merge, changeset > cea88a661227, unfortunately succeeds even though the first push has > already been done. > > Thanks for finding this! > > On 2013-06-14, Volker Simonis wrote: > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=8011891 > > > > It seems that, even if not wrong, the code is now at least not optimal, > > because save_heap_summary() will now be called two times. > > You are correct. The extra call to save_heap_summary will not cause any > correctness problems but will, of course, make CMS slower. > > I will create a patch and send it out for review on > hotspot-gc-dev at openjdk.java.net that removes the extra, unnecessary, if > statement. > > Again, thank you for finding this! > > Erik > > > Thank you and best regards, > > Volker > > > > > > Changeset: c78ea7137c06 > > Author: ehelin > > Date: 2013-05-17 15:28 +0200 > > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c78ea7137c06 > > > > 8011891: The vm/gc/heap/heap_summary_after_gc event for CMS contains old > > data > > Reviewed-by: brutisso, stefank > > > > ! > > > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > > > Changeset: 3e38b7096830 > > Author: ehelin > > Date: 2013-05-20 14:18 +0200 > > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3e38b7096830 > > > > Merge > > > > ! > > > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > > > > > On Tue, May 21, 2013 at 11:05 PM, wrote: > > > > > Changeset: 97eb1ea6bae8 > > > Author: ehelin > > > Date: 2013-05-21 20:29 +0200 > > > URL: > http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/97eb1ea6bae8 > > > > > > 8011891: The vm/gc/heap/heap_summary_after_gc event for CMS contains > old > > > data > > > Reviewed-by: brutisso, stefank > > > > > > ! > > > > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > > > > > Changeset: cea88a661227 > > > Author: ehelin > > > Date: 2013-05-21 20:46 +0200 > > > URL: > http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cea88a661227 > > > > > > Merge > > > > > > > > > > From vladimir.kozlov at oracle.com Fri Jun 14 08:57:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Jun 2013 08:57:48 -0700 Subject: RFR(S): 8016476: PPC64 (part 1): reenable CORE build In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE58F9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFDB808@DEWDFEMB12A.global.corp.sap> <51B9A34F.8080702@oracle.com> <51BA3CC9.8040100@oracle.com> <51BABA10.50805@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE58F9@DEWDFEMB12A.global.corp.sap> Message-ID: <51BB3D7C.1080205@oracle.com> This looks good. Albert tested it and I think it is ready to push. Thanks, Vladimir On 6/14/13 12:49 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev accordingly. > I'm checking for "ppc" and "64" now. > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, June 14, 2013 8:37 AM > To: David Holmes; Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8016476: PPC64 (part 1): reenable CORE build > > Hi, Goetz > > I talked with David and we want you to add OS checks as generic_buildminimal1 does to avoid a confusion in future if > someone (as I did) try to build CORE on other platforms. CORE was one of our supported builds and someone can think that > this change will reenable it on all platforms which is not true. > > Thanks, > Vladimir > > On 6/13/13 2:42 PM, Vladimir Kozlov wrote: >> On 6/13/13 3:47 AM, David Holmes wrote: >>> On 13/06/2013 7:53 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I fixed the jvmg target and prepared a webrev: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8016476-CORE/ >>>> >>>> Thanks for reviewing, Vladimir. >>>> I need a second reviewer, please. >>> >>> So to clarify, this restores the old core targets but will only actually >>> work on the new ports? If so do we want to validate that in >>> generic_buildcore similar to the way we validate in generic_buildminimal1? >> >> It would be nice to have such validation but on other hand we don't have it for zero and shark, platforms which Oracle >> does not support. And core will not be in our official builds or supported. >> >> thanks, >> Vladimir >> >>> >>> There is a huge amount of cleanup I'd like to do in this makefile to >>> remove all the copy'n'paste duplication. :( >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: hotspot-dev-bounces at openjdk.java.net >>>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >>>> Kozlov >>>> Sent: Donnerstag, 13. Juni 2013 00:58 >>>> To: Volker Simonis >>>> Cc: ppc-aix-port-dev at openjdk.java.net; Chris Plummer; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Hi, Volker >>>> >>>> 0001_fix_core_build.patch passed JPRT build/test run so it is good, >>>> consider reviewed (assuming you fix jvmgcore). >>>> >>>> Should we formalize the process to follow our normal openjdk review >>>> process? It will allow other people to see what is coming and to comment >>>> on it as you said and I agree. >>>> >>>> - I will file rfes and add Volker and Goetz to watch list so you get >>>> notifications (I hope) about rfes. >>>> >>>> - You submit webrev for reviews to ppc-aix-port-dev, hotspot-dev mail >>>> aliases. >>>> >>>> - We do reviews and small testing to make sure changes do not break our >>>> builds. >>>> >>>> - You prepare final patch with correct changeset header after we agree >>>> on changes. >>>> >>>> - I push it to staging repo. >>>> >>>> Is this acceptable to you? >>>> >>>> About changeset header: >>>> >>>> : >>>> Summary: >>>> Reviewed-by: + >>>> Contributed-by: >>>> >>>> I don't think you need "Contributed-by:" since Volker could be author. >>>> But it is up to you if you want to mention other contributors. >>>> >>>> 8016476: PPC64 (part 1): reenable CORE build >>>> Summary: reenable CORE build for Linux/PPC64 and AIX/PPC64 >>>> Reviewed-by: kvn >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> PS: I filed next bug: PPC64 (part 2): Clean up PPC defines. Please, >>>> check that you get notification. You are on watch list. >>>> >>>> >>>> On 6/12/13 12:18 PM, Vladimir Kozlov wrote: >>>>> Okay, I will add comment to the rfe that CORE target is only used on >>>>> Linux/PPC64 and AIX/PPC64 and Oracle will not support it (at least for >>>>> now). >>>>> >>>>> Vladimir >>>>> >>>>> On 6/12/13 11:51 AM, Volker Simonis wrote: >>>>>> On Wed, Jun 12, 2013 at 7:18 PM, Vladimir Kozlov >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Thanks, Goetz >>>>>>> >>>>>>> I am perfectly fine with such granularity and I can start generating >>>>>>> RFEs. >>>>>>> I filed first: >>>>>>> >>>>>>> 8016476: PPC64 (part 1): reenable CORE build >>>>>>> >>>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>>> Are you sure that 0001_fix_core_build.patch is complete? I can't >>>>>>> build it >>>>>>> on my Mac: >>>>>>> >>>>>>> >>>>>> We haven't fixed the CORE build on all platforms. It should wok on >>>>>> Linux/PPC64 and AIX/PPC64 and not break anything else. >>>>>> >>>>>> This is the general approach we have taken. So I'm not sure what >>>>>> will be >>>>>> the best way for you to review the changes. But all of the patches >>>>>> from the >>>>>> first series of changes (1-9) won't probably do anything useful on >>>>>> Linux/x86 and Solaris because we haven't fixed the CORE build and >>>>>> the C++ >>>>>> interpreter on that platforms. So building a CORE build or the C++ >>>>>> interpreter on Linux/x86, Solaris or Mac will probably not succeed >>>>>> (and was >>>>>> not the scope of this project). >>>>>> >>>>>> I think the review for these patches should only make sure that they >>>>>> don't >>>>>> break anything that worked before an any supported platforms (and >>>>>> trust us >>>>>> that they are good for our platforms:). >>>>>> >>>>>> So in that sense "reenable CORE build" only means to provide the >>>>>> appropriate targets in the Makefiles and not the required source code >>>>>> fixes >>>>>> on all platforms (although they may be trivial/minimal). But if you'd >>>>>> absolutely also want to have a core build on Linux/x86 and Solaris, >>>>>> I can >>>>>> have a look at it. >>>>>> >>>>>> gnumake[4]: *** No rule to make target `dtrace_stuff'. Stop. >>>>>>> gnumake[3]: *** [dtrace_stuff] Error 2 >>>>>>> gnumake[2]: *** [debugcore] Error 2 >>>>>>> gnumake[1]: *** [generic_buildcore] Error 2 >>>>>>> gnumake: *** [debugcore] Error 2 >>>>>>> >>>>>>> And on SPARC: >>>>>>> >>>>>>> src/share/vm/runtime/globals.**hpp", line 170: Error: Multiple >>>>>>> declaration for pd_InlineSmallCode. >>>>>>> >>>>>>> And you should used debugcore instead of jvmgcore: >>>>>>> +all_debugcore: jvmgcore docs export_debug >>>>>>> >>>>>>> I want your changes be perfect from the start ;) >>>>>>> >>>>>> >>>>>> You're right. The renaming of the 'jvmg' target to 'debug' has happened >>>>>> recently ( >>>>>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f36e073d56a4) and >>>>>> >>>>>> we haven't adapted it. We will fix this. >>>>>> >>>>>> >>>>>>> And I need to discuss with our embedded group about >>>>>>> 0002_PPC_defines.patch >>>>>>> because it affects them. It may take time. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>> On 6/12/13 8:39 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> yes, the plan is that each is self contained. When I set up the >>>>>>>> patches I >>>>>>>> built and jckecked each. When I updated them I only built them >>>>>>>> selectively, >>>>>>>> so there might be minor issues. I had planned to assure this once I >>>>>>>> make >>>>>>>> webrevs from the patches. >>>>>>>> >>>>>>>> Some of them might apply in any order, but others depend on previous >>>>>>>> ones, >>>>>>>> e.g., 0009 containing the ppc files will not work without the changes >>>>>>>> before. >>>>>>>> >>>>>>>> The patches work with hs25-b34. >>>>>>>> >>>>>>>> Please tell me if I can do anything to ease your reviewing. >>>>>>>> >>>>>>>> Ah, I just saw your mail about closed code ... I tried to keep >>>>>>>> changes necessary to other platform code to a minimum, but also tried >>>>>>>> to avoid strange workarounds. Therefore I for example did change >>>>>>>> 0002 >>>>>>>> renaming the PPC defines, see the comment there. >>>>>>>> >>>>>>>> If you agree with the granularity of the changes, it would be great >>>>>>>> if you >>>>>>>> could generate bug-ids for them. Maybe at least for the changes >>>>>>>> up to 0016? >>>>>>>> >>>>>>>> Best regards >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov >>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>> ] >>>>>>>> Sent: Mittwoch, 12. Juni 2013 17:03 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: >>>>>>>> ppc-aix-port-dev at openjdk.java.**net; >>>>>>>> >>>>>>>> hotspot-dev at openjdk.java.net; Volker Simonis; Azeem Jiva; Chris >>>>>>>> Plummer >>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>> >>>>>>>> Thank you, Goetz. >>>>>>>> >>>>>>>> Can I review just 1 patch (for example, 1 from first 1-9), merge it >>>>>>>> with >>>>>>>> jdk8 and build? Or I should do review all 1-9 >>>>>>>> patches and merge them together into jdk8 to be able build? In >>>>>>>> short, is >>>>>>>> each patch self-contain? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> With my recent changes I removed some of the problems Vladimir >>>>>>>>> mentioned. >>>>>>>>> >>>>>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>>>>> repository, >>>>>>>>> at hotspot/ppc_patches. >>>>>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>>>>> hotspots >>>>>>>>> can be built. >>>>>>>>> >>>>>>>>> The queue contains the changes proposed by me before, with minor >>>>>>>>> changes >>>>>>>>> due >>>>>>>>> to recent development: >>>>>>>>> >>>>>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>>>>> 101-107 C-interpreter improvements >>>>>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>>>>> performant ppc port. >>>>>>>>> Altogether currently 49 changes. >>>>>>>>> >>>>>>>>> Our plan was to propose the changes in the order of the queue for >>>>>>>>> review. I'm happy to create webrevs for any of them. >>>>>>>>> >>>>>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the >>>>>>>>> changes >>>>>>>>> are more complete. They include all later improvements by fixes or >>>>>>>>> adaptions in merge changes. >>>>>>>>> For why and where I renamed PPC to PPC32 see the second change in >>>>>>>>> the >>>>>>>>> queue. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> PS: This can be used as the invokedynamic repository: >>>>>>>>> hg clone >>>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspot >>>>>>>>> >>>>>>>>> ppc-hotspot >>>>>>>>> hg clone >>>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/stage/hotspotstage-hotspot >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> cd stage-hotspot >>>>>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>>>>> hg qpush -a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Vladimir Kozlov >>>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>>> ] >>>>>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Here is result of my first attempt to build/test ppc changes >>>>>>>>> together >>>>>>>>> with our closed sources. >>>>>>>>> >>>>>>>>> Small problems: >>>>>>>>> >>>>>>>>> src/share/vm/memory/**allocation.hpp:209: Trailing whitespace >>>>>>>>> src/share/vm/memory/**allocation.inline.hpp:121: Trailing whitespace >>>>>>>>> src/share/vm/opto/escape.cpp:**2207: Trailing whitespace >>>>>>>>> src/share/vm/memory/**allocation.hpp:212: Trailing whitespace >>>>>>>>> src/share/vm/opto/escape.cpp:**2214: Trailing whitespace >>>>>>>>> >>>>>>>>> Build on MacOS: >>>>>>>>> >>>>>>>>> src/share/vm/opto/**callGenerator.cpp: In member function 'virtual >>>>>>>>> JVMState* VirtualCallGenerator::**generate(JVMState*)': >>>>>>>>> src/share/vm/opto/**callGenerator.cpp:204: error: >>>>>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>>>>> >>>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:54:2: error: #error >>>>>>>>> UNSUPPORTED_ARCH >>>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:167:4: error: #error >>>>>>>>> UNSUPPORTED_ARCH >>>>>>>>> agent/src/os/bsd/**MacosxDebuggerLocal.m:591:2: error: #error >>>>>>>>> UNSUPPORTED_ARCH >>>>>>>>> >>>>>>>>> >>>>>>>>> We have several conflict with closed sources builds: >>>>>>>>> >>>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp: In member function >>>>>>>>> 'bool >>>>>>>>> ElfSymbolTable::lookup(**unsigned char*, int*, int*, int*)': >>>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:97: error: comparison >>>>>>>>> between >>>>>>>>> signed and unsigned integer expressions >>>>>>>>> src/share/vm/utilities/**elfSymbolTable.cpp:124: error: comparison >>>>>>>>> between >>>>>>>>> signed and unsigned integer expressions >>>>>>>>> >>>>>>>>> error: no 'oopDesc** frame::interpreter_frame_**mirror_addr() const' >>>>>>>>> member function declared in class 'frame' >>>>>>>>> >>>>>>>>> error: no matching function for call to >>>>>>>>> 'SharedRuntime::c_calling_**convention(BasicType*&, VMRegPair*&, >>>>>>>>> uint&)' >>>>>>>>> >>>>>>>>> I think it is due to changes like next: >>>>>>>>> >>>>>>>>> -#ifdef PPC >>>>>>>>> +#ifdef PPC32 >>>>>>>>> oop* interpreter_frame_mirror_addr(**) const; >>>>>>>>> >>>>>>>>> >>>>>>>>> Next is easy fix in our closed sources but it requires efforts from >>>>>>>>> our >>>>>>>>> side: >>>>>>>>> >>>>>>>>> src/share/vm/prims/**methodHandles.cpp: In static member function >>>>>>>>> 'static >>>>>>>>> void MethodHandles::generate_**adapters()': >>>>>>>>> src/share/vm/prims/**methodHandles.cpp:68: error: >>>>>>>>> 'adapter_code_size' >>>>>>>>> cannot be used as a function >>>>>>>>> src/share/vm/prims/**methodHandles.cpp:70: error: >>>>>>>>> 'adapter_code_size' >>>>>>>>> cannot be used as a function >>>>>>>>> >>>>>>>>> >>>>>>>>> I would suggest to do such shared changes which affects different >>>>>>>>> builds >>>>>>>>> later after initial push. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>>>>> >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>>>>> tested it successfully. In case you experience any problems >>>>>>>>>> please tell me the details so I can fix them. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~**simonis/ppc-aix-port/index.**html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Vladimir Kozlov >>>>>>>>>> [mailto:vladimir.kozlov@**oracle.com >>>>>>>>>> ] >>>>>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>>>>> To: Simonis, Volker >>>>>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>> Vidstedt; >>>>>>>>>> Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan >>>>>>>>>> Bateman >>>>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>>>> >>>>>>>>>> Volker, >>>>>>>>>> >>>>>>>>>> Can you or someone update >>>>>>>>>> http://hg.openjdk.java.net/**ppc-aix-port/jdk8/hotspotto >>>>>>>>>> >>>>>>>>>> match latest >>>>>>>>>> sources in >>>>>>>>>> http://hg.openjdk.java.net/**jdk8/jdk8/hotspot >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ? >>>>>>>>>> I just tried to merge them and build Hotspot on x86 without >>>>>>>>>> success. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We intentionally used 'porters-dev' rather >>>>>>>>>>> than'ppc-aix-port-dev' in >>>>>>>>>>> the >>>>>>>>>>> beginning to address a broader audience for the initial >>>>>>>>>>> discussions. >>>>>>>>>>> >>>>>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Volker >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>>> ------------ >>>>>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>>> Bernard >>>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>>>> Ellison; >>>>>>>>>>> iris.clark at oracle.com >>>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>>> >>>>>>>>>>> Hi, Volker. >>>>>>>>>>> >>>>>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>>>>> >>>>>>>>>>> I think that the "Discussion" list probably needs to be updated >>>>>>>>>>> to be >>>>>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's >>>>>>>>>>> listed >>>>>>>>>>> as porters-dev. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> iris >>>>>>>>>>> >>>>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>>> Bernard >>>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim >>>>>>>>>>> Ellison >>>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>>> >>>>>>>>>>> Hi Iris, >>>>>>>>>>> >>>>>>>>>>> you're right, the title is too clumsy - I just couldn't come up >>>>>>>>>>> with >>>>>>>>>>> something better yesterday in the evening. >>>>>>>>>>> >>>>>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll >>>>>>>>>>> take >>>>>>>>>>> it. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Volker >>>>>>>>>>> >>>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>>> ------------ >>>>>>>>>>> >>>>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>>> Bernard >>>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>>> ; Tim Ellison >>>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>>>>> >>>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>>> >>>>>>>>>>> Hi, Volker. >>>>>>>>>>> >>>>>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>>>>> >>>>>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK >>>>>>>>>>> master >>>>>>>>>>> repositories" in the revised title is not ideal: >>>>>>>>>>> >>>>>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>>>>> >>>>>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>>>>> >>>>>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>>>>> >>>>>>>>>>> JEP: 175 >>>>>>>>>>> >>>>>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>>>> >>>>>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>>>>> repositories >>>>>>>>>>> >>>>>>>>>>> Author: Volker Simonis >>>>>>>>>>> >>>>>>>>>>> Organization: SAP AG >>>>>>>>>>> >>>>>>>>>>> Created: 2013/1/11 >>>>>>>>>>> >>>>>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs >>>>>>>>>>> are all >>>>>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: >>>>>>>>>>> Unicode >>>>>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself >>>>>>>>>>> contains >>>>>>>>>>> additional details. >>>>>>>>>>> >>>>>>>>>>> Perhaps others have suggestions? >>>>>>>>>>> >>>>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>>>> still be >>>>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>>>> be set >>>>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>>>> specified in the JEP specification)? >>>>>>>>>>> >>>>>>>>>>> Yes. Once that field is populated, the value will appear in >>>>>>>>>>> the JEP >>>>>>>>>>> index [1], see the third column. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Iris >>>>>>>>>>> >>>>>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>>>>> >>>>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com**] >>>>>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>>>> Bernard >>>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>>> ; Tim Ellison >>>>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I've just updated the JEP according to your suggestions. Please >>>>>>>>>>> find >>>>>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>>>>> version >>>>>>>>>>> in until now to give everybody a chance to comment on the >>>>>>>>>>> changes). >>>>>>>>>>> >>>>>>>>>>> Am I right with my assumption that the targeted release will >>>>>>>>>>> still be >>>>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will >>>>>>>>>>> be set >>>>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>>>> specified in the JEP specification)? >>>>>>>>>>> >>>>>>>>>>> In addition to the changes proposed by you I've added the >>>>>>>>>>> contents of >>>>>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the >>>>>>>>>>> "Description" >>>>>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX >>>>>>>>>>> Port >>>>>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki >>>>>>>>>>> Space" [3] >>>>>>>>>>> to the JEP. >>>>>>>>>>> >>>>>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended >>>>>>>>>>> to hold >>>>>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>>>>> >>>>>>>>>>> @Iris: could you please somehow arrange to give Azeem editing >>>>>>>>>>> rights to >>>>>>>>>>> that page? >>>>>>>>>>> >>>>>>>>>>> @Azeem: could you please be so kind to past the contents of the >>>>>>>>>>> "PPCAIX >>>>>>>>>>> plan" into that page (once you have the appropriate rights)? I >>>>>>>>>>> saw that >>>>>>>>>>> the document is created from an Atlassian Confluence Wiki anyway >>>>>>>>>>> and in >>>>>>>>>>> my unlimited naivety I imagine this could be a simple >>>>>>>>>>> copy-and-paste >>>>>>>>>>> operation:) If that doesn't work so easily, please let me know >>>>>>>>>>> how I >>>>>>>>>>> could help. >>>>>>>>>>> >>>>>>>>>>> If there are no objections I plan to checkin the new version of >>>>>>>>>>> the JEP >>>>>>>>>>> tomorrow after our telephone call. >>>>>>>>>>> >>>>>>>>>>> Thank you and best regards, >>>>>>>>>>> Volker >>>>>>>>>>> >>>>>>>>>>> [2]: >>>>>>>>>>> https://wiki.openjdk.java.net/**pages/viewpage.action?pageId=** >>>>>>>>>>> 13729959 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [3]: >>>>>>>>>>> https://wiki.openjdk.java.net/**display/PPCAIXPort >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>>>> ------------ >>>>>>>>>>> >>>>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>>>>> Bernard >>>>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>>>> ; Tim Ellison >>>>>>>>>>> *Cc:* iris.clark at oracle.com **; Alan >>>>>>>>>>> Bateman; Vladimir Kozlov >>>>>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>>>>> >>>>>>>>>>> Hi, Volker. >>>>>>>>>>> >>>>>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>>>> >>>>>>>>>>> http://openjdk.java.net/jeps/**175 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>>>>> comments: >>>>>>>>>>> >>>>>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>>>>> >>>>>>>>>>> -Recommend that the first Motivation bullet clearly indicate that >>>>>>>>>>> it is >>>>>>>>>>> only covering PPC/AIX. >>>>>>>>>>> >>>>>>>>>>> -Recommend that the second Motivation bullet be modified to >>>>>>>>>>> make it >>>>>>>>>>> clear that it applies to Hotspot only. >>>>>>>>>>> >>>>>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>>>>> >>>>>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined >>>>>>>>>>> up to >>>>>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>>>>> line. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Iris Clark >>>>>>>>>>> >>>>>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>>>>> >>>>>>>>>>> From serguei.spitsyn at oracle.com Fri Jun 14 09:28:57 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2013 09:28:57 -0700 Subject: Review Request (S) 6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description In-Reply-To: <4EBDFAC1-541F-4907-BA2A-EF1A8A68123D@oracle.com> References: <51BA2124.6060809@oracle.com> <4EBDFAC1-541F-4907-BA2A-EF1A8A68123D@oracle.com> Message-ID: <51BB44C9.6050405@oracle.com> Thanks, Staffan! Serguei On 6/14/13 2:11 AM, Staffan Larsen wrote: > Looks good. > > /Staffan > > On 13 jun 2013, at 21:44, serguei.spitsyn at oracle.com wrote: > >> Please, review a 1-line JVMTI doc fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=6493116 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-6493116 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/6493116-JVMTI-DOC.1 >> >> Summary: >> A typo in the parameter spelling, a bound update missed when the parameter was renamed >> >> >> Testing: Manual build of the JVMTI docs >> >> Thanks, >> Serguei From john.coomes at oracle.com Fri Jun 14 11:01:02 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Jun 2013 18:01:02 +0000 Subject: hg: hsx/hsx25/hotspot: 5 new changesets Message-ID: <20130614180121.D817F4820F@hg.openjdk.java.net> Changeset: 3a353050e85a Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a353050e85a Added tag jdk8-b94 for changeset 1beed1f6f9ed ! .hgtags Changeset: d0add7016434 Author: amurillo Date: 2013-06-07 09:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d0add7016434 8016078: new hotspot build - hs25-b37 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f2110083203d Author: sla Date: 2013-06-10 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f2110083203d 8005849: JEP 167: Event-Based JVM Tracing Reviewed-by: acorn, coleenp, sla Contributed-by: Karen Kinnear , Bengt Rutisson , Calvin Cheung , Erik Gahlin , Erik Helin , Jesper Wilhelmsson , Keith McGuigan , Mattias Tobiasson , Markus Gronlund , Mikael Auno , Nils Eliasson , Nils Loodin , Rickard Backman , Staffan Larsen , Stefan Karlsson , Yekaterina Kantserova ! make/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/minimal1.make ! make/bsd/makefiles/top.make + make/bsd/makefiles/trace.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/excludeSrc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/minimal1.make ! make/linux/makefiles/top.make + make/linux/makefiles/trace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/top.make + make/solaris/makefiles/trace.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/generated.make ! make/windows/makefiles/projectcreator.make + make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_share_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp + src/share/vm/gc_implementation/g1/evacuationInfo.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp + src/share/vm/gc_implementation/g1/g1YCTypes.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp + src/share/vm/gc_implementation/shared/copyFailedInfo.hpp + src/share/vm/gc_implementation/shared/gcHeapSummary.hpp + src/share/vm/gc_implementation/shared/gcTimer.cpp + src/share/vm/gc_implementation/shared/gcTimer.hpp + src/share/vm/gc_implementation/shared/gcTrace.cpp + src/share/vm/gc_implementation/shared/gcTrace.hpp + src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.hpp + src/share/vm/gc_implementation/shared/gcWhen.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp + src/share/vm/gc_interface/allocTracer.cpp + src/share/vm/gc_interface/allocTracer.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp + src/share/vm/gc_interface/gcName.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp + src/share/vm/memory/klassInfoClosure.hpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp + src/share/vm/memory/referenceProcessorStats.hpp + src/share/vm/memory/referenceType.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp + src/share/vm/opto/phasetype.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGen.java ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/memBaseline.cpp + src/share/vm/trace/noTraceBackend.hpp + src/share/vm/trace/trace.dtd + src/share/vm/trace/trace.xml + src/share/vm/trace/traceBackend.hpp + src/share/vm/trace/traceDataTypes.hpp + src/share/vm/trace/traceEvent.hpp + src/share/vm/trace/traceEventClasses.xsl + src/share/vm/trace/traceEventIds.xsl - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/traceStream.hpp + src/share/vm/trace/traceTime.hpp + src/share/vm/trace/traceTypes.xsl + src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/tracing.hpp + src/share/vm/trace/xinclude.mod + src/share/vm/trace/xsl_util.xsl ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp Changeset: 69689078dff8 Author: amurillo Date: 2013-06-13 23:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/69689078dff8 Merge - src/share/vm/trace/traceEventTypes.hpp Changeset: 5d65c078cd0a Author: amurillo Date: 2013-06-13 23:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5d65c078cd0a Added tag hs25-b37 for changeset 69689078dff8 ! .hgtags From goetz.lindenmaier at sap.com Fri Jun 14 13:54:12 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 14 Jun 2013 20:54:12 +0000 Subject: RFR(M): 8016586: PPC64 (part 3): basic changes for PPC64 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE3802@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE3802@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFE94C4@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I put the answer into a reply on this thread, if that's ok. > Albert tried 3 together with 1+2 and it failed to build very > dramatically so I need to look what happens. > It could be because you use TARGET_ARCH_MODEL_ppc_32 but > make/linux/platform_ppc was not modified accordingly so the build still > use TARGET_ARCH_MODEL_ppc. I guess you have to set arch_model = ppc_32 in platform_ppc. Further I renamed interp_masm_ppc_32.hpp stubRoutines_ppc_32.hpp I assume that adlc automatically adapts the names, or better the adlc.make does so. I'm not sure whether you need a ppc_32.ad file. I needed one (ppc_64.ad), which is empty so far. Best regards, Goetz. -----Original Message----- From: goetz.lindenmaier at sap.com Sent: Friday, June 14, 2013 12:38 AM To: 'Vladimir Kozlov' Cc: 'David Holmes'; 'ppc-aix-port-dev at openjdk.java.net'; 'Chris Plummer'; 'hotspot-dev at openjdk.java.net' Subject: RFR(M): 8016586: PPC64 (part 3): basic changes for PPC64 Hi, http://cr.openjdk.java.net/~goetz/webrevs/8016586-inlcudes/ This change contains the #includes we need for the linuxppc64 port, and some other minor changes. It decides about the file names in the cpu/ppc directory. We changed some of your #includes to use _32 extension, basically where they are guarded by TARGET_ARCH_MODEL... . I think it would make sense to set TARGET_ARCH_MODEL_ppc_32 instead of TARGET_ARCH_MODEL_ppc in your port, and name all files used within that define with extension _32. In the webrev this is changed consistently (not so in the patch). What are your politics about ordering the includes here? Most other includes are alpha sorted, but the platforms here are not at all. If you wish to, I'll establish a certain order. The changes in compileBroker.cpp and globals.hpp/EnableInvokeDynamic are preliminary. They'll be reverted in later changes. I would be glad if you could review this change, Best regards & thanks, Goetz. From john.coomes at oracle.com Fri Jun 14 18:12:27 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 15 Jun 2013 01:12:27 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130615011244.5E4764822F@hg.openjdk.java.net> Changeset: 3a353050e85a Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a353050e85a Added tag jdk8-b94 for changeset 1beed1f6f9ed ! .hgtags Changeset: 69689078dff8 Author: amurillo Date: 2013-06-13 23:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69689078dff8 Merge - src/share/vm/trace/traceEventTypes.hpp Changeset: 5d65c078cd0a Author: amurillo Date: 2013-06-13 23:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5d65c078cd0a Added tag hs25-b37 for changeset 69689078dff8 ! .hgtags Changeset: f9709e27a876 Author: amurillo Date: 2013-06-14 07:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9709e27a876 8016567: new hotspot build - hs25-b38 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.kozlov at oracle.com Fri Jun 14 21:25:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Jun 2013 21:25:14 -0700 Subject: RFR(S): 8016491: PPC64 (part 2): Clean up PPC defines. In-Reply-To: <51BAB324.3060708@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE37E1@DEWDFEMB12A.global.corp.sap> <51BAB324.3060708@oracle.com> Message-ID: <51BBECAA.8000303@oracle.com> These changes (part 2) passed testing on ppc. Thumb up for push. Thanks, Vladimir On 6/13/13 11:07 PM, David Holmes wrote: > Hi Goetz, > > I think having platform_ppc define PPC32, and platform_ppc64 define PPC64, with macros.hpp doing > > #if defined(PPC32) | defined(PPC64) > #infdef PPC > #define PPC > > is the right way to do this. It echoes what we do for x86. > > I was concerned that ppc32 was going to propagate everywhere but it appears that we would still use "ppc" to reflect a > 32-bit PPC build eg as the ARCH and BUILD_ARCH value, in platform_ppc, and in TARGET_ARCH_ppc etc. I assume your port (I > hate this 'yours', 'ours' business :( ) uses ppc64 ? > > A few places where PPC has become PPC32 indicate where cleanup is needed anyway: > > - os_xxx.cpp: the cpu_arch[] strings should not be hardwired in the file given they represent values we already define > in the platform_xxx file. > > - vm_version.cpp. The #define for CPU again should be handled via a variable passed by make; or at a minimum could be > inside the platform specific vm_version_xxx.hpp files! The FLOAT_ARCH strings are superfluous now as we always set > FLOAT_ARCH via the build - this should be cleaned up. > > > The change in os_xxx_zero.hpp seems unnecessary but harmless. > > The change in frame.h/cpp is indeed strange. I have no idea why our PPC port needs to do something in a completely > different way to our other 3 platforms. I will raise this with the team and see what can be done. > > Similarly for sharedRuntime.h/cpp. I would expect this to be conditional on the FP support. > > So this all seems okay to me. > > Thanks, > David > > On 14/06/2013 7:36 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Thanks for the bugid, Vladimir, I updated the webrev. >> http://cr.openjdk.java.net/~goetz/webrevs/8016491-PPC_defines/ >> >> I think defining PPC in macro.hpp makes it a bit more clear that >> it's meant for all, as it's coded in the #if. Also if I read code, I would >> more easily find it there than in platform_ppcXX. >> But the other way is OK, too. >> The #ifndef is not nice, I agree. Maybe a general #undef PPC >> before the #if? >> >> Best regards, >> Goetz. >> >> PS: About the JBS, I got the mail for the first change, but not for >> the second. >> >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, June 13, 2013 11:11 PM >> To: Lindenmaier, Goetz >> Cc: 'David Holmes'; 'Chris Plummer'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: JEP 175 - Review comments >> >> On 6/13/13 1:25 PM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I made a webrev with the changes you proposed: >>> http://cr.openjdk.java.net/~goetz/webrevs/PPC_defines/ >> >> I am not sure about what is the best solution for #define PPC, with >> #ifdef check in macros.hpp or, as Chris suggested, remove it from >> macros.hpp and add -DPPC in platform_ppc and platform_ppc64. >> >> And we need to wait what David can suggest for frame.cpp (may be comment >> should be enough). >> >>> Unfortunately I didn't get the JBS mail with the bugid yet. >>> If I have that, I'll update the webrev change message. >> >> Sorry. It means I have to send Bug ID each time I created one :( >> For this one it is: >> >> 8016491: PPC64 (part 2): Clean up PPC defines. >> >> Please, resend request for review in separate mail as you did for first >> 8016476. >> >> I also filed next bug: >> >> 8016586: PPC64 (part 3): basic changes for PPC64 >> >> Thanks, >> Vladimir >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Thursday, June 13, 2013 7:24 PM >>> To: Lindenmaier, Goetz >>> Cc: David Holmes; Chris Plummer; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: JEP 175 - Review comments >>> >>> Hi, >>> >>> With next changes in make/linux/platform_ppc >>> >>> -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC >>> +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32 >>> >>> g++ still doesn't like it: >>> >>> /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1: >>> error: "PPC" redefined >>> : error: this is the location of the previous definition >>> >>> I have to do next changes in macros.hpp to pass it: >>> >>> #if defined(PPC32) || defined(PPC64) >>> +#ifndef PPC >>> #define PPC >>> +#endif >>> #define PPC_ONLY(code) code >>> #define NOT_PPC(code) >>> #else >>> +#undef PPC >>> #define PPC_ONLY(code) >>> #define NOT_PPC(code) code >>> #endif >>> >>> Please, fix your patch accordingly (it is all open sources). >>> >>> Thanks, >>> Vladimir >>> >>> On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> I understand there are three cases: >>>> 1.) A real 32-bit processor/instruction set >>>> 2.) A real 64-bit processor/instruction set using 64-bit addresses etc. >>>> 3.) A 64-bit processor/instruction set using 32-bit addresses etc. >>> >>> Is 3) theoretical combination or you are doing it? >>> >>>> >>>> My naming is the following: >>>> 1.) PPC32 >>>> 2.) PPC64 & LP64 >>>> 3.) PPC64 & !LP64. >>>> PPC should be valid for all. >>>> >>>> I understood your port is of kind 1., but I really don?t know that. >>>> Thus I changed the existing PPC guards to PPC32 where we don't >>>> need the guarded code. >>>> >>>> This distinction seems to me to fit well in >>>> os_bsd_zero.hpp >>>> os_linux_zero.hpp >>>> sharedRuntime.cpp >>>> sharedRuntime.hpp >>>> vm_version.cpp / FLOAT_ARCH_STR >>>> >>>> You are right for the defines in >>>> frame.hpp/frame.cpp >>>> Here I guard what is probably an implementation detail of your port and >>>> not a restriction of the architecture. But maybe you can clean up this >>>> piece of code, or tell me by what else I should guard this. >>>> >>>> In patch 0008 you see the libarch adaption: >>>> LIBARCH/ppc64 = ppc64 >>>> LIBARCH/ppc = ppc >>>> I'm happy to adapt the naming of your port however you want to. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> yes, I changed PPC to PPC32 wherever we don't need the >>>> special case in our port. I do not know why you implemented >>>> the special cases, and maybe you need a define that is more >>>> verbose about the reason. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 13. Juni 2013 12:27 >>>> To: Lindenmaier, Goetz >>>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>> Subject: Re: JEP 175 - Review comments >>>> >>>> Hi Goetz, >>>> >>>> On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> @Chris: -DPPC32 needs to be set in make//platform_ppc32. >>>> >>>> I think BUILD_ARCH would also need to be ppc32 to pick that up - but >>>> then we would need to change LIB_ARCH back to ppc. Is the 64-bit port >>>> using ppc64 as the LIB_ARCH? >>>> >>>>> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64, >>>>> and in macros.hpp you find >>>> >>>> Okay I confess, it was a bad idea to generalize that given that out of >>>> the four platforms we support in the Oracle JDK, two are 32-bit only, so >>>> we only have sparc and x86 as examples. On sparc we only use SPARC and >>>> _LP64=1 to indicate things (and obviously in sparc specific files >>>> anything not in _LP64=1 is implicitly 32-bit). >>>> >>>> For x86 .... well x86 is a bit of a historical mess. So yes all those >>>> defines exist but the predominant form in shared code is X86 and AMD64 >>>> (as a synonym for LP64=1). IA32 exists but is barely used and arguably >>>> most of the places it remains are relics from before the 32-bit and >>>> 64-bit x86 code merge took place. So we have some historical baggage there. >>>> >>>> My main concern with the PPC, PPC32, PPC64 proposal is that the patch I >>>> saw: >>>> >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch >>>> >>>> seemed to use PPC32 in places I would not expect. I'm starting to feel >>>> that this is not 32 vs 64 per-se, but that PPC32 is being used as a way >>>> to flag "PPC Oracle" in a way that excludes it from use by the PPC64 >>>> port. If that is the case, and I can understand that it may well be >>>> given the existing PPC specific code was indeed put in place to support >>>> Oracle's PPC port, then perhaps we can look at ways of dealing with that >>>> without using what seems to me to be an artificial 32 vs 64-bit distinction? >>>> >>>> Aside: I would greatly prefer if ARM and PPC were never mentioned in the >>>> (existing) openjdk code, but that would require a level of refactoring >>>> in places that no-one unfortunately has the time to do. That said >>>> perhaps there are some places where a cleaner separation is possible. >>>> There are also places where compiler defines could be used to set string >>>> values rather than using the cpu ifdefs ie: >>>> >>>> #ifdef PPC >>>> #define CPU "ppc" >>>> etc >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> #if defined(IA32) || defined(AMD64) >>>>> #define X86 >>>>> #define X86_ONLY(code) code >>>>> #define NOT_X86(code) >>>>> #else >>>>> #undef X86 >>>>> #define X86_ONLY(code) >>>>> #define NOT_X86(code) code >>>>> #endif >>>>> >>>>> It's just not that obvious as the names of these platforms >>>>> are messed up. On PPC I wanted to follow a clean approach. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Donnerstag, 13. Juni 2013 04:46 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>>> Subject: Re: JEP 175 - Review comments >>>>> >>>>> Just adding my 2c from what was an internal discussion but is not in any >>>>> way confidential: >>>>> >>>>> We don't use 3 architecture designators on other platforms to >>>>> distinguish between "common", 32-bit and 64-bit, so why do we need to do >>>>> so for PPC ? >>>>> >>>>> The normal approach would be to add _LP64=1 specific ifdefs within an >>>>> architectural ifdef. >>>>> >>>>> This change (PPC32 usage) seems to be introducing unnecessary changes >>>>> and inconsistency with how 32-bit vs 64-bit is generally handled. >>>>> >>>>> Further, it is far from obvious from the patch that code now flagged as >>>>> PPC32 is indeed 32-bit specific rather than common! >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 13/06/2013 5:54 AM, Chris Plummer wrote: >>>>>> Hi Goetz, >>>>>> >>>>>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see >>>>>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in >>>>>> make/linux/platform_ppc. >>>>>> >>>>>> There are a lot of PPC references in c1 that don't appear to have been >>>>>> addressed. >>>>>> >>>>>> Is there a reason that PPC is not also defined for both PPC32 and PPC64, >>>>>> allowing you to use >>>>>> >>>>>> #ifdef PPC >>>>>> >>>>>> rather than >>>>>> >>>>>> #if defined(PPC32) || defined(PPC64) >>>>>> >>>>>> best regards, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> With my recent changes I removed some of the problems Vladimir mentioned. >>>>>>> >>>>>>> I also added the patches queue I maintain into our jdk8/hotspot >>>>>>> repository, >>>>>>> at hotspot/ppc_patches. >>>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc >>>>>>> hotspots >>>>>>> can be built. >>>>>>> >>>>>>> The queue contains the changes proposed by me before, with minor >>>>>>> changes due >>>>>>> to recent development: >>>>>>> >>>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) >>>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2) >>>>>>> 101-107 C-interpreter improvements >>>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working >>>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and >>>>>>> performant ppc port. >>>>>>> Altogether currently 49 changes. >>>>>>> >>>>>>> Our plan was to propose the changes in the order of the queue for >>>>>>> review. I'm happy to create webrevs for any of them. >>>>>>> >>>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes >>>>>>> are more complete. They include all later improvements by fixes or >>>>>>> adaptions in merge changes. >>>>>>> For why and where I renamed PPC to PPC32 see the second change in the >>>>>>> queue. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> PS: This can be used as the invokedynamic repository: >>>>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot >>>>>>> ppc-hotspot >>>>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot >>>>>>> stage-hotspot >>>>>>> cd stage-hotspot >>>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches >>>>>>> hg qpush -a >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>> Sent: Dienstag, 11. Juni 2013 18:34 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer >>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>> >>>>>>> Here is result of my first attempt to build/test ppc changes together >>>>>>> with our closed sources. >>>>>>> >>>>>>> Small problems: >>>>>>> >>>>>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >>>>>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >>>>>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >>>>>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >>>>>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >>>>>>> >>>>>>> Build on MacOS: >>>>>>> >>>>>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >>>>>>> JVMState* VirtualCallGenerator::generate(JVMState*)': >>>>>>> src/share/vm/opto/callGenerator.cpp:204: error: >>>>>>> 'zero_page_read_protected' is not a member of 'os' >>>>>>> >>>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error >>>>>>> UNSUPPORTED_ARCH >>>>>>> >>>>>>> >>>>>>> We have several conflict with closed sources builds: >>>>>>> >>>>>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >>>>>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >>>>>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >>>>>>> signed and unsigned integer expressions >>>>>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >>>>>>> signed and unsigned integer expressions >>>>>>> >>>>>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >>>>>>> member function declared in class 'frame' >>>>>>> >>>>>>> error: no matching function for call to >>>>>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >>>>>>> >>>>>>> I think it is due to changes like next: >>>>>>> >>>>>>> -#ifdef PPC >>>>>>> +#ifdef PPC32 >>>>>>> oop* interpreter_frame_mirror_addr() const; >>>>>>> >>>>>>> >>>>>>> Next is easy fix in our closed sources but it requires efforts from our >>>>>>> side: >>>>>>> >>>>>>> src/share/vm/prims/methodHandles.cpp: In static member function 'static >>>>>>> void MethodHandles::generate_adapters()': >>>>>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >>>>>>> cannot be used as a function >>>>>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >>>>>>> cannot be used as a function >>>>>>> >>>>>>> >>>>>>> I would suggest to do such shared changes which affects different builds >>>>>>> later after initial push. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and >>>>>>>> tested it successfully. In case you experience any problems >>>>>>>> please tell me the details so I can fix them. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>>> Sent: Dienstag, 4. Juni 2013 20:58 >>>>>>>> To: Simonis, Volker >>>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>>>> Alan Bateman >>>>>>>> Subject: Re: JEP 175 - Review comments >>>>>>>> >>>>>>>> Volker, >>>>>>>> >>>>>>>> Can you or someone update >>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>>>>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>>>>>>> I just tried to merge them and build Hotspot on x86 without success. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in >>>>>>>>> the >>>>>>>>> beginning to address a broader audience for the initial discussions. >>>>>>>>> >>>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> *From:* Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>>>>>>> iris.clark at oracle.com >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> Sorry about this, one more thing about the JEP... >>>>>>>>> >>>>>>>>> I think that the "Discussion" list probably needs to be updated to be >>>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>>>>>>> as porters-dev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> iris >>>>>>>>> >>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi Iris, >>>>>>>>> >>>>>>>>> you're right, the title is too clumsy - I just couldn't come up with >>>>>>>>> something better yesterday in the evening. >>>>>>>>> >>>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>>>>>>> >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> I've just updated the JEP according to your suggestions. >>>>>>>>> >>>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>>>>>>> repositories" in the revised title is not ideal: >>>>>>>>> >>>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>>>>>>> >>>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>>>>>>> >>>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>>> >>>>>>>>> JEP: 175 >>>>>>>>> >>>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>> >>>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master >>>>>>>>> repositories >>>>>>>>> >>>>>>>>> Author: Volker Simonis >>>>>>>>> >>>>>>>>> Organization: SAP AG >>>>>>>>> >>>>>>>>> Created: 2013/1/11 >>>>>>>>> >>>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>>>>>>> about adding features to JDK Release Projects. There are lots of >>>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>>>>>>> additional details. >>>>>>>>> >>>>>>>>> Perhaps others have suggestions? >>>>>>>>> >>>>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>> specified in the JEP specification)? >>>>>>>>> >>>>>>>>> Yes. Once that field is populated, the value will appear in the JEP >>>>>>>>> index [1], see the third column. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Iris >>>>>>>>> >>>>>>>>> [1]: http://openjdk.java.net/jeps/0 >>>>>>>>> >>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* RE: JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've just updated the JEP according to your suggestions. Please find >>>>>>>>> the new version attached to this mail (I haven't checked the new >>>>>>>>> version >>>>>>>>> in until now to give everybody a chance to comment on the changes). >>>>>>>>> >>>>>>>>> Am I right with my assumption that the targeted release will still be >>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>>>>>>> specified in the JEP specification)? >>>>>>>>> >>>>>>>>> In addition to the changes proposed by you I've added the contents of >>>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>>>>>>> to the JEP. >>>>>>>>> >>>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>>>>>>> Azeems "PPCAIX plan" document. >>>>>>>>> >>>>>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>>>>>>> that page? >>>>>>>>> >>>>>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>>>>>>> plan" into that page (once you have the appropriate rights)? I saw that >>>>>>>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>>>>>>> operation:) If that doesn't work so easily, please let me know how I >>>>>>>>> could help. >>>>>>>>> >>>>>>>>> If there are no objections I plan to checkin the new version of the JEP >>>>>>>>> tomorrow after our telephone call. >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> [2]: >>>>>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>>>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com] >>>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; >>>>>>>>> Bernard >>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>>>>>>> ; Tim Ellison >>>>>>>>> *Cc:* iris.clark at oracle.com ; Alan >>>>>>>>> Bateman; Vladimir Kozlov >>>>>>>>> *Subject:* JEP 175 - Review comments >>>>>>>>> >>>>>>>>> Hi, Volker. >>>>>>>>> >>>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>>>>>>> >>>>>>>>> http://openjdk.java.net/jeps/175 >>>>>>>>> >>>>>>>>> We're actively working to get your JEP to Funded. We had a few >>>>>>>>> comments: >>>>>>>>> >>>>>>>>> -Recommend that "8" be removed from the JEP title, etc. >>>>>>>>> >>>>>>>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>>>>>>> only covering PPC/AIX. >>>>>>>>> >>>>>>>>> -Recommend that the second Motivation bullet be modified to make it >>>>>>>>> clear that it applies to Hotspot only. >>>>>>>>> >>>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>>>>>>> section at the bottom of JEP 1 [1].) >>>>>>>>> >>>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>>>>>>> be the JEP's reviewers. Once they're satisfied with your >>>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" >>>>>>>>> line. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Iris Clark >>>>>>>>> >>>>>>>>> [1]: http://openjdk.java.net/jeps/1 >>>>>>>>> >>>>>> From david.holmes at oracle.com Sat Jun 15 03:00:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 15 Jun 2013 20:00:14 +1000 Subject: RFR(M): 8016586: PPC64 (part 3): basic changes for PPC64 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE3818@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE3818@DEWDFEMB12A.global.corp.sap> Message-ID: <51BC3B2E.2000205@oracle.com> On 14/06/2013 8:38 AM, Lindenmaier, Goetz wrote: > Hi, > > http://cr.openjdk.java.net/~goetz/webrevs/8016586-inlcudes/ > > This change contains the #includes we need for the linuxppc64 port, > and some other minor changes. It decides about the > file names in the cpu/ppc directory. > > We changed some of your #includes to use _32 extension, basically > where they are guarded by TARGET_ARCH_MODEL... . I think it > would make sense to set TARGET_ARCH_MODEL_ppc_32 instead > of TARGET_ARCH_MODEL_ppc in your port, and name all files used > within that define with extension _32. In the webrev this is changed > consistently (not so in the patch). So this ppc32 is indeed spreading everywhere :( That is potentially going to require a whole bunch of changes in our makefiles, source file renaming and possibly even build file changes. This will take time to investigate. It would have been simpler to simply let ppc imply 32-bit and use ppc64 as needed to distinguish. Our LIBARCH for this is likely to remain ppc not change to ppc32 David ----- > What are your politics about ordering the includes here? Most > other includes are alpha sorted, but the platforms here are not > at all. If you wish to, I'll establish a certain order. > > The changes in compileBroker.cpp and globals.hpp/EnableInvokeDynamic > are preliminary. They'll be reverted in later changes. > > I would be glad if you could review this change, > > Best regards & thanks, > Goetz. > From david.holmes at oracle.com Sun Jun 16 20:23:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Jun 2013 13:23:13 +1000 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51B9DCEC.6050906@oracle.com> References: <51B9DCEC.6050906@oracle.com> Message-ID: <51BE8121.8050101@oracle.com> Hi Bengt, I don't think it makes sense to embed a StackObj into a ValueObj! But then why is ArrayAllocator a StackObj? The only existing use of it I can see also embeds it! So seems to me it should be a ValueObj in the first place. David On 14/06/2013 12:53 AM, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of review for this small change? > http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ > > Sending this request to the broad hotspot dev mailing list since it > touches code in vm/utilities. > > Background: > > In the constructor for the ConcurrentMark class in G1 we set up one bit > map per worker thread: > > for (uint i = 0; i < _max_worker_id; ++i) { > ... > _count_card_bitmaps[i] = BitMap(card_bm_size, false); > ... > } > > Each of these bitmaps are malloced, which means that the amount of > C-heap we require grows with the number of GC worker threads we have. On > a machine with many CPUs we get many worker threads by default. For > example, on scaaa007 I get 79 GC worker threads. The size of the bitmaps > also scale with the heap size. Since this large machine has a lot of > memory we get a large default heap as well. > > Here is the output from just running java -version with G1 on scaaa007: > > $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version > java version "1.8.0-ea-fastdebug" > Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed mode) > allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc > > We malloc 221MB just by starting the VM. Most of the large allocations > are due to the BitMap allocations. My patch changes the BitMap > allocations to use the ArrayAllocator instead. That class uses mmap on > Solaris if the size is larger than 64K. > > With this patch the output looks like this: > > $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version > java version "1.8.0-ea-fastdebug" > Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) > Java HotSpot(TM) 64-Bit Server VM (build > 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed > mode) > allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc > > We are down to 31MB. > > Note that the ArrayAllocator only has this effect on Solaris machines. > Also note that I have not reduced the total amount of memory, just moved > it from the C-heap to mapped memory. > > One complication with the fix is that the BitMap data structures get > copied around quite a bit. The copies are shallow copies, so we don't > risk re-doing the allocation. But since I am now embedding an > ArrayAllocator in the BitMap structure the destructor for copies of the > ArrayAllocator gets called every now and then. The BitMap explicitly > frees up the allocated memory when it thinks it is necessary. So, rather > than trying to refactor the code to avoid copying I made it optional to > free the allocated memory in the ArrayAllocator desctructor. > > I do think it would be good to review the BitMap code. It seems a bit > fishy that we pass around shallow copies. But I think my current change > keeps the same behavior as before. > > Thanks, > Bengt From david.holmes at oracle.com Sun Jun 16 20:30:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Jun 2013 13:30:31 +1000 Subject: Review Request (S) 6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description In-Reply-To: <51BA2124.6060809@oracle.com> References: <51BA2124.6060809@oracle.com> Message-ID: <51BE82D7.3010400@oracle.com> Looks good to me too. David On 14/06/2013 5:44 AM, serguei.spitsyn at oracle.com wrote: > Please, review a 1-line JVMTI doc fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=6493116 > jbs: https://jbs.oracle.com/bugs/browse/JDK-6493116 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/6493116-JVMTI-DOC.1 > > > Summary: > A typo in the parameter spelling, a bound update missed when the > parameter was renamed > > > Testing: Manual build of the JVMTI docs > > Thanks, > Serguei From serguei.spitsyn at oracle.com Sun Jun 16 20:33:36 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 16 Jun 2013 20:33:36 -0700 Subject: Review Request (S) 6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description In-Reply-To: <51BE82D7.3010400@oracle.com> References: <51BA2124.6060809@oracle.com> <51BE82D7.3010400@oracle.com> Message-ID: <51BE8390.6040500@oracle.com> Thank you, David! But I've got the 2nd review from Yumin and already integrated the fix yesteray, sorry. Thanks, Serguei On 6/16/13 8:30 PM, David Holmes wrote: > Looks good to me too. > > David > > On 14/06/2013 5:44 AM, serguei.spitsyn at oracle.com wrote: >> Please, review a 1-line JVMTI doc fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=6493116 >> jbs: https://jbs.oracle.com/bugs/browse/JDK-6493116 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/6493116-JVMTI-DOC.1 >> >> >> >> Summary: >> A typo in the parameter spelling, a bound update missed when the >> parameter was renamed >> >> >> Testing: Manual build of the JVMTI docs >> >> Thanks, >> Serguei From bengt.rutisson at oracle.com Sun Jun 16 23:17:11 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 17 Jun 2013 08:17:11 +0200 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51BE8121.8050101@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> Message-ID: <51BEA9E7.1030503@oracle.com> Hi David, On 6/17/13 5:23 AM, David Holmes wrote: > Hi Bengt, > > I don't think it makes sense to embed a StackObj into a ValueObj! But > then why is ArrayAllocator a StackObj? The only existing use of it I > can see also embeds it! So seems to me it should be a ValueObj in the > first place. Good point. I changed ArrayAllocator to be a ValueObj instead. New webrev here: http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ Here is the diff compared to the last version: diff --git a/src/share/vm/memory/allocation.hpp b/src/share/vm/memory/allocation.hpp --- a/src/share/vm/memory/allocation.hpp +++ b/src/share/vm/memory/allocation.hpp @@ -665,7 +665,7 @@ // is set so that we always use malloc except for Solaris where we set the // limit to get mapped memory. template -class ArrayAllocator : public StackObj { +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { char* _addr; bool _use_malloc; size_t _size; Thanks for looking at this! Bengt > > David > > On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of review for this small change? >> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >> >> Sending this request to the broad hotspot dev mailing list since it >> touches code in vm/utilities. >> >> Background: >> >> In the constructor for the ConcurrentMark class in G1 we set up one bit >> map per worker thread: >> >> for (uint i = 0; i < _max_worker_id; ++i) { >> ... >> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >> ... >> } >> >> Each of these bitmaps are malloced, which means that the amount of >> C-heap we require grows with the number of GC worker threads we have. On >> a machine with many CPUs we get many worker threads by default. For >> example, on scaaa007 I get 79 GC worker threads. The size of the bitmaps >> also scale with the heap size. Since this large machine has a lot of >> memory we get a large default heap as well. >> >> Here is the output from just running java -version with G1 on scaaa007: >> >> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >> java version "1.8.0-ea-fastdebug" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed mode) >> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc >> >> We malloc 221MB just by starting the VM. Most of the large allocations >> are due to the BitMap allocations. My patch changes the BitMap >> allocations to use the ArrayAllocator instead. That class uses mmap on >> Solaris if the size is larger than 64K. >> >> With this patch the output looks like this: >> >> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >> java version "1.8.0-ea-fastdebug" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >> Java HotSpot(TM) 64-Bit Server VM (build >> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed >> mode) >> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc >> >> We are down to 31MB. >> >> Note that the ArrayAllocator only has this effect on Solaris machines. >> Also note that I have not reduced the total amount of memory, just moved >> it from the C-heap to mapped memory. >> >> One complication with the fix is that the BitMap data structures get >> copied around quite a bit. The copies are shallow copies, so we don't >> risk re-doing the allocation. But since I am now embedding an >> ArrayAllocator in the BitMap structure the destructor for copies of the >> ArrayAllocator gets called every now and then. The BitMap explicitly >> frees up the allocated memory when it thinks it is necessary. So, rather >> than trying to refactor the code to avoid copying I made it optional to >> free the allocated memory in the ArrayAllocator desctructor. >> >> I do think it would be good to review the BitMap code. It seems a bit >> fishy that we pass around shallow copies. But I think my current change >> keeps the same behavior as before. >> >> Thanks, >> Bengt From goetz.lindenmaier at sap.com Mon Jun 17 05:24:31 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 17 Jun 2013 12:24:31 +0000 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs Message-ID: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> Hi, On PPC, we use special stubs we call trampoline stubs for calls to target addresses that can not be encoded as offset in the branch instruction. A trampoline allows to encode a small branch in the code, even if there is the chance that this branch can not reach all possible code locations. If the relocation finds that a branch is too far for the instruction in the code, it can patch it to jump to the trampoline where is sufficient space for a far branch. To implement this, we extended the relocations by a new kind, trampoline_stub_Relocation: http://cr.openjdk.java.net/~goetz/webrevs/8016696-trampoline/ Aditionally to the code in 0004_opto-trampoline_relocations.patch I added debug printing functionality. Could I get a review on this change, please? Thanks, Goetz. From goetz.lindenmaier at sap.com Mon Jun 17 06:55:39 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 17 Jun 2013 13:55:39 +0000 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch Message-ID: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> Hi, the PPC64 port uses stub routines to implement safefetch. We had and have problems with inline assembly, especially with non-gcc compilers. Stub routines allow to implement safefetch without depending on OS or compiler, as it's the case with the current implementation. This also allows to use a single implementation if an architecture is supported on several os platforms. http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/ Currently, we guard the code with #ifdef SAFEFETCH_STUBS which is set in ppc64.make. I could also imagine an implementation that uses a pd_debug flag or a const flag set in os_.hpp that allows the C-compiler to optimize, and writing the code like this: extern "C" int pd_SafeFetch32 (int * adr, int errValue) ; extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ; inline int SafeFetch32(int* adr, int errValue) { if (UseSafefetchStub) { assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); return StubRoutines::SafeFetch32_stub()(adr, errValue); } else { pd_SafeFetch32(adr, errValue); } } Unfortunately this requires 1) setting the flag on all platforms 2) renaming the safefetch function on all platfoms. Actually I would prefer this second solution as it avoids the preprocessor, and am happy to edit the sources accordingly if this finds acceptance. For the implementation of a safefetch_stub see http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp Could I get a review on this change, please? Thanks, Goetz. From vladimir.kozlov at oracle.com Mon Jun 17 09:28:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Jun 2013 09:28:18 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> Message-ID: <51BF3922.2030100@oracle.com> I don't see problems with it. I asked Roland to look in also. Can you push it before Part 3 (which may need some time to adjust closed sources)? Thanks, Vladimir On 6/17/13 5:24 AM, Lindenmaier, Goetz wrote: > Hi, > > On PPC, we use special stubs we call trampoline stubs for calls to > > target addresses that can not be encoded as offset in the branch > > instruction. > > A trampoline allows to encode a small branch in the code, even if > > there is the chance that this branch can not reach all possible code > > locations. If the relocation finds that a branch is too far for the > > instruction in the code, it can patch it to jump to the trampoline > > where is sufficient space for a far branch. > > To implement this, we extended the relocations by a new kind, > > trampoline_stub_Relocation: > > http://cr.openjdk.java.net/~goetz/webrevs/8016696-trampoline/ > > Aditionally to the code in 0004_opto-trampoline_relocations.patch > > I added debug printing functionality. > > Could I get a review on this change, please? > > Thanks, > > Goetz. > From volker.simonis at gmail.com Mon Jun 17 10:08:09 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Jun 2013 19:08:09 +0200 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, I think the change is good and if the other reviewers don't decide to implement it for the current platforms we can push it. By the way, the makefile changes in ppc64.make will follow in patch 8 for linux [1] and patch 14 for aix [2]. The implementation of the stubs will be in patch 9 for linux [3] and patch 15 for aix [4] (only the signal handling part). Regards, Volker [1] http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch [2] http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch [3] http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch [4] http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi,**** > > ** ** > > the PPC64 port uses stub routines to implement safefetch. We had and**** > > have problems with inline assembly, especially with non-gcc**** > > compilers. Stub routines allow to implement safefetch without**** > > depending on OS or compiler, as it's the case with the current**** > > implementation. This also allows to use a single implementation if an**** > > architecture is supported on several os platforms.**** > > ** ** > > http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** > > ** ** > > Currently, we guard the code with **** > > #ifdef SAFEFETCH_STUBS**** > > which is set in ppc64.make.**** > > ** ** > > I could also imagine an implementation that uses a pd_debug flag**** > > or a const flag set in os_.hpp that allows the C-compiler to **** > > optimize, and writing the code like this:**** > > ** ** > > extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** > > extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** > * > > inline int SafeFetch32(int* adr, int errValue) {**** > > if (UseSafefetchStub) {**** > > assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** > * > > return StubRoutines::SafeFetch32_stub()(adr, errValue);**** > > } else {**** > > pd_SafeFetch32(adr, errValue);**** > > }**** > > }**** > > ** ** > > Unfortunately this requires **** > > 1) setting the flag on all platforms**** > > 2) renaming the safefetch function on all platfoms.**** > > ** ** > > Actually I would prefer this second solution as it avoids the > preprocessor, **** > > and am happy to edit the sources accordingly if this finds acceptance.**** > > ** ** > > For the implementation of a safefetch_stub see**** > > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp > **** > > ** ** > > Could I get a review on this change, please?**** > > ** ** > > Thanks,**** > > Goetz.**** > From vladimir.kozlov at oracle.com Mon Jun 17 11:10:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Jun 2013 11:10:18 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51BF3922.2030100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> Message-ID: <51BF510A.2090308@oracle.com> Albert ran JPRT testing with this Part 4 changes and it passed. Vladimir On 6/17/13 9:28 AM, Vladimir Kozlov wrote: > I don't see problems with it. I asked Roland to look in also. > > Can you push it before Part 3 (which may need some time to adjust closed > sources)? > > Thanks, > Vladimir > > On 6/17/13 5:24 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> On PPC, we use special stubs we call trampoline stubs for calls to >> >> target addresses that can not be encoded as offset in the branch >> >> instruction. >> >> A trampoline allows to encode a small branch in the code, even if >> >> there is the chance that this branch can not reach all possible code >> >> locations. If the relocation finds that a branch is too far for the >> >> instruction in the code, it can patch it to jump to the trampoline >> >> where is sufficient space for a far branch. >> >> To implement this, we extended the relocations by a new kind, >> >> trampoline_stub_Relocation: >> >> http://cr.openjdk.java.net/~goetz/webrevs/8016696-trampoline/ >> >> Aditionally to the code in 0004_opto-trampoline_relocations.patch >> >> I added debug printing functionality. >> >> Could I get a review on this change, please? >> >> Thanks, >> >> Goetz. >> From vladimir.kozlov at oracle.com Mon Jun 17 12:16:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Jun 2013 12:16:01 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> Message-ID: <51BF6071.4000101@oracle.com> I am fine with using stubs but it should be done in platform specific files stubRoutines_ppc_64.hpp (and .cpp) as we normally do on other platforms. That way you don't need #ifdef and separate flags. Vladimir On 6/17/13 6:55 AM, Lindenmaier, Goetz wrote: > Hi, > > the PPC64 port uses stub routines to implement safefetch. We had and > > have problems with inline assembly, especially with non-gcc > > compilers. Stub routines allow to implement safefetch without > > depending on OS or compiler, as it's the case with the current > > implementation. This also allows to use a single implementation if an > > architecture is supported on several os platforms. > > http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/ > > Currently, we guard the code with > > #ifdef SAFEFETCH_STUBS > > which is set in ppc64.make. > > I could also imagine an implementation that uses a pd_debug flag > > or a const flag set in os_.hpp that allows the C-compiler to > > optimize, and writing the code like this: > > extern "C" int pd_SafeFetch32 (int * adr, int errValue) ; > > extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ; > > inline int SafeFetch32(int* adr, int errValue) { > > if (UseSafefetchStub) { > > assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); > > return StubRoutines::SafeFetch32_stub()(adr, errValue); > > } else { > > pd_SafeFetch32(adr, errValue); > > } > > } > > Unfortunately this requires > > 1) setting the flag on all platforms > > 2) renaming the safefetch function on all platfoms. > > Actually I would prefer this second solution as it avoids the preprocessor, > > and am happy to edit the sources accordingly if this finds acceptance. > > For the implementation of a safefetch_stub see > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp > > Could I get a review on this change, please? > > Thanks, > > Goetz. > From vladimir.kozlov at oracle.com Wed Jun 12 07:56:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2013 07:56:12 -0700 (PDT) Subject: JEP 175 - Review comments In-Reply-To: References: <51B75177.3020804@oracle.com> <51B75221.9070901@oracle.com> Message-ID: <51B88C0C.6030907@oracle.com> On 6/11/13 11:28 PM, Steve Poole wrote: > When you say 'closed code' what are we talking about here? What functionality? Oracle code for ppc and arm. I am verifying that we don't have conflicts with ppc-aix merge. > Just to be clear - fixing up the open code to suit Oracles closed code is not our responsibility and should not be a gate to the merging in of the ppc-aix project. Not true, your changes in shared code affects our code so you pushing your problems on us. You should avoid shared code modification which affects our current sources and builds. At least in your initial big changesets. As I said, I am fine to do reasonable closed code adjustment but as separate small changeset later. For example, to convert adapter_code_size variable to function as in your changes. Regards, Vladimir > > On 11 Jun 2013, at 17:36, Vladimir Kozlov wrote: > >> Forgot to include ppc-aix mail alias. Which Hotspot mail alias we will use for reviews? >> >> Thanks, >> Vladimir >> >> >> -------- Original Message -------- >> Subject: Re: JEP 175 - Review comments >> Date: Tue, 11 Jun 2013 09:33:59 -0700 >> From: Vladimir Kozlov >> To: Lindenmaier, Goetz >> CC: Volker Simonis , Azeem Jiva , Chris Plummer >> >> Here is result of my first attempt to build/test ppc changes together >> with our closed sources. >> >> Small problems: >> >> src/share/vm/memory/allocation.hpp:209: Trailing whitespace >> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace >> src/share/vm/opto/escape.cpp:2207: Trailing whitespace >> src/share/vm/memory/allocation.hpp:212: Trailing whitespace >> src/share/vm/opto/escape.cpp:2214: Trailing whitespace >> >> Build on MacOS: >> >> src/share/vm/opto/callGenerator.cpp: In member function 'virtual >> JVMState* VirtualCallGenerator::generate(JVMState*)': >> src/share/vm/opto/callGenerator.cpp:204: error: >> 'zero_page_read_protected' is not a member of 'os' >> >> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error UNSUPPORTED_ARCH >> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error UNSUPPORTED_ARCH >> >> >> We have several conflict with closed sources builds: >> >> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool >> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': >> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between >> signed and unsigned integer expressions >> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between >> signed and unsigned integer expressions >> >> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' >> member function declared in class 'frame' >> >> error: no matching function for call to >> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' >> >> I think it is due to changes like next: >> >> -#ifdef PPC >> +#ifdef PPC32 >> oop* interpreter_frame_mirror_addr() const; >> >> >> Next is easy fix in our closed sources but it requires efforts from our >> side: >> >> src/share/vm/prims/methodHandles.cpp: In static member function 'static >> void MethodHandles::generate_adapters()': >> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' >> cannot be used as a function >> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' >> cannot be used as a function >> >> >> I would suggest to do such shared changes which affects different builds >> later after initial push. >> >> >> Thanks, >> Vladimir >> >> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I updated the repo to jdk8-b92. Our nightly tests built and >>> tested it successfully. In case you experience any problems >>> please tell me the details so I can fix them. >>> >>> Best regards, >>> Goetz. >>> >>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Dienstag, 4. Juni 2013 20:58 >>> To: Simonis, Volker >>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan Bateman >>> Subject: Re: JEP 175 - Review comments >>> >>> Volker, >>> >>> Can you or someone update >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >>> I just tried to merge them and build Hotspot on x86 without success. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>>> >>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in the >>>> beginning to address a broader audience for the initial discussions. >>>> >>>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>>> iris.clark at oracle.com >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> Sorry about this, one more thing about the JEP... >>>> >>>> I think that the "Discussion" list probably needs to be updated to be >>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>>> as porters-dev. >>>> >>>> Thanks, >>>> >>>> iris >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi Iris, >>>> >>>> you're right, the title is too clumsy - I just couldn't come up with >>>> something better yesterday in the evening. >>>> >>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take it. >>>> >>>> Thanks, >>>> Volker >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>>> >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> I've just updated the JEP according to your suggestions. >>>> >>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>>> repositories" in the revised title is not ideal: >>>> >>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>>> >>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>>> >>>> @@ -1,5 +1,5 @@ >>>> >>>> JEP: 175 >>>> >>>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master repositories >>>> >>>> Author: Volker Simonis >>>> >>>> Organization: SAP AG >>>> >>>> Created: 2013/1/11 >>>> >>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>>> about adding features to JDK Release Projects. There are lots of >>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>>> additional details. >>>> >>>> Perhaps others have suggestions? >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> Yes. Once that field is populated, the value will appear in the JEP >>>> index [1], see the third column. >>>> >>>> Thanks, >>>> >>>> Iris >>>> >>>> [1]: http://openjdk.java.net/jeps/0 >>>> >>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>>> *Sent:* Monday, June 03, 2013 10:10 AM >>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* Alan Bateman; Vladimir Kozlov >>>> *Subject:* RE: JEP 175 - Review comments >>>> >>>> Hi, >>>> >>>> I've just updated the JEP according to your suggestions. Please find >>>> the new version attached to this mail (I haven't checked the new version >>>> in until now to give everybody a chance to comment on the changes). >>>> >>>> Am I right with my assumption that the targeted release will still be >>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>>> specified in the JEP specification)? >>>> >>>> In addition to the changes proposed by you I've added the contents of >>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>>> to the JEP. >>>> >>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>>> Azeems "PPCAIX plan" document. >>>> >>>> @Iris: could you please somehow arrange to give Azeem editing rights to >>>> that page? >>>> >>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>>> plan" into that page (once you have the appropriate rights)? I saw that >>>> the document is created from an Atlassian Confluence Wiki anyway and in >>>> my unlimited naivety I imagine this could be a simple copy-and-paste >>>> operation:) If that doesn't work so easily, please let me know how I >>>> could help. >>>> >>>> If there are no objections I plan to checkin the new version of the JEP >>>> tomorrow after our telephone call. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> [2]: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:*Iris Clark [iris.clark at oracle.com] >>>> *Sent:* Friday, May 31, 2013 8:48 PM >>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; Bernard >>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>>> ; Tim Ellison >>>> *Cc:* iris.clark at oracle.com ; Alan >>>> Bateman; Vladimir Kozlov >>>> *Subject:* JEP 175 - Review comments >>>> >>>> Hi, Volker. >>>> >>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>>> >>>> http://openjdk.java.net/jeps/175 >>>> >>>> We're actively working to get your JEP to Funded. We had a few comments: >>>> >>>> -Recommend that "8" be removed from the JEP title, etc. >>>> >>>> -Recommend that the first Motivation bullet clearly indicate that it is >>>> only covering PPC/AIX. >>>> >>>> -Recommend that the second Motivation bullet be modified to make it >>>> clear that it applies to Hotspot only. >>>> >>>> (Instructions for editing the JEP may be found in the "Mechanics" >>>> section at the bottom of JEP 1 [1].) >>>> >>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>>> be the JEP's reviewers. Once they're satisfied with your >>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" line. >>>> >>>> Thanks, >>>> >>>> Iris Clark >>>> >>>> [1]: http://openjdk.java.net/jeps/1 >>>> >> >> > From david.holmes at oracle.com Mon Jun 17 20:34:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Jun 2013 13:34:49 +1000 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51BEA9E7.1030503@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> Message-ID: <51BFD559.8040908@oracle.com> Seems reasonable to me. Thanks, David On 17/06/2013 4:17 PM, Bengt Rutisson wrote: > > Hi David, > > On 6/17/13 5:23 AM, David Holmes wrote: >> Hi Bengt, >> >> I don't think it makes sense to embed a StackObj into a ValueObj! But >> then why is ArrayAllocator a StackObj? The only existing use of it I >> can see also embeds it! So seems to me it should be a ValueObj in the >> first place. > > Good point. I changed ArrayAllocator to be a ValueObj instead. New > webrev here: > http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ > > Here is the diff compared to the last version: > > diff --git a/src/share/vm/memory/allocation.hpp > b/src/share/vm/memory/allocation.hpp > --- a/src/share/vm/memory/allocation.hpp > +++ b/src/share/vm/memory/allocation.hpp > @@ -665,7 +665,7 @@ > // is set so that we always use malloc except for Solaris where we set > the > // limit to get mapped memory. > template > -class ArrayAllocator : public StackObj { > +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { > char* _addr; > bool _use_malloc; > size_t _size; > > > Thanks for looking at this! > Bengt > > >> >> David >> >> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Could I have a couple of review for this small change? >>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>> >>> Sending this request to the broad hotspot dev mailing list since it >>> touches code in vm/utilities. >>> >>> Background: >>> >>> In the constructor for the ConcurrentMark class in G1 we set up one bit >>> map per worker thread: >>> >>> for (uint i = 0; i < _max_worker_id; ++i) { >>> ... >>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>> ... >>> } >>> >>> Each of these bitmaps are malloced, which means that the amount of >>> C-heap we require grows with the number of GC worker threads we have. On >>> a machine with many CPUs we get many worker threads by default. For >>> example, on scaaa007 I get 79 GC worker threads. The size of the bitmaps >>> also scale with the heap size. Since this large machine has a lot of >>> memory we get a large default heap as well. >>> >>> Here is the output from just running java -version with G1 on scaaa007: >>> >>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>> java version "1.8.0-ea-fastdebug" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed mode) >>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc >>> >>> We malloc 221MB just by starting the VM. Most of the large allocations >>> are due to the BitMap allocations. My patch changes the BitMap >>> allocations to use the ArrayAllocator instead. That class uses mmap on >>> Solaris if the size is larger than 64K. >>> >>> With this patch the output looks like this: >>> >>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>> java version "1.8.0-ea-fastdebug" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>> Java HotSpot(TM) 64-Bit Server VM (build >>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed >>> mode) >>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc >>> >>> We are down to 31MB. >>> >>> Note that the ArrayAllocator only has this effect on Solaris machines. >>> Also note that I have not reduced the total amount of memory, just moved >>> it from the C-heap to mapped memory. >>> >>> One complication with the fix is that the BitMap data structures get >>> copied around quite a bit. The copies are shallow copies, so we don't >>> risk re-doing the allocation. But since I am now embedding an >>> ArrayAllocator in the BitMap structure the destructor for copies of the >>> ArrayAllocator gets called every now and then. The BitMap explicitly >>> frees up the allocated memory when it thinks it is necessary. So, rather >>> than trying to refactor the code to avoid copying I made it optional to >>> free the allocated memory in the ArrayAllocator desctructor. >>> >>> I do think it would be good to review the BitMap code. It seems a bit >>> fishy that we pass around shallow copies. But I think my current change >>> keeps the same behavior as before. >>> >>> Thanks, >>> Bengt > From bengt.rutisson at oracle.com Mon Jun 17 21:50:46 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Jun 2013 06:50:46 +0200 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51BFD559.8040908@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51BFD559.8040908@oracle.com> Message-ID: <51BFE726.8010903@oracle.com> On 6/18/13 5:34 AM, David Holmes wrote: > Seems reasonable to me. Thanks, David! BTW, I am not sure if you reviewed the whole change or just commented on the StackObj vs. ValueObj issue. Can I list you as a reviewer of the change? Thanks, Bengt > > Thanks, > David > > On 17/06/2013 4:17 PM, Bengt Rutisson wrote: >> >> Hi David, >> >> On 6/17/13 5:23 AM, David Holmes wrote: >>> Hi Bengt, >>> >>> I don't think it makes sense to embed a StackObj into a ValueObj! But >>> then why is ArrayAllocator a StackObj? The only existing use of it I >>> can see also embeds it! So seems to me it should be a ValueObj in the >>> first place. >> >> Good point. I changed ArrayAllocator to be a ValueObj instead. New >> webrev here: >> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >> >> Here is the diff compared to the last version: >> >> diff --git a/src/share/vm/memory/allocation.hpp >> b/src/share/vm/memory/allocation.hpp >> --- a/src/share/vm/memory/allocation.hpp >> +++ b/src/share/vm/memory/allocation.hpp >> @@ -665,7 +665,7 @@ >> // is set so that we always use malloc except for Solaris where we set >> the >> // limit to get mapped memory. >> template >> -class ArrayAllocator : public StackObj { >> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >> char* _addr; >> bool _use_malloc; >> size_t _size; >> >> >> Thanks for looking at this! >> Bengt >> >> >>> >>> David >>> >>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> Could I have a couple of review for this small change? >>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>> >>>> Sending this request to the broad hotspot dev mailing list since it >>>> touches code in vm/utilities. >>>> >>>> Background: >>>> >>>> In the constructor for the ConcurrentMark class in G1 we set up one >>>> bit >>>> map per worker thread: >>>> >>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>> ... >>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>> ... >>>> } >>>> >>>> Each of these bitmaps are malloced, which means that the amount of >>>> C-heap we require grows with the number of GC worker threads we >>>> have. On >>>> a machine with many CPUs we get many worker threads by default. For >>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>> bitmaps >>>> also scale with the heap size. Since this large machine has a lot of >>>> memory we get a large default heap as well. >>>> >>>> Here is the output from just running java -version with G1 on >>>> scaaa007: >>>> >>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>> java version "1.8.0-ea-fastdebug" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>>> mode) >>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc >>>> >>>> We malloc 221MB just by starting the VM. Most of the large allocations >>>> are due to the BitMap allocations. My patch changes the BitMap >>>> allocations to use the ArrayAllocator instead. That class uses mmap on >>>> Solaris if the size is larger than 64K. >>>> >>>> With this patch the output looks like this: >>>> >>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>> java version "1.8.0-ea-fastdebug" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>> Java HotSpot(TM) 64-Bit Server VM (build >>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed >>>> mode) >>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc >>>> >>>> We are down to 31MB. >>>> >>>> Note that the ArrayAllocator only has this effect on Solaris machines. >>>> Also note that I have not reduced the total amount of memory, just >>>> moved >>>> it from the C-heap to mapped memory. >>>> >>>> One complication with the fix is that the BitMap data structures get >>>> copied around quite a bit. The copies are shallow copies, so we don't >>>> risk re-doing the allocation. But since I am now embedding an >>>> ArrayAllocator in the BitMap structure the destructor for copies of >>>> the >>>> ArrayAllocator gets called every now and then. The BitMap explicitly >>>> frees up the allocated memory when it thinks it is necessary. So, >>>> rather >>>> than trying to refactor the code to avoid copying I made it >>>> optional to >>>> free the allocated memory in the ArrayAllocator desctructor. >>>> >>>> I do think it would be good to review the BitMap code. It seems a bit >>>> fishy that we pass around shallow copies. But I think my current >>>> change >>>> keeps the same behavior as before. >>>> >>>> Thanks, >>>> Bengt >> From david.holmes at oracle.com Mon Jun 17 21:57:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Jun 2013 14:57:17 +1000 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51BFE726.8010903@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51BFD559.8040908@oracle.com> <51BFE726.8010903@oracle.com> Message-ID: <51BFE8AD.8080504@oracle.com> Reviewed. Thanks. David On 18/06/2013 2:50 PM, Bengt Rutisson wrote: > On 6/18/13 5:34 AM, David Holmes wrote: >> Seems reasonable to me. > > Thanks, David! > > BTW, I am not sure if you reviewed the whole change or just commented on > the StackObj vs. ValueObj issue. Can I list you as a reviewer of the > change? > > Thanks, > Bengt > >> >> Thanks, >> David >> >> On 17/06/2013 4:17 PM, Bengt Rutisson wrote: >>> >>> Hi David, >>> >>> On 6/17/13 5:23 AM, David Holmes wrote: >>>> Hi Bengt, >>>> >>>> I don't think it makes sense to embed a StackObj into a ValueObj! But >>>> then why is ArrayAllocator a StackObj? The only existing use of it I >>>> can see also embeds it! So seems to me it should be a ValueObj in the >>>> first place. >>> >>> Good point. I changed ArrayAllocator to be a ValueObj instead. New >>> webrev here: >>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >>> >>> Here is the diff compared to the last version: >>> >>> diff --git a/src/share/vm/memory/allocation.hpp >>> b/src/share/vm/memory/allocation.hpp >>> --- a/src/share/vm/memory/allocation.hpp >>> +++ b/src/share/vm/memory/allocation.hpp >>> @@ -665,7 +665,7 @@ >>> // is set so that we always use malloc except for Solaris where we set >>> the >>> // limit to get mapped memory. >>> template >>> -class ArrayAllocator : public StackObj { >>> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >>> char* _addr; >>> bool _use_malloc; >>> size_t _size; >>> >>> >>> Thanks for looking at this! >>> Bengt >>> >>> >>>> >>>> David >>>> >>>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> Could I have a couple of review for this small change? >>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>>> >>>>> Sending this request to the broad hotspot dev mailing list since it >>>>> touches code in vm/utilities. >>>>> >>>>> Background: >>>>> >>>>> In the constructor for the ConcurrentMark class in G1 we set up one >>>>> bit >>>>> map per worker thread: >>>>> >>>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>>> ... >>>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>>> ... >>>>> } >>>>> >>>>> Each of these bitmaps are malloced, which means that the amount of >>>>> C-heap we require grows with the number of GC worker threads we >>>>> have. On >>>>> a machine with many CPUs we get many worker threads by default. For >>>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>>> bitmaps >>>>> also scale with the heap size. Since this large machine has a lot of >>>>> memory we get a large default heap as well. >>>>> >>>>> Here is the output from just running java -version with G1 on >>>>> scaaa007: >>>>> >>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>> java version "1.8.0-ea-fastdebug" >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>>>> mode) >>>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc >>>>> >>>>> We malloc 221MB just by starting the VM. Most of the large allocations >>>>> are due to the BitMap allocations. My patch changes the BitMap >>>>> allocations to use the ArrayAllocator instead. That class uses mmap on >>>>> Solaris if the size is larger than 64K. >>>>> >>>>> With this patch the output looks like this: >>>>> >>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>> java version "1.8.0-ea-fastdebug" >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed >>>>> mode) >>>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc >>>>> >>>>> We are down to 31MB. >>>>> >>>>> Note that the ArrayAllocator only has this effect on Solaris machines. >>>>> Also note that I have not reduced the total amount of memory, just >>>>> moved >>>>> it from the C-heap to mapped memory. >>>>> >>>>> One complication with the fix is that the BitMap data structures get >>>>> copied around quite a bit. The copies are shallow copies, so we don't >>>>> risk re-doing the allocation. But since I am now embedding an >>>>> ArrayAllocator in the BitMap structure the destructor for copies of >>>>> the >>>>> ArrayAllocator gets called every now and then. The BitMap explicitly >>>>> frees up the allocated memory when it thinks it is necessary. So, >>>>> rather >>>>> than trying to refactor the code to avoid copying I made it >>>>> optional to >>>>> free the allocated memory in the ArrayAllocator desctructor. >>>>> >>>>> I do think it would be good to review the BitMap code. It seems a bit >>>>> fishy that we pass around shallow copies. But I think my current >>>>> change >>>>> keeps the same behavior as before. >>>>> >>>>> Thanks, >>>>> Bengt >>> > From christian.thalinger at oracle.com Mon Jun 17 22:12:43 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Jun 2013 22:12:43 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> Message-ID: <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: > Hi Goetz, > > I think the change is good and if the other reviewers don't decide to > implement it for the current platforms we can push it. I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? -- Chris > > By the way, the makefile changes in ppc64.make will follow in patch 8 for > linux [1] and patch 14 for aix [2]. > The implementation of the stubs will be in patch 9 for linux [3] and patch > 15 for aix [4] (only the signal handling part). > > Regards, > Volker > > [1] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch > [2] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch > [3] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch > [4] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch > > > > On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > >> Hi,**** >> >> ** ** >> >> the PPC64 port uses stub routines to implement safefetch. We had and**** >> >> have problems with inline assembly, especially with non-gcc**** >> >> compilers. Stub routines allow to implement safefetch without**** >> >> depending on OS or compiler, as it's the case with the current**** >> >> implementation. This also allows to use a single implementation if an**** >> >> architecture is supported on several os platforms.**** >> >> ** ** >> >> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >> >> ** ** >> >> Currently, we guard the code with **** >> >> #ifdef SAFEFETCH_STUBS**** >> >> which is set in ppc64.make.**** >> >> ** ** >> >> I could also imagine an implementation that uses a pd_debug flag**** >> >> or a const flag set in os_.hpp that allows the C-compiler to **** >> >> optimize, and writing the code like this:**** >> >> ** ** >> >> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >> >> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >> * >> >> inline int SafeFetch32(int* adr, int errValue) {**** >> >> if (UseSafefetchStub) {**** >> >> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >> * >> >> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >> >> } else {**** >> >> pd_SafeFetch32(adr, errValue);**** >> >> }**** >> >> }**** >> >> ** ** >> >> Unfortunately this requires **** >> >> 1) setting the flag on all platforms**** >> >> 2) renaming the safefetch function on all platfoms.**** >> >> ** ** >> >> Actually I would prefer this second solution as it avoids the >> preprocessor, **** >> >> and am happy to edit the sources accordingly if this finds acceptance.**** >> >> ** ** >> >> For the implementation of a safefetch_stub see**** >> >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >> **** >> >> ** ** >> >> Could I get a review on this change, please?**** >> >> ** ** >> >> Thanks,**** >> >> Goetz.**** >> From bengt.rutisson at oracle.com Mon Jun 17 22:34:04 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Jun 2013 07:34:04 +0200 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51BFE8AD.8080504@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51BFD559.8040908@oracle.com> <51BFE726.8010903@oracle.com> <51BFE8AD.8080504@oracle.com> Message-ID: <51BFF14C.2060403@oracle.com> On 6/18/13 6:57 AM, David Holmes wrote: > Reviewed. Thanks! Bengt > > Thanks. > > David > > On 18/06/2013 2:50 PM, Bengt Rutisson wrote: >> On 6/18/13 5:34 AM, David Holmes wrote: >>> Seems reasonable to me. >> >> Thanks, David! >> >> BTW, I am not sure if you reviewed the whole change or just commented on >> the StackObj vs. ValueObj issue. Can I list you as a reviewer of the >> change? >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> David >>> >>> On 17/06/2013 4:17 PM, Bengt Rutisson wrote: >>>> >>>> Hi David, >>>> >>>> On 6/17/13 5:23 AM, David Holmes wrote: >>>>> Hi Bengt, >>>>> >>>>> I don't think it makes sense to embed a StackObj into a ValueObj! But >>>>> then why is ArrayAllocator a StackObj? The only existing use of it I >>>>> can see also embeds it! So seems to me it should be a ValueObj in the >>>>> first place. >>>> >>>> Good point. I changed ArrayAllocator to be a ValueObj instead. New >>>> webrev here: >>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >>>> >>>> Here is the diff compared to the last version: >>>> >>>> diff --git a/src/share/vm/memory/allocation.hpp >>>> b/src/share/vm/memory/allocation.hpp >>>> --- a/src/share/vm/memory/allocation.hpp >>>> +++ b/src/share/vm/memory/allocation.hpp >>>> @@ -665,7 +665,7 @@ >>>> // is set so that we always use malloc except for Solaris where >>>> we set >>>> the >>>> // limit to get mapped memory. >>>> template >>>> -class ArrayAllocator : public StackObj { >>>> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >>>> char* _addr; >>>> bool _use_malloc; >>>> size_t _size; >>>> >>>> >>>> Thanks for looking at this! >>>> Bengt >>>> >>>> >>>>> >>>>> David >>>>> >>>>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Could I have a couple of review for this small change? >>>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>>>> >>>>>> Sending this request to the broad hotspot dev mailing list since it >>>>>> touches code in vm/utilities. >>>>>> >>>>>> Background: >>>>>> >>>>>> In the constructor for the ConcurrentMark class in G1 we set up one >>>>>> bit >>>>>> map per worker thread: >>>>>> >>>>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>>>> ... >>>>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>>>> ... >>>>>> } >>>>>> >>>>>> Each of these bitmaps are malloced, which means that the amount of >>>>>> C-heap we require grows with the number of GC worker threads we >>>>>> have. On >>>>>> a machine with many CPUs we get many worker threads by default. For >>>>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>>>> bitmaps >>>>>> also scale with the heap size. Since this large machine has a lot of >>>>>> memory we get a large default heap as well. >>>>>> >>>>>> Here is the output from just running java -version with G1 on >>>>>> scaaa007: >>>>>> >>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>> java version "1.8.0-ea-fastdebug" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>>>>> mode) >>>>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB >>>>>> resrc >>>>>> >>>>>> We malloc 221MB just by starting the VM. Most of the large >>>>>> allocations >>>>>> are due to the BitMap allocations. My patch changes the BitMap >>>>>> allocations to use the ArrayAllocator instead. That class uses >>>>>> mmap on >>>>>> Solaris if the size is larger than 64K. >>>>>> >>>>>> With this patch the output looks like this: >>>>>> >>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>> java version "1.8.0-ea-fastdebug" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, >>>>>> mixed >>>>>> mode) >>>>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB >>>>>> resrc >>>>>> >>>>>> We are down to 31MB. >>>>>> >>>>>> Note that the ArrayAllocator only has this effect on Solaris >>>>>> machines. >>>>>> Also note that I have not reduced the total amount of memory, just >>>>>> moved >>>>>> it from the C-heap to mapped memory. >>>>>> >>>>>> One complication with the fix is that the BitMap data structures get >>>>>> copied around quite a bit. The copies are shallow copies, so we >>>>>> don't >>>>>> risk re-doing the allocation. But since I am now embedding an >>>>>> ArrayAllocator in the BitMap structure the destructor for copies of >>>>>> the >>>>>> ArrayAllocator gets called every now and then. The BitMap explicitly >>>>>> frees up the allocated memory when it thinks it is necessary. So, >>>>>> rather >>>>>> than trying to refactor the code to avoid copying I made it >>>>>> optional to >>>>>> free the allocated memory in the ArrayAllocator desctructor. >>>>>> >>>>>> I do think it would be good to review the BitMap code. It seems a >>>>>> bit >>>>>> fishy that we pass around shallow copies. But I think my current >>>>>> change >>>>>> keeps the same behavior as before. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >> From roland.westrelin at oracle.com Tue Jun 18 00:33:49 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 18 Jun 2013 09:33:49 +0200 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51BF3922.2030100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> Message-ID: > I don't see problems with it. I asked Roland to look in also. I don't see a problem with it either. Roland. From bertrand.delsart at oracle.com Tue Jun 18 01:36:45 2013 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 18 Jun 2013 10:36:45 +0200 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> Message-ID: <51C01C1D.6040205@oracle.com> Well, there might be one. This change is consuming the last unused relocType (yet_unused_type_2) Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. Bertrand. On 6/18/13 9:33 AM, Roland Westrelin wrote: >> I don't see problems with it. I asked Roland to look in also. > > I don't see a problem with it either. > > Roland. > -- Bertrand Delsart, bertrand.delsart at oracle.com Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From goetz.lindenmaier at sap.com Tue Jun 18 01:50:27 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 18 Jun 2013 08:50:27 +0000 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> Hi, We have it on these platforms: ia64 (nt, linux, hp_ux) parisc (hp_ux) zArch (linux) ppc (aix, linux) I would implement it on x86 & friends, you do it on sparc and wherever else you like it? Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 18. Juni 2013 07:13 To: Volker Simonis Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: > Hi Goetz, > > I think the change is good and if the other reviewers don't decide to > implement it for the current platforms we can push it. I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? -- Chris > > By the way, the makefile changes in ppc64.make will follow in patch 8 for > linux [1] and patch 14 for aix [2]. > The implementation of the stubs will be in patch 9 for linux [3] and patch > 15 for aix [4] (only the signal handling part). > > Regards, > Volker > > [1] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch > [2] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch > [3] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch > [4] > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch > > > > On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > >> Hi,**** >> >> ** ** >> >> the PPC64 port uses stub routines to implement safefetch. We had and**** >> >> have problems with inline assembly, especially with non-gcc**** >> >> compilers. Stub routines allow to implement safefetch without**** >> >> depending on OS or compiler, as it's the case with the current**** >> >> implementation. This also allows to use a single implementation if an**** >> >> architecture is supported on several os platforms.**** >> >> ** ** >> >> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >> >> ** ** >> >> Currently, we guard the code with **** >> >> #ifdef SAFEFETCH_STUBS**** >> >> which is set in ppc64.make.**** >> >> ** ** >> >> I could also imagine an implementation that uses a pd_debug flag**** >> >> or a const flag set in os_.hpp that allows the C-compiler to **** >> >> optimize, and writing the code like this:**** >> >> ** ** >> >> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >> >> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >> * >> >> inline int SafeFetch32(int* adr, int errValue) {**** >> >> if (UseSafefetchStub) {**** >> >> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >> * >> >> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >> >> } else {**** >> >> pd_SafeFetch32(adr, errValue);**** >> >> }**** >> >> }**** >> >> ** ** >> >> Unfortunately this requires **** >> >> 1) setting the flag on all platforms**** >> >> 2) renaming the safefetch function on all platfoms.**** >> >> ** ** >> >> Actually I would prefer this second solution as it avoids the >> preprocessor, **** >> >> and am happy to edit the sources accordingly if this finds acceptance.**** >> >> ** ** >> >> For the implementation of a safefetch_stub see**** >> >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >> **** >> >> ** ** >> >> Could I get a review on this change, please?**** >> >> ** ** >> >> Thanks,**** >> >> Goetz.**** >> From coleen.phillimore at oracle.com Tue Jun 18 06:21:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 18 Jun 2013 09:21:39 -0400 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51BFE8AD.8080504@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51BFD559.8040908@oracle.com> <51BFE726.8010903@oracle.com> <51BFE8AD.8080504@oracle.com> Message-ID: <51C05EE3.1010808@oracle.com> Bengt, I had a look at this change also. I would pick ResourceObj over ValueObj for the ArrayAllocator class. ValueObj really is embedded and is used very consistently, and ResourceObj is usually used for mixed cases like this. Is there some complication to using ResourceObj? Thanks, Coleen On 06/18/2013 12:57 AM, David Holmes wrote: > Reviewed. > > Thanks. > > David > > On 18/06/2013 2:50 PM, Bengt Rutisson wrote: >> On 6/18/13 5:34 AM, David Holmes wrote: >>> Seems reasonable to me. >> >> Thanks, David! >> >> BTW, I am not sure if you reviewed the whole change or just commented on >> the StackObj vs. ValueObj issue. Can I list you as a reviewer of the >> change? >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> David >>> >>> On 17/06/2013 4:17 PM, Bengt Rutisson wrote: >>>> >>>> Hi David, >>>> >>>> On 6/17/13 5:23 AM, David Holmes wrote: >>>>> Hi Bengt, >>>>> >>>>> I don't think it makes sense to embed a StackObj into a ValueObj! But >>>>> then why is ArrayAllocator a StackObj? The only existing use of it I >>>>> can see also embeds it! So seems to me it should be a ValueObj in the >>>>> first place. >>>> >>>> Good point. I changed ArrayAllocator to be a ValueObj instead. New >>>> webrev here: >>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >>>> >>>> Here is the diff compared to the last version: >>>> >>>> diff --git a/src/share/vm/memory/allocation.hpp >>>> b/src/share/vm/memory/allocation.hpp >>>> --- a/src/share/vm/memory/allocation.hpp >>>> +++ b/src/share/vm/memory/allocation.hpp >>>> @@ -665,7 +665,7 @@ >>>> // is set so that we always use malloc except for Solaris where >>>> we set >>>> the >>>> // limit to get mapped memory. >>>> template >>>> -class ArrayAllocator : public StackObj { >>>> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >>>> char* _addr; >>>> bool _use_malloc; >>>> size_t _size; >>>> >>>> >>>> Thanks for looking at this! >>>> Bengt >>>> >>>> >>>>> >>>>> David >>>>> >>>>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Could I have a couple of review for this small change? >>>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>>>> >>>>>> Sending this request to the broad hotspot dev mailing list since it >>>>>> touches code in vm/utilities. >>>>>> >>>>>> Background: >>>>>> >>>>>> In the constructor for the ConcurrentMark class in G1 we set up one >>>>>> bit >>>>>> map per worker thread: >>>>>> >>>>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>>>> ... >>>>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>>>> ... >>>>>> } >>>>>> >>>>>> Each of these bitmaps are malloced, which means that the amount of >>>>>> C-heap we require grows with the number of GC worker threads we >>>>>> have. On >>>>>> a machine with many CPUs we get many worker threads by default. For >>>>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>>>> bitmaps >>>>>> also scale with the heap size. Since this large machine has a lot of >>>>>> memory we get a large default heap as well. >>>>>> >>>>>> Here is the output from just running java -version with G1 on >>>>>> scaaa007: >>>>>> >>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>> java version "1.8.0-ea-fastdebug" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>>>>> mode) >>>>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB >>>>>> resrc >>>>>> >>>>>> We malloc 221MB just by starting the VM. Most of the large >>>>>> allocations >>>>>> are due to the BitMap allocations. My patch changes the BitMap >>>>>> allocations to use the ArrayAllocator instead. That class uses >>>>>> mmap on >>>>>> Solaris if the size is larger than 64K. >>>>>> >>>>>> With this patch the output looks like this: >>>>>> >>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>> java version "1.8.0-ea-fastdebug" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, >>>>>> mixed >>>>>> mode) >>>>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB >>>>>> resrc >>>>>> >>>>>> We are down to 31MB. >>>>>> >>>>>> Note that the ArrayAllocator only has this effect on Solaris >>>>>> machines. >>>>>> Also note that I have not reduced the total amount of memory, just >>>>>> moved >>>>>> it from the C-heap to mapped memory. >>>>>> >>>>>> One complication with the fix is that the BitMap data structures get >>>>>> copied around quite a bit. The copies are shallow copies, so we >>>>>> don't >>>>>> risk re-doing the allocation. But since I am now embedding an >>>>>> ArrayAllocator in the BitMap structure the destructor for copies of >>>>>> the >>>>>> ArrayAllocator gets called every now and then. The BitMap explicitly >>>>>> frees up the allocated memory when it thinks it is necessary. So, >>>>>> rather >>>>>> than trying to refactor the code to avoid copying I made it >>>>>> optional to >>>>>> free the allocated memory in the ArrayAllocator desctructor. >>>>>> >>>>>> I do think it would be good to review the BitMap code. It seems a >>>>>> bit >>>>>> fishy that we pass around shallow copies. But I think my current >>>>>> change >>>>>> keeps the same behavior as before. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >> From bengt.rutisson at oracle.com Tue Jun 18 07:31:55 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Jun 2013 16:31:55 +0200 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51C05EE3.1010808@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51BFD559.8040908@oracle.com> <51BFE726.8010903@oracle.com> <51BFE8AD.8080504@oracle.com> <51C05EE3.1010808@oracle.com> Message-ID: <51C06F5B.9090007@oracle.com> Hi Coleen, Thanks for looking at this! On 6/18/13 3:21 PM, Coleen Phillimore wrote: > > Bengt, > I had a look at this change also. I would pick ResourceObj over > ValueObj for the ArrayAllocator class. ValueObj really is embedded > and is used very consistently, and ResourceObj is usually used for > mixed cases like this. Is there some complication to using ResourceObj? Now I'm confused. I'm fine with switching to ResourceObj, but I thought that was supposed to be a way of tagging objects that should be allocated in resource areas. Here is the comment in allocation.hpp that I am using as a reference: // For objects allocated in the resource area (see resourceArea.hpp). // - ResourceObj // // For objects allocated in the C-heap (managed by: free & malloc). // - CHeapObj // // For objects allocated on the stack. // - StackObj // // For embedded objects. // - ValueObj Currently ArrayAllocator is always embedded in another object, so I figured that David's point was valid that it should be a ValueObj. But for the ResourceObj class there is this comment: //---------------------------------------------------------------------- // Base class for objects allocated in the resource area per default. // Optionally, objects may be allocated on the C heap with // new(ResourceObj::C_HEAP) Foo(...) or in an Arena with new (&arena) // ResourceObj's can be allocated within other objects, but don't use // new or delete (allocation_type is unknown). If new is used to allocate, // use delete to deallocate. Which, I guess says that a ResourceObj can be used for pretty much anything. If that is right, what is the point of having the ResourceObj class? Thanks, Bengt > > Thanks, > Coleen > > > On 06/18/2013 12:57 AM, David Holmes wrote: >> Reviewed. >> >> Thanks. >> >> David >> >> On 18/06/2013 2:50 PM, Bengt Rutisson wrote: >>> On 6/18/13 5:34 AM, David Holmes wrote: >>>> Seems reasonable to me. >>> >>> Thanks, David! >>> >>> BTW, I am not sure if you reviewed the whole change or just >>> commented on >>> the StackObj vs. ValueObj issue. Can I list you as a reviewer of the >>> change? >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 17/06/2013 4:17 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi David, >>>>> >>>>> On 6/17/13 5:23 AM, David Holmes wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> I don't think it makes sense to embed a StackObj into a ValueObj! >>>>>> But >>>>>> then why is ArrayAllocator a StackObj? The only existing use of it I >>>>>> can see also embeds it! So seems to me it should be a ValueObj in >>>>>> the >>>>>> first place. >>>>> >>>>> Good point. I changed ArrayAllocator to be a ValueObj instead. New >>>>> webrev here: >>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >>>>> >>>>> Here is the diff compared to the last version: >>>>> >>>>> diff --git a/src/share/vm/memory/allocation.hpp >>>>> b/src/share/vm/memory/allocation.hpp >>>>> --- a/src/share/vm/memory/allocation.hpp >>>>> +++ b/src/share/vm/memory/allocation.hpp >>>>> @@ -665,7 +665,7 @@ >>>>> // is set so that we always use malloc except for Solaris where >>>>> we set >>>>> the >>>>> // limit to get mapped memory. >>>>> template >>>>> -class ArrayAllocator : public StackObj { >>>>> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >>>>> char* _addr; >>>>> bool _use_malloc; >>>>> size_t _size; >>>>> >>>>> >>>>> Thanks for looking at this! >>>>> Bengt >>>>> >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> Could I have a couple of review for this small change? >>>>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>>>>> >>>>>>> Sending this request to the broad hotspot dev mailing list since it >>>>>>> touches code in vm/utilities. >>>>>>> >>>>>>> Background: >>>>>>> >>>>>>> In the constructor for the ConcurrentMark class in G1 we set up one >>>>>>> bit >>>>>>> map per worker thread: >>>>>>> >>>>>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>>>>> ... >>>>>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> Each of these bitmaps are malloced, which means that the amount of >>>>>>> C-heap we require grows with the number of GC worker threads we >>>>>>> have. On >>>>>>> a machine with many CPUs we get many worker threads by default. For >>>>>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>>>>> bitmaps >>>>>>> also scale with the heap size. Since this large machine has a >>>>>>> lot of >>>>>>> memory we get a large default heap as well. >>>>>>> >>>>>>> Here is the output from just running java -version with G1 on >>>>>>> scaaa007: >>>>>>> >>>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>>> java version "1.8.0-ea-fastdebug" >>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>>>>>> mode) >>>>>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB >>>>>>> resrc >>>>>>> >>>>>>> We malloc 221MB just by starting the VM. Most of the large >>>>>>> allocations >>>>>>> are due to the BitMap allocations. My patch changes the BitMap >>>>>>> allocations to use the ArrayAllocator instead. That class uses >>>>>>> mmap on >>>>>>> Solaris if the size is larger than 64K. >>>>>>> >>>>>>> With this patch the output looks like this: >>>>>>> >>>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>>> java version "1.8.0-ea-fastdebug" >>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, >>>>>>> mixed >>>>>>> mode) >>>>>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB >>>>>>> resrc >>>>>>> >>>>>>> We are down to 31MB. >>>>>>> >>>>>>> Note that the ArrayAllocator only has this effect on Solaris >>>>>>> machines. >>>>>>> Also note that I have not reduced the total amount of memory, just >>>>>>> moved >>>>>>> it from the C-heap to mapped memory. >>>>>>> >>>>>>> One complication with the fix is that the BitMap data structures >>>>>>> get >>>>>>> copied around quite a bit. The copies are shallow copies, so we >>>>>>> don't >>>>>>> risk re-doing the allocation. But since I am now embedding an >>>>>>> ArrayAllocator in the BitMap structure the destructor for copies of >>>>>>> the >>>>>>> ArrayAllocator gets called every now and then. The BitMap >>>>>>> explicitly >>>>>>> frees up the allocated memory when it thinks it is necessary. So, >>>>>>> rather >>>>>>> than trying to refactor the code to avoid copying I made it >>>>>>> optional to >>>>>>> free the allocated memory in the ArrayAllocator desctructor. >>>>>>> >>>>>>> I do think it would be good to review the BitMap code. It seems >>>>>>> a bit >>>>>>> fishy that we pass around shallow copies. But I think my current >>>>>>> change >>>>>>> keeps the same behavior as before. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>> >>> > From coleen.phillimore at oracle.com Tue Jun 18 07:41:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 18 Jun 2013 10:41:17 -0400 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51C06F5B.9090007@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51BFD559.8040908@oracle.com> <51BFE726.8010903@oracle.com> <51BFE8AD.8080504@oracle.com> <51C05EE3.1010808@oracle.com> <51C06F5B.9090007@oracle.com> Message-ID: <51C0718D.7000009@oracle.com> On 06/18/2013 10:31 AM, Bengt Rutisson wrote: > > Hi Coleen, > > Thanks for looking at this! > > On 6/18/13 3:21 PM, Coleen Phillimore wrote: >> >> Bengt, >> I had a look at this change also. I would pick ResourceObj over >> ValueObj for the ArrayAllocator class. ValueObj really is embedded >> and is used very consistently, and ResourceObj is usually used for >> mixed cases like this. Is there some complication to using >> ResourceObj? > > Now I'm confused. > > I'm fine with switching to ResourceObj, but I thought that was > supposed to be a way of tagging objects that should be allocated in > resource areas. Here is the comment in allocation.hpp that I am using > as a reference: > > // For objects allocated in the resource area (see resourceArea.hpp). > // - ResourceObj > // > // For objects allocated in the C-heap (managed by: free & malloc). > // - CHeapObj > // > // For objects allocated on the stack. > // - StackObj > // > // For embedded objects. > // - ValueObj > > > Currently ArrayAllocator is always embedded in another object, so I > figured that David's point was valid that it should be a ValueObj. Oh, yes, you are right. I didn't know this. ValueObj is correct for ArrayAllocator if they are embedded in other objects. I got confused by the class vs. what it did. > But for the ResourceObj class there is this comment: > > //---------------------------------------------------------------------- > // Base class for objects allocated in the resource area per default. > // Optionally, objects may be allocated on the C heap with > // new(ResourceObj::C_HEAP) Foo(...) or in an Arena with new (&arena) > // ResourceObj's can be allocated within other objects, but don't use > // new or delete (allocation_type is unknown). If new is used to > allocate, > // use delete to deallocate. > > Which, I guess says that a ResourceObj can be used for pretty much > anything. If that is right, what is the point of having the > ResourceObj class? It is useful because it describes the normal case, but it can deal with exceptions. We have a few exceptions. I thought this was one but it's not. Sorry for the noise. Coleen > > Thanks, > Bengt > >> >> Thanks, >> Coleen >> >> >> On 06/18/2013 12:57 AM, David Holmes wrote: >>> Reviewed. >>> >>> Thanks. >>> >>> David >>> >>> On 18/06/2013 2:50 PM, Bengt Rutisson wrote: >>>> On 6/18/13 5:34 AM, David Holmes wrote: >>>>> Seems reasonable to me. >>>> >>>> Thanks, David! >>>> >>>> BTW, I am not sure if you reviewed the whole change or just >>>> commented on >>>> the StackObj vs. ValueObj issue. Can I list you as a reviewer of the >>>> change? >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 17/06/2013 4:17 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> On 6/17/13 5:23 AM, David Holmes wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> I don't think it makes sense to embed a StackObj into a >>>>>>> ValueObj! But >>>>>>> then why is ArrayAllocator a StackObj? The only existing use of >>>>>>> it I >>>>>>> can see also embeds it! So seems to me it should be a ValueObj >>>>>>> in the >>>>>>> first place. >>>>>> >>>>>> Good point. I changed ArrayAllocator to be a ValueObj instead. New >>>>>> webrev here: >>>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >>>>>> >>>>>> Here is the diff compared to the last version: >>>>>> >>>>>> diff --git a/src/share/vm/memory/allocation.hpp >>>>>> b/src/share/vm/memory/allocation.hpp >>>>>> --- a/src/share/vm/memory/allocation.hpp >>>>>> +++ b/src/share/vm/memory/allocation.hpp >>>>>> @@ -665,7 +665,7 @@ >>>>>> // is set so that we always use malloc except for Solaris where >>>>>> we set >>>>>> the >>>>>> // limit to get mapped memory. >>>>>> template >>>>>> -class ArrayAllocator : public StackObj { >>>>>> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >>>>>> char* _addr; >>>>>> bool _use_malloc; >>>>>> size_t _size; >>>>>> >>>>>> >>>>>> Thanks for looking at this! >>>>>> Bengt >>>>>> >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> Could I have a couple of review for this small change? >>>>>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>>>>>> >>>>>>>> Sending this request to the broad hotspot dev mailing list >>>>>>>> since it >>>>>>>> touches code in vm/utilities. >>>>>>>> >>>>>>>> Background: >>>>>>>> >>>>>>>> In the constructor for the ConcurrentMark class in G1 we set up >>>>>>>> one >>>>>>>> bit >>>>>>>> map per worker thread: >>>>>>>> >>>>>>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>>>>>> ... >>>>>>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> Each of these bitmaps are malloced, which means that the amount of >>>>>>>> C-heap we require grows with the number of GC worker threads we >>>>>>>> have. On >>>>>>>> a machine with many CPUs we get many worker threads by default. >>>>>>>> For >>>>>>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>>>>>> bitmaps >>>>>>>> also scale with the heap size. Since this large machine has a >>>>>>>> lot of >>>>>>>> memory we get a large default heap as well. >>>>>>>> >>>>>>>> Here is the output from just running java -version with G1 on >>>>>>>> scaaa007: >>>>>>>> >>>>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>>>> java version "1.8.0-ea-fastdebug" >>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>>>>>>> mode) >>>>>>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), >>>>>>>> 35MB resrc >>>>>>>> >>>>>>>> We malloc 221MB just by starting the VM. Most of the large >>>>>>>> allocations >>>>>>>> are due to the BitMap allocations. My patch changes the BitMap >>>>>>>> allocations to use the ArrayAllocator instead. That class uses >>>>>>>> mmap on >>>>>>>> Solaris if the size is larger than 64K. >>>>>>>> >>>>>>>> With this patch the output looks like this: >>>>>>>> >>>>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>>>> java version "1.8.0-ea-fastdebug" >>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed >>>>>>>> >>>>>>>> mode) >>>>>>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB >>>>>>>> resrc >>>>>>>> >>>>>>>> We are down to 31MB. >>>>>>>> >>>>>>>> Note that the ArrayAllocator only has this effect on Solaris >>>>>>>> machines. >>>>>>>> Also note that I have not reduced the total amount of memory, just >>>>>>>> moved >>>>>>>> it from the C-heap to mapped memory. >>>>>>>> >>>>>>>> One complication with the fix is that the BitMap data >>>>>>>> structures get >>>>>>>> copied around quite a bit. The copies are shallow copies, so we >>>>>>>> don't >>>>>>>> risk re-doing the allocation. But since I am now embedding an >>>>>>>> ArrayAllocator in the BitMap structure the destructor for >>>>>>>> copies of >>>>>>>> the >>>>>>>> ArrayAllocator gets called every now and then. The BitMap >>>>>>>> explicitly >>>>>>>> frees up the allocated memory when it thinks it is necessary. So, >>>>>>>> rather >>>>>>>> than trying to refactor the code to avoid copying I made it >>>>>>>> optional to >>>>>>>> free the allocated memory in the ArrayAllocator desctructor. >>>>>>>> >>>>>>>> I do think it would be good to review the BitMap code. It seems >>>>>>>> a bit >>>>>>>> fishy that we pass around shallow copies. But I think my current >>>>>>>> change >>>>>>>> keeps the same behavior as before. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>> >>>> >> > From christian.thalinger at oracle.com Tue Jun 18 09:59:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Jun 2013 09:59:25 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> Message-ID: <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: > Hi, > > We have it on these platforms: > ia64 (nt, linux, hp_ux) > parisc (hp_ux) > zArch (linux) > ppc (aix, linux) > > I would implement it on x86 & friends, you do it on sparc and wherever > else you like it? That sounds reasonable. Are we pushing this to the ppc repository then? -- Chris > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 18. Juni 2013 07:13 > To: Volker Simonis > Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: > >> Hi Goetz, >> >> I think the change is good and if the other reviewers don't decide to >> implement it for the current platforms we can push it. > > I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? > > -- Chris > >> >> By the way, the makefile changes in ppc64.make will follow in patch 8 for >> linux [1] and patch 14 for aix [2]. >> The implementation of the stubs will be in patch 9 for linux [3] and patch >> 15 for aix [4] (only the signal handling part). >> >> Regards, >> Volker >> >> [1] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >> [2] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >> [3] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >> [4] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >> >> >> >> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >> goetz.lindenmaier at sap.com> wrote: >> >>> Hi,**** >>> >>> ** ** >>> >>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>> >>> have problems with inline assembly, especially with non-gcc**** >>> >>> compilers. Stub routines allow to implement safefetch without**** >>> >>> depending on OS or compiler, as it's the case with the current**** >>> >>> implementation. This also allows to use a single implementation if an**** >>> >>> architecture is supported on several os platforms.**** >>> >>> ** ** >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>> >>> ** ** >>> >>> Currently, we guard the code with **** >>> >>> #ifdef SAFEFETCH_STUBS**** >>> >>> which is set in ppc64.make.**** >>> >>> ** ** >>> >>> I could also imagine an implementation that uses a pd_debug flag**** >>> >>> or a const flag set in os_.hpp that allows the C-compiler to **** >>> >>> optimize, and writing the code like this:**** >>> >>> ** ** >>> >>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>> >>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>> * >>> >>> inline int SafeFetch32(int* adr, int errValue) {**** >>> >>> if (UseSafefetchStub) {**** >>> >>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>> * >>> >>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>> >>> } else {**** >>> >>> pd_SafeFetch32(adr, errValue);**** >>> >>> }**** >>> >>> }**** >>> >>> ** ** >>> >>> Unfortunately this requires **** >>> >>> 1) setting the flag on all platforms**** >>> >>> 2) renaming the safefetch function on all platfoms.**** >>> >>> ** ** >>> >>> Actually I would prefer this second solution as it avoids the >>> preprocessor, **** >>> >>> and am happy to edit the sources accordingly if this finds acceptance.**** >>> >>> ** ** >>> >>> For the implementation of a safefetch_stub see**** >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>> **** >>> >>> ** ** >>> >>> Could I get a review on this change, please?**** >>> >>> ** ** >>> >>> Thanks,**** >>> >>> Goetz.**** >>> > From bengt.rutisson at oracle.com Tue Jun 18 11:43:27 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Tue, 18 Jun 2013 18:43:27 +0000 Subject: hg: hsx/hsx24/hotspot: 8012265: VM often crashes on solaris with a lot of memory Message-ID: <20130618184329.46F13482C4@hg.openjdk.java.net> Changeset: f65b000853c7 Author: brutisso Date: 2013-06-14 08:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f65b000853c7 8012265: VM often crashes on solaris with a lot of memory Summary: Increase HeapBaseMinAddress for G1 from 256m to 1g on Solaris x86 Reviewed-by: mgerdin, coleenp, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp From john.r.rose at oracle.com Tue Jun 18 12:40:15 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 18 Jun 2013 12:40:15 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51C01C1D.6040205@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> Message-ID: <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart wrote: > This change is consuming the last unused relocType (yet_unused_type_2) > > Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) > > This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. The relocInfo records are stored as an array of unsigned shorts (u2). This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space. At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation. That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude. For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable. The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost. The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width. The variability could be encoded in the tag field itself (Huffman style, right-to-left): type_width = 4, type_width_2 = 6, type_width_2_mask = 0x0003, ... bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; } ... ? John P.S. Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing. It is somewhat fragile and (I now think) over-clever. This is another thing I would like to change about the relocinfo mechanism, if it were rewritten. Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language. From john.cuthbertson at oracle.com Tue Jun 18 12:41:49 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 18 Jun 2013 12:41:49 -0700 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51BEA9E7.1030503@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> Message-ID: <51C0B7FD.6020202@oracle.com> Hi Bengt, The latest webrev looks good to me. Sorry for being late. JohnC On 6/16/2013 11:17 PM, Bengt Rutisson wrote: > > Hi David, > > On 6/17/13 5:23 AM, David Holmes wrote: >> Hi Bengt, >> >> I don't think it makes sense to embed a StackObj into a ValueObj! But >> then why is ArrayAllocator a StackObj? The only existing use of it I >> can see also embeds it! So seems to me it should be a ValueObj in the >> first place. > > Good point. I changed ArrayAllocator to be a ValueObj instead. New > webrev here: > http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ > > Here is the diff compared to the last version: > > diff --git a/src/share/vm/memory/allocation.hpp > b/src/share/vm/memory/allocation.hpp > --- a/src/share/vm/memory/allocation.hpp > +++ b/src/share/vm/memory/allocation.hpp > @@ -665,7 +665,7 @@ > // is set so that we always use malloc except for Solaris where we > set the > // limit to get mapped memory. > template > -class ArrayAllocator : public StackObj { > +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { > char* _addr; > bool _use_malloc; > size_t _size; > > > Thanks for looking at this! > Bengt > > >> >> David >> >> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Could I have a couple of review for this small change? >>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>> >>> Sending this request to the broad hotspot dev mailing list since it >>> touches code in vm/utilities. >>> >>> Background: >>> >>> In the constructor for the ConcurrentMark class in G1 we set up one bit >>> map per worker thread: >>> >>> for (uint i = 0; i < _max_worker_id; ++i) { >>> ... >>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>> ... >>> } >>> >>> Each of these bitmaps are malloced, which means that the amount of >>> C-heap we require grows with the number of GC worker threads we >>> have. On >>> a machine with many CPUs we get many worker threads by default. For >>> example, on scaaa007 I get 79 GC worker threads. The size of the >>> bitmaps >>> also scale with the heap size. Since this large machine has a lot of >>> memory we get a large default heap as well. >>> >>> Here is the output from just running java -version with G1 on scaaa007: >>> >>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>> java version "1.8.0-ea-fastdebug" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>> mode) >>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc >>> >>> We malloc 221MB just by starting the VM. Most of the large allocations >>> are due to the BitMap allocations. My patch changes the BitMap >>> allocations to use the ArrayAllocator instead. That class uses mmap on >>> Solaris if the size is larger than 64K. >>> >>> With this patch the output looks like this: >>> >>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>> java version "1.8.0-ea-fastdebug" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>> Java HotSpot(TM) 64-Bit Server VM (build >>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed >>> mode) >>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc >>> >>> We are down to 31MB. >>> >>> Note that the ArrayAllocator only has this effect on Solaris machines. >>> Also note that I have not reduced the total amount of memory, just >>> moved >>> it from the C-heap to mapped memory. >>> >>> One complication with the fix is that the BitMap data structures get >>> copied around quite a bit. The copies are shallow copies, so we don't >>> risk re-doing the allocation. But since I am now embedding an >>> ArrayAllocator in the BitMap structure the destructor for copies of the >>> ArrayAllocator gets called every now and then. The BitMap explicitly >>> frees up the allocated memory when it thinks it is necessary. So, >>> rather >>> than trying to refactor the code to avoid copying I made it optional to >>> free the allocated memory in the ArrayAllocator desctructor. >>> >>> I do think it would be good to review the BitMap code. It seems a bit >>> fishy that we pass around shallow copies. But I think my current change >>> keeps the same behavior as before. >>> >>> Thanks, >>> Bengt > From goetz.lindenmaier at sap.com Tue Jun 18 13:18:38 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 18 Jun 2013 20:18:38 +0000 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> Ok, I will implement it on x86. To get a single change, you can give me the sparc patch, or you extend the webrev once I updated it with the x86 code. If you prefer, you can also push it to some other repository, it will end up in the ppc repo in time I guess. Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Tuesday, June 18, 2013 6:59 PM To: Lindenmaier, Goetz Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: > Hi, > > We have it on these platforms: > ia64 (nt, linux, hp_ux) > parisc (hp_ux) > zArch (linux) > ppc (aix, linux) > > I would implement it on x86 & friends, you do it on sparc and wherever > else you like it? That sounds reasonable. Are we pushing this to the ppc repository then? -- Chris > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 18. Juni 2013 07:13 > To: Volker Simonis > Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: > >> Hi Goetz, >> >> I think the change is good and if the other reviewers don't decide to >> implement it for the current platforms we can push it. > > I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? > > -- Chris > >> >> By the way, the makefile changes in ppc64.make will follow in patch 8 for >> linux [1] and patch 14 for aix [2]. >> The implementation of the stubs will be in patch 9 for linux [3] and patch >> 15 for aix [4] (only the signal handling part). >> >> Regards, >> Volker >> >> [1] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >> [2] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >> [3] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >> [4] >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >> >> >> >> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >> goetz.lindenmaier at sap.com> wrote: >> >>> Hi,**** >>> >>> ** ** >>> >>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>> >>> have problems with inline assembly, especially with non-gcc**** >>> >>> compilers. Stub routines allow to implement safefetch without**** >>> >>> depending on OS or compiler, as it's the case with the current**** >>> >>> implementation. This also allows to use a single implementation if an**** >>> >>> architecture is supported on several os platforms.**** >>> >>> ** ** >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>> >>> ** ** >>> >>> Currently, we guard the code with **** >>> >>> #ifdef SAFEFETCH_STUBS**** >>> >>> which is set in ppc64.make.**** >>> >>> ** ** >>> >>> I could also imagine an implementation that uses a pd_debug flag**** >>> >>> or a const flag set in os_.hpp that allows the C-compiler to **** >>> >>> optimize, and writing the code like this:**** >>> >>> ** ** >>> >>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>> >>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>> * >>> >>> inline int SafeFetch32(int* adr, int errValue) {**** >>> >>> if (UseSafefetchStub) {**** >>> >>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>> * >>> >>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>> >>> } else {**** >>> >>> pd_SafeFetch32(adr, errValue);**** >>> >>> }**** >>> >>> }**** >>> >>> ** ** >>> >>> Unfortunately this requires **** >>> >>> 1) setting the flag on all platforms**** >>> >>> 2) renaming the safefetch function on all platfoms.**** >>> >>> ** ** >>> >>> Actually I would prefer this second solution as it avoids the >>> preprocessor, **** >>> >>> and am happy to edit the sources accordingly if this finds acceptance.**** >>> >>> ** ** >>> >>> For the implementation of a safefetch_stub see**** >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>> **** >>> >>> ** ** >>> >>> Could I get a review on this change, please?**** >>> >>> ** ** >>> >>> Thanks,**** >>> >>> Goetz.**** >>> > From christian.thalinger at oracle.com Tue Jun 18 13:44:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Jun 2013 13:44:14 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> Message-ID: On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" wrote: > Ok, I will implement it on x86. > > To get a single change, you can give me the sparc patch, > or you extend the webrev once I updated it with the > x86 code. Sounds good. Let me know when it's there. -- Chris > If you prefer, you can also push it to some other repository, it > will end up in the ppc repo in time I guess. > > Best regards, > Goetz. > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Tuesday, June 18, 2013 6:59 PM > To: Lindenmaier, Goetz > Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> We have it on these platforms: >> ia64 (nt, linux, hp_ux) >> parisc (hp_ux) >> zArch (linux) >> ppc (aix, linux) >> >> I would implement it on x86 & friends, you do it on sparc and wherever >> else you like it? > > That sounds reasonable. Are we pushing this to the ppc repository then? > > -- Chris > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 18. Juni 2013 07:13 >> To: Volker Simonis >> Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >> >> >> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: >> >>> Hi Goetz, >>> >>> I think the change is good and if the other reviewers don't decide to >>> implement it for the current platforms we can push it. >> >> I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? >> >> -- Chris >> >>> >>> By the way, the makefile changes in ppc64.make will follow in patch 8 for >>> linux [1] and patch 14 for aix [2]. >>> The implementation of the stubs will be in patch 9 for linux [3] and patch >>> 15 for aix [4] (only the signal handling part). >>> >>> Regards, >>> Volker >>> >>> [1] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>> [2] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>> [3] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>> [4] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>> >>> >>> >>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>> goetz.lindenmaier at sap.com> wrote: >>> >>>> Hi,**** >>>> >>>> ** ** >>>> >>>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>>> >>>> have problems with inline assembly, especially with non-gcc**** >>>> >>>> compilers. Stub routines allow to implement safefetch without**** >>>> >>>> depending on OS or compiler, as it's the case with the current**** >>>> >>>> implementation. This also allows to use a single implementation if an**** >>>> >>>> architecture is supported on several os platforms.**** >>>> >>>> ** ** >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>> >>>> ** ** >>>> >>>> Currently, we guard the code with **** >>>> >>>> #ifdef SAFEFETCH_STUBS**** >>>> >>>> which is set in ppc64.make.**** >>>> >>>> ** ** >>>> >>>> I could also imagine an implementation that uses a pd_debug flag**** >>>> >>>> or a const flag set in os_.hpp that allows the C-compiler to **** >>>> >>>> optimize, and writing the code like this:**** >>>> >>>> ** ** >>>> >>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>> >>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>>> * >>>> >>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>> >>>> if (UseSafefetchStub) {**** >>>> >>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>>> * >>>> >>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>> >>>> } else {**** >>>> >>>> pd_SafeFetch32(adr, errValue);**** >>>> >>>> }**** >>>> >>>> }**** >>>> >>>> ** ** >>>> >>>> Unfortunately this requires **** >>>> >>>> 1) setting the flag on all platforms**** >>>> >>>> 2) renaming the safefetch function on all platfoms.**** >>>> >>>> ** ** >>>> >>>> Actually I would prefer this second solution as it avoids the >>>> preprocessor, **** >>>> >>>> and am happy to edit the sources accordingly if this finds acceptance.**** >>>> >>>> ** ** >>>> >>>> For the implementation of a safefetch_stub see**** >>>> >>>> >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>> **** >>>> >>>> ** ** >>>> >>>> Could I get a review on this change, please?**** >>>> >>>> ** ** >>>> >>>> Thanks,**** >>>> >>>> Goetz.**** >>>> >> > From bengt.rutisson at oracle.com Tue Jun 18 13:52:37 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Jun 2013 22:52:37 +0200 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51C0718D.7000009@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51BFD559.8040908@oracle.com> <51BFE726.8010903@oracle.com> <51BFE8AD.8080504@oracle.com> <51C05EE3.1010808@oracle.com> <51C06F5B.9090007@oracle.com> <51C0718D.7000009@oracle.com> Message-ID: <51C0C895.8090301@oracle.com> On 6/18/13 4:41 PM, Coleen Phillimore wrote: > > On 06/18/2013 10:31 AM, Bengt Rutisson wrote: >> >> Hi Coleen, >> >> Thanks for looking at this! >> >> On 6/18/13 3:21 PM, Coleen Phillimore wrote: >>> >>> Bengt, >>> I had a look at this change also. I would pick ResourceObj over >>> ValueObj for the ArrayAllocator class. ValueObj really is embedded >>> and is used very consistently, and ResourceObj is usually used for >>> mixed cases like this. Is there some complication to using >>> ResourceObj? >> >> Now I'm confused. >> >> I'm fine with switching to ResourceObj, but I thought that was >> supposed to be a way of tagging objects that should be allocated in >> resource areas. Here is the comment in allocation.hpp that I am using >> as a reference: >> >> // For objects allocated in the resource area (see resourceArea.hpp). >> // - ResourceObj >> // >> // For objects allocated in the C-heap (managed by: free & malloc). >> // - CHeapObj >> // >> // For objects allocated on the stack. >> // - StackObj >> // >> // For embedded objects. >> // - ValueObj >> >> >> Currently ArrayAllocator is always embedded in another object, so I >> figured that David's point was valid that it should be a ValueObj. > > Oh, yes, you are right. I didn't know this. ValueObj is correct for > ArrayAllocator if they are embedded in other objects. I got confused > by the class vs. what it did. OK. Good. :) > >> But for the ResourceObj class there is this comment: >> >> //---------------------------------------------------------------------- >> // Base class for objects allocated in the resource area per default. >> // Optionally, objects may be allocated on the C heap with >> // new(ResourceObj::C_HEAP) Foo(...) or in an Arena with new (&arena) >> // ResourceObj's can be allocated within other objects, but don't use >> // new or delete (allocation_type is unknown). If new is used to >> allocate, >> // use delete to deallocate. >> >> Which, I guess says that a ResourceObj can be used for pretty much >> anything. If that is right, what is the point of having the >> ResourceObj class? > > It is useful because it describes the normal case, but it can deal > with exceptions. We have a few exceptions. I thought this was one > but it's not. Sorry for the noise. Thanks again for looking at this change! Bengt > > Coleen > >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Coleen >>> >>> >>> On 06/18/2013 12:57 AM, David Holmes wrote: >>>> Reviewed. >>>> >>>> Thanks. >>>> >>>> David >>>> >>>> On 18/06/2013 2:50 PM, Bengt Rutisson wrote: >>>>> On 6/18/13 5:34 AM, David Holmes wrote: >>>>>> Seems reasonable to me. >>>>> >>>>> Thanks, David! >>>>> >>>>> BTW, I am not sure if you reviewed the whole change or just >>>>> commented on >>>>> the StackObj vs. ValueObj issue. Can I list you as a reviewer of the >>>>> change? >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 17/06/2013 4:17 PM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> On 6/17/13 5:23 AM, David Holmes wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> I don't think it makes sense to embed a StackObj into a >>>>>>>> ValueObj! But >>>>>>>> then why is ArrayAllocator a StackObj? The only existing use of >>>>>>>> it I >>>>>>>> can see also embeds it! So seems to me it should be a ValueObj >>>>>>>> in the >>>>>>>> first place. >>>>>>> >>>>>>> Good point. I changed ArrayAllocator to be a ValueObj instead. New >>>>>>> webrev here: >>>>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >>>>>>> >>>>>>> Here is the diff compared to the last version: >>>>>>> >>>>>>> diff --git a/src/share/vm/memory/allocation.hpp >>>>>>> b/src/share/vm/memory/allocation.hpp >>>>>>> --- a/src/share/vm/memory/allocation.hpp >>>>>>> +++ b/src/share/vm/memory/allocation.hpp >>>>>>> @@ -665,7 +665,7 @@ >>>>>>> // is set so that we always use malloc except for Solaris >>>>>>> where we set >>>>>>> the >>>>>>> // limit to get mapped memory. >>>>>>> template >>>>>>> -class ArrayAllocator : public StackObj { >>>>>>> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >>>>>>> char* _addr; >>>>>>> bool _use_malloc; >>>>>>> size_t _size; >>>>>>> >>>>>>> >>>>>>> Thanks for looking at this! >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> Could I have a couple of review for this small change? >>>>>>>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>>>>>>> >>>>>>>>> Sending this request to the broad hotspot dev mailing list >>>>>>>>> since it >>>>>>>>> touches code in vm/utilities. >>>>>>>>> >>>>>>>>> Background: >>>>>>>>> >>>>>>>>> In the constructor for the ConcurrentMark class in G1 we set >>>>>>>>> up one >>>>>>>>> bit >>>>>>>>> map per worker thread: >>>>>>>>> >>>>>>>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>>>>>>> ... >>>>>>>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> >>>>>>>>> Each of these bitmaps are malloced, which means that the >>>>>>>>> amount of >>>>>>>>> C-heap we require grows with the number of GC worker threads we >>>>>>>>> have. On >>>>>>>>> a machine with many CPUs we get many worker threads by >>>>>>>>> default. For >>>>>>>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>>>>>>> bitmaps >>>>>>>>> also scale with the heap size. Since this large machine has a >>>>>>>>> lot of >>>>>>>>> memory we get a large default heap as well. >>>>>>>>> >>>>>>>>> Here is the output from just running java -version with G1 on >>>>>>>>> scaaa007: >>>>>>>>> >>>>>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>>>>> java version "1.8.0-ea-fastdebug" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, >>>>>>>>> mixed >>>>>>>>> mode) >>>>>>>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), >>>>>>>>> 35MB resrc >>>>>>>>> >>>>>>>>> We malloc 221MB just by starting the VM. Most of the large >>>>>>>>> allocations >>>>>>>>> are due to the BitMap allocations. My patch changes the BitMap >>>>>>>>> allocations to use the ArrayAllocator instead. That class uses >>>>>>>>> mmap on >>>>>>>>> Solaris if the size is larger than 64K. >>>>>>>>> >>>>>>>>> With this patch the output looks like this: >>>>>>>>> >>>>>>>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>>>>>>> java version "1.8.0-ea-fastdebug" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, >>>>>>>>> mixed >>>>>>>>> mode) >>>>>>>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), >>>>>>>>> 35MB resrc >>>>>>>>> >>>>>>>>> We are down to 31MB. >>>>>>>>> >>>>>>>>> Note that the ArrayAllocator only has this effect on Solaris >>>>>>>>> machines. >>>>>>>>> Also note that I have not reduced the total amount of memory, >>>>>>>>> just >>>>>>>>> moved >>>>>>>>> it from the C-heap to mapped memory. >>>>>>>>> >>>>>>>>> One complication with the fix is that the BitMap data >>>>>>>>> structures get >>>>>>>>> copied around quite a bit. The copies are shallow copies, so >>>>>>>>> we don't >>>>>>>>> risk re-doing the allocation. But since I am now embedding an >>>>>>>>> ArrayAllocator in the BitMap structure the destructor for >>>>>>>>> copies of >>>>>>>>> the >>>>>>>>> ArrayAllocator gets called every now and then. The BitMap >>>>>>>>> explicitly >>>>>>>>> frees up the allocated memory when it thinks it is necessary. So, >>>>>>>>> rather >>>>>>>>> than trying to refactor the code to avoid copying I made it >>>>>>>>> optional to >>>>>>>>> free the allocated memory in the ArrayAllocator desctructor. >>>>>>>>> >>>>>>>>> I do think it would be good to review the BitMap code. It >>>>>>>>> seems a bit >>>>>>>>> fishy that we pass around shallow copies. But I think my current >>>>>>>>> change >>>>>>>>> keeps the same behavior as before. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>> >>>>> >>> >> > From bengt.rutisson at oracle.com Tue Jun 18 13:52:58 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Jun 2013 22:52:58 +0200 Subject: RFR (S): G1: Use ArrayAllocator for BitMaps In-Reply-To: <51C0B7FD.6020202@oracle.com> References: <51B9DCEC.6050906@oracle.com> <51BE8121.8050101@oracle.com> <51BEA9E7.1030503@oracle.com> <51C0B7FD.6020202@oracle.com> Message-ID: <51C0C8AA.5050108@oracle.com> On 6/18/13 9:41 PM, John Cuthbertson wrote: > Hi Bengt, > > The latest webrev looks good to me. Sorry for being late. Thanks, John! Bengt > > JohnC > > On 6/16/2013 11:17 PM, Bengt Rutisson wrote: >> >> Hi David, >> >> On 6/17/13 5:23 AM, David Holmes wrote: >>> Hi Bengt, >>> >>> I don't think it makes sense to embed a StackObj into a ValueObj! >>> But then why is ArrayAllocator a StackObj? The only existing use of >>> it I can see also embeds it! So seems to me it should be a ValueObj >>> in the first place. >> >> Good point. I changed ArrayAllocator to be a ValueObj instead. New >> webrev here: >> http://cr.openjdk.java.net/~brutisso/8016556/webrev.01/ >> >> Here is the diff compared to the last version: >> >> diff --git a/src/share/vm/memory/allocation.hpp >> b/src/share/vm/memory/allocation.hpp >> --- a/src/share/vm/memory/allocation.hpp >> +++ b/src/share/vm/memory/allocation.hpp >> @@ -665,7 +665,7 @@ >> // is set so that we always use malloc except for Solaris where we >> set the >> // limit to get mapped memory. >> template >> -class ArrayAllocator : public StackObj { >> +class ArrayAllocator VALUE_OBJ_CLASS_SPEC { >> char* _addr; >> bool _use_malloc; >> size_t _size; >> >> >> Thanks for looking at this! >> Bengt >> >> >>> >>> David >>> >>> On 14/06/2013 12:53 AM, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> Could I have a couple of review for this small change? >>>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/ >>>> >>>> Sending this request to the broad hotspot dev mailing list since it >>>> touches code in vm/utilities. >>>> >>>> Background: >>>> >>>> In the constructor for the ConcurrentMark class in G1 we set up one >>>> bit >>>> map per worker thread: >>>> >>>> for (uint i = 0; i < _max_worker_id; ++i) { >>>> ... >>>> _count_card_bitmaps[i] = BitMap(card_bm_size, false); >>>> ... >>>> } >>>> >>>> Each of these bitmaps are malloced, which means that the amount of >>>> C-heap we require grows with the number of GC worker threads we >>>> have. On >>>> a machine with many CPUs we get many worker threads by default. For >>>> example, on scaaa007 I get 79 GC worker threads. The size of the >>>> bitmaps >>>> also scale with the heap size. Since this large machine has a lot of >>>> memory we get a large default heap as well. >>>> >>>> Here is the output from just running java -version with G1 on >>>> scaaa007: >>>> >>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>> java version "1.8.0-ea-fastdebug" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed >>>> mode) >>>> allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc >>>> >>>> We malloc 221MB just by starting the VM. Most of the large allocations >>>> are due to the BitMap allocations. My patch changes the BitMap >>>> allocations to use the ArrayAllocator instead. That class uses mmap on >>>> Solaris if the size is larger than 64K. >>>> >>>> With this patch the output looks like this: >>>> >>>> $ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version >>>> java version "1.8.0-ea-fastdebug" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93) >>>> Java HotSpot(TM) 64-Bit Server VM (build >>>> 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed >>>> mode) >>>> allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc >>>> >>>> We are down to 31MB. >>>> >>>> Note that the ArrayAllocator only has this effect on Solaris machines. >>>> Also note that I have not reduced the total amount of memory, just >>>> moved >>>> it from the C-heap to mapped memory. >>>> >>>> One complication with the fix is that the BitMap data structures get >>>> copied around quite a bit. The copies are shallow copies, so we don't >>>> risk re-doing the allocation. But since I am now embedding an >>>> ArrayAllocator in the BitMap structure the destructor for copies of >>>> the >>>> ArrayAllocator gets called every now and then. The BitMap explicitly >>>> frees up the allocated memory when it thinks it is necessary. So, >>>> rather >>>> than trying to refactor the code to avoid copying I made it >>>> optional to >>>> free the allocated memory in the ArrayAllocator desctructor. >>>> >>>> I do think it would be good to review the BitMap code. It seems a bit >>>> fishy that we pass around shallow copies. But I think my current >>>> change >>>> keeps the same behavior as before. >>>> >>>> Thanks, >>>> Bengt >> > From david.holmes at oracle.com Tue Jun 18 19:36:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Jun 2013 12:36:56 +1000 Subject: JEP 175 - Review comments In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> References: > <<26eeb84c-2abf-4ba2-8b12-2333b7651680@default> > <> <51AE38D0.6090301@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFCB936@DEWDFEMB12A.global.corp.sap> <51B75177.3020804@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFDA5FF@DEWDFEMB12A.global.corp.sap> Message-ID: <51C11948.4080005@oracle.com> Just for the record ... hotspot folk please note this thread is a continuation of a discussion that started on the ppc-aix-port-dev list: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-June/000525.html and of course there is a lot of discussion on that list if you need further details/background on things. David On 13/06/2013 12:44 AM, Lindenmaier, Goetz wrote: > Hi, > > With my recent changes I removed some of the problems Vladimir mentioned. > > I also added the patches queue I maintain into our jdk8/hotspot repository, > at hotspot/ppc_patches. > Applied to the staging hotspot directory, the linuxppc and aixppc hotspots > can be built. > > The queue contains the changes proposed by me before, with minor changes due > to recent development: > > 1-9 linuxppc C-interpreter port (In our plan milestone M2.1) > 11-15 aixppc C-interpreter port (In our plan milestone M2.2) > 101-107 C-interpreter improvements > 111-122 ppc C2 compiler port leading to a vm rudimentarily working > 200-217 C2 compiler fixes, extensions etc needed for a stable and > performant ppc port. > Altogether currently 49 changes. > > Our plan was to propose the changes in the order of the queue for > review. I'm happy to create webrevs for any of them. > > Vladimir, maybe the queue simplifies reviewing the port, as the changes > are more complete. They include all later improvements by fixes or > adaptions in merge changes. > For why and where I renamed PPC to PPC32 see the second change in the > queue. > > Best regards, > Goetz. > > > PS: This can be used as the invokedynamic repository: > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot ppc-hotspot > hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot stage-hotspot > cd stage-hotspot > ln -s .../ppc-hotspot/ppc_patches/ .hg/patches > hg qpush -a > > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 11. Juni 2013 18:34 > To: Lindenmaier, Goetz > Cc: Volker Simonis; Azeem Jiva; Chris Plummer > Subject: Re: JEP 175 - Review comments > > Here is result of my first attempt to build/test ppc changes together > with our closed sources. > > Small problems: > > src/share/vm/memory/allocation.hpp:209: Trailing whitespace > src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace > src/share/vm/opto/escape.cpp:2207: Trailing whitespace > src/share/vm/memory/allocation.hpp:212: Trailing whitespace > src/share/vm/opto/escape.cpp:2214: Trailing whitespace > > Build on MacOS: > > src/share/vm/opto/callGenerator.cpp: In member function 'virtual > JVMState* VirtualCallGenerator::generate(JVMState*)': > src/share/vm/opto/callGenerator.cpp:204: error: > 'zero_page_read_protected' is not a member of 'os' > > agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error UNSUPPORTED_ARCH > agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error UNSUPPORTED_ARCH > > > We have several conflict with closed sources builds: > > src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool > ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)': > src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between > signed and unsigned integer expressions > src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between > signed and unsigned integer expressions > > error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const' > member function declared in class 'frame' > > error: no matching function for call to > 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)' > > I think it is due to changes like next: > > -#ifdef PPC > +#ifdef PPC32 > oop* interpreter_frame_mirror_addr() const; > > > Next is easy fix in our closed sources but it requires efforts from our > side: > > src/share/vm/prims/methodHandles.cpp: In static member function 'static > void MethodHandles::generate_adapters()': > src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size' > cannot be used as a function > src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size' > cannot be used as a function > > > I would suggest to do such shared changes which affects different builds > later after initial push. > > > Thanks, > Vladimir > > On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I updated the repo to jdk8-b92. Our nightly tests built and >> tested it successfully. In case you experience any problems >> please tell me the details so I can fix them. >> >> Best regards, >> Goetz. >> >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 4. Juni 2013 20:58 >> To: Simonis, Volker >> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; Alan Bateman >> Subject: Re: JEP 175 - Review comments >> >> Volker, >> >> Can you or someone update >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest >> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot? >> I just tried to merge them and build Hotspot on x86 without success. >> >> Thanks, >> Vladimir >> >> On 6/4/13 7:04 AM, Simonis, Volker wrote: >>> >>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in the >>> beginning to address a broader audience for the initial discussions. >>> >>> But I'm happy to change that back to 'ppc-aix-port-dev' now. >>> >>> Regards, >>> Volker >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 3:50 PM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison; >>> iris.clark at oracle.com >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> Sorry about this, one more thing about the JEP... >>> >>> I think that the "Discussion" list probably needs to be updated to be >>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed >>> as porters-dev. >>> >>> Thanks, >>> >>> iris >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Tuesday, June 04, 2013 12:12 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi Iris, >>> >>> you're right, the title is too clumsy - I just couldn't come up with >>> something better yesterday in the evening. >>> >>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take it. >>> >>> Thanks, >>> Volker >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Tuesday, June 04, 2013 2:57 AM >>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com >>> >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> I've just updated the JEP according to your suggestions. >>> >>> I'm not a Reviewer however, I think that the phrase "OpenJDK master >>> repositories" in the revised title is not ideal: >>> >>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400 >>> >>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200 >>> >>> @@ -1,5 +1,5 @@ >>> >>> JEP: 175 >>> >>> -Title: Integrate PowerPC/AIX Port into JDK 8 >>> >>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master repositories >>> >>> Author: Volker Simonis >>> >>> Organization: SAP AG >>> >>> Created: 2013/1/11 >>> >>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all >>> about adding features to JDK Release Projects. There are lots of >>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode >>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains >>> additional details. >>> >>> Perhaps others have suggestions? >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> Yes. Once that field is populated, the value will appear in the JEP >>> index [1], see the third column. >>> >>> Thanks, >>> >>> Iris >>> >>> [1]: http://openjdk.java.net/jeps/0 >>> >>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com] >>> *Sent:* Monday, June 03, 2013 10:10 AM >>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* Alan Bateman; Vladimir Kozlov >>> *Subject:* RE: JEP 175 - Review comments >>> >>> Hi, >>> >>> I've just updated the JEP according to your suggestions. Please find >>> the new version attached to this mail (I haven't checked the new version >>> in until now to give everybody a chance to comment on the changes). >>> >>> Am I right with my assumption that the targeted release will still be >>> JDK 8 (or 9/8u respectively) but that the targeted release will be set >>> in the "Release" header field of the JEP by the OpenJDK Lead (as >>> specified in the JEP specification)? >>> >>> In addition to the changes proposed by you I've added the contents of >>> the "Approach" section from Azeems "PPCAIX plan" to the "Description" >>> section of the JEP. I've also added links to the new "PowerPC/AIX Port >>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3] >>> to the JEP. >>> >>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold >>> Azeems "PPCAIX plan" document. >>> >>> @Iris: could you please somehow arrange to give Azeem editing rights to >>> that page? >>> >>> @Azeem: could you please be so kind to past the contents of the "PPCAIX >>> plan" into that page (once you have the appropriate rights)? I saw that >>> the document is created from an Atlassian Confluence Wiki anyway and in >>> my unlimited naivety I imagine this could be a simple copy-and-paste >>> operation:) If that doesn't work so easily, please let me know how I >>> could help. >>> >>> If there are no objections I plan to checkin the new version of the JEP >>> tomorrow after our telephone call. >>> >>> Thank you and best regards, >>> Volker >>> >>> [2]: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 >>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Iris Clark [iris.clark at oracle.com] >>> *Sent:* Friday, May 31, 2013 8:48 PM >>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz; Bernard >>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael >>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com >>> ; Tim Ellison >>> *Cc:* iris.clark at oracle.com ; Alan >>> Bateman; Vladimir Kozlov >>> *Subject:* JEP 175 - Review comments >>> >>> Hi, Volker. >>> >>> JEP 175: Integrate PowerPC/AIX Port into JDK 8 >>> >>> http://openjdk.java.net/jeps/175 >>> >>> We're actively working to get your JEP to Funded. We had a few comments: >>> >>> -Recommend that "8" be removed from the JEP title, etc. >>> >>> -Recommend that the first Motivation bullet clearly indicate that it is >>> only covering PPC/AIX. >>> >>> -Recommend that the second Motivation bullet be modified to make it >>> clear that it applies to Hotspot only. >>> >>> (Instructions for editing the JEP may be found in the "Mechanics" >>> section at the bottom of JEP 1 [1].) >>> >>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to >>> be the JEP's reviewers. Once they're satisfied with your >>> changes/feedback they'll add themselves to the JEP's "Reviewed-by" line. >>> >>> Thanks, >>> >>> Iris Clark >>> >>> [1]: http://openjdk.java.net/jeps/1 >>> From bengt.rutisson at oracle.com Wed Jun 19 02:15:03 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 19 Jun 2013 09:15:03 +0000 Subject: hg: hsx/hsx24/hotspot: 8016556: G1: Use ArrayAllocator for BitMaps Message-ID: <20130619091508.D97794831B@hg.openjdk.java.net> Changeset: a51e6c9c3210 Author: brutisso Date: 2013-06-18 22:45 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a51e6c9c3210 8016556: G1: Use ArrayAllocator for BitMaps Reviewed-by: tschatzl, dholmes, coleenp, johnc ! src/share/vm/memory/allocation.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp From nils.loodin at oracle.com Wed Jun 19 12:17:25 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Wed, 19 Jun 2013 19:17:25 +0000 Subject: hg: hsx/hotspot-main/hotspot: 21 new changesets Message-ID: <20130619191812.05E594833F@hg.openjdk.java.net> Changeset: a837fa3d3f86 Author: dcubed Date: 2013-06-13 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a837fa3d3f86 8013057: assert(_needs_gc || SafepointSynchronize::is_at_safepoint()) failed: only read at safepoint Summary: Detect mmap() commit failures in Linux and Solaris os::commit_memory() impls and call vm_exit_out_of_memory(). Add os::commit_memory_or_exit(). Also tidy up some NMT accounting and some mmap() return value checking. Reviewed-by: zgu, stefank, dholmes, dsamersoff ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 2bffd20a0fcc Author: ctornqvi Date: 2013-06-13 21:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2bffd20a0fcc 8016065: Write regression test for 7167142 Summary: Regression tests written for both test cases (.hotspotrc and .hotspot_compiler). Also reviewed by mikhailo.seledtsov at oracle.com Reviewed-by: zgu, coleenp + test/runtime/CommandLine/CompilerConfigFileWarning.java + test/runtime/CommandLine/ConfigFileWarning.java Changeset: 1e9094165098 Author: ctornqvi Date: 2013-06-13 22:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1e9094165098 8015324: Create tests for CDS feature Summary: Wrote tests for use of CDS with ObjectAlignmentInBytes CL option Reviewed-by: coleenp, ctornqvi, hseigel Contributed-by: Mikhailo Seledtsov + test/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java + test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java + test/testlibrary/com/oracle/java/testlibrary/Platform.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: a0a47b2649a2 Author: ctornqvi Date: 2013-06-14 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a0a47b2649a2 Merge Changeset: ef57c43512d6 Author: ccheung Date: 2013-06-13 22:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ef57c43512d6 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux Reviewed-by: dholmes, coleenp Contributed-by: jeremymanson at google.com, calvin.cheung at oracle.com ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/genericSignatures.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: bcb96b2922f2 Author: zgu Date: 2013-06-14 07:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bcb96b2922f2 Merge Changeset: ab313d4e9a8b Author: zgu Date: 2013-06-14 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ab313d4e9a8b 8011968: Kitchensink crashed with SIGSEGV in MemBaseline::baseline Summary: Simple fix to add NULL pointer check that can cause segv Reviewed-by: coleenp, ctornqvi ! src/share/vm/services/memBaseline.cpp Changeset: dba2306ee2e3 Author: zgu Date: 2013-06-14 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dba2306ee2e3 Merge Changeset: 3aaa16611c30 Author: zgu Date: 2013-06-14 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3aaa16611c30 Merge Changeset: e95fc50106cf Author: rdurbin Date: 2013-06-14 07:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e95fc50106cf 7178026: os::close can restart ::close but that is not a restartable syscall Summary: Removed restart macros from all os:close calls on Solaris, Linux, MacOS X platforms. Reviewed-by: dcubed, dholmes ! src/os/bsd/dtrace/jvm_dtrace.c ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp Changeset: f2d56a269345 Author: dcubed Date: 2013-06-14 08:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f2d56a269345 Merge Changeset: c7242a797916 Author: dcubed Date: 2013-06-14 19:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c7242a797916 Merge Changeset: 5c89346f2bdd Author: sspitsyn Date: 2013-06-14 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5c89346f2bdd 6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description Summary: A typo in the parameter spelling, a bound update missed when the parameter was renamed Reviewed-by: sla, minqi Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmti.xml Changeset: 7fa28f3d3f62 Author: sspitsyn Date: 2013-06-14 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7fa28f3d3f62 Merge Changeset: abbd5c660b48 Author: mgronlun Date: 2013-06-15 13:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/abbd5c660b48 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp Reviewed-by: sla, rbackman ! src/share/vm/memory/allocation.hpp Changeset: cd2118b62475 Author: zgu Date: 2013-06-10 10:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd2118b62475 8013917: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Simple fix when memory allocation site is gone, NMT should report 0 memory size, instead old memory size. Reviewed-by: dcubed, ctornqvi ! src/share/vm/services/memReporter.cpp Changeset: ef748153ee8f Author: sla Date: 2013-06-17 18:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ef748153ee8f 8016304: ThreadMXBean.getDeadlockedThreads reports bogus deadlocks on JDK 8 Reviewed-by: dcubed, mgronlun ! src/share/vm/services/threadService.cpp + test/serviceability/threads/TestFalseDeadLock.java Changeset: 1f4355cee9a2 Author: zgu Date: 2013-06-18 08:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f4355cee9a2 8013651: NMT: reserve/release sequence id's in incorrect order due to race Summary: Fixed NMT race condition for realloc, uncommit and release Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: a5904a086d9f Author: zgu Date: 2013-06-18 09:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a5904a086d9f Merge Changeset: cd54c7e92908 Author: minqi Date: 2013-06-18 09:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd54c7e92908 8015660: Test8009761.java "Failed: init recursive calls: 24. After deopt 25" Summary: Windows reserves and only partially commits thread stack. For detecting more thread stack space for execution, Windows installs one-shot page as guard page just before the current commited edge. It will trigger STACK_OVERFLOW_EXCEPTION when lands on last 4 pages of thread stack space. StackYellowPages default value is 2 on Windows (plus 1 page of StackRedPages, 3 pages guarded by hotspot) so the exception happens one page before Yellow pages. Same route executed second time will have one more page brought in, this leads same execution with different stack depth(interpreter mode). We need match Windows settings so the stack overflow exception will not happen before Yellow pages. Reviewed-by: dholmes Contributed-by: andreas.schoesser at sap.com ! src/cpu/x86/vm/globals_x86.hpp Changeset: 726d2d4913fc Author: nloodin Date: 2013-06-19 18:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/726d2d4913fc Merge From erik.helin at oracle.com Thu Jun 20 02:54:57 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Thu, 20 Jun 2013 09:54:57 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130620095511.1FC2048365@hg.openjdk.java.net> Changeset: 0abfeed51c9e Author: brutisso Date: 2013-06-14 08:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0abfeed51c9e 8012265: VM often crashes on solaris with a lot of memory Summary: Increase HeapBaseMinAddress for G1 from 256m to 1g on Solaris x86 Reviewed-by: mgerdin, coleenp, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 01522ca68fc7 Author: johnc Date: 2013-06-18 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/01522ca68fc7 8015237: Parallelize string table scanning during strong root processing Summary: Parallelize the scanning of the intern string table by having each GC worker claim a given number of buckets. Changes were also reviewed by Per Liden . Reviewed-by: tschatzl, stefank, twisti ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: b9d151496930 Author: brutisso Date: 2013-06-18 22:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b9d151496930 8016556: G1: Use ArrayAllocator for BitMaps Reviewed-by: tschatzl, dholmes, coleenp, johnc ! src/share/vm/memory/allocation.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp Changeset: 493089fd29df Author: poonam Date: 2013-06-19 06:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/493089fd29df 8015903: Format issue with -XX:+PrintAdaptiveSizePolicy on JDK8 Summary: Missing linebreak in hotspot log. Reviewed-by: brutisso, tschatzl Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp Changeset: 9f9c0a163cc5 Author: ehelin Date: 2013-06-20 10:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9f9c0a163cc5 Merge ! src/share/vm/memory/allocation.hpp From goetz.lindenmaier at sap.com Thu Jun 20 07:01:01 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Jun 2013 14:01:01 +0000 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> Hi, I implemented the safefetch stubs for x86 and sparc (was quiet simple). This way I could clean up the #define right away. I tested it thouroughly on x86_64: bsd, nt, linux, solaris x86_32: nt, linux by adding it into our internal VM. Tonight I will get build/test on sparc_64 solaris sparc_32 solaris x86_64 nt, linux with the openjdk ppc port, but I tested that before submitting in a smaller extend, too. Here the webrev: http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 18. Juni 2013 22:44 To: Lindenmaier, Goetz Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" wrote: > Ok, I will implement it on x86. > > To get a single change, you can give me the sparc patch, > or you extend the webrev once I updated it with the > x86 code. Sounds good. Let me know when it's there. -- Chris > If you prefer, you can also push it to some other repository, it > will end up in the ppc repo in time I guess. > > Best regards, > Goetz. > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Tuesday, June 18, 2013 6:59 PM > To: Lindenmaier, Goetz > Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> We have it on these platforms: >> ia64 (nt, linux, hp_ux) >> parisc (hp_ux) >> zArch (linux) >> ppc (aix, linux) >> >> I would implement it on x86 & friends, you do it on sparc and wherever >> else you like it? > > That sounds reasonable. Are we pushing this to the ppc repository then? > > -- Chris > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 18. Juni 2013 07:13 >> To: Volker Simonis >> Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >> >> >> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: >> >>> Hi Goetz, >>> >>> I think the change is good and if the other reviewers don't decide to >>> implement it for the current platforms we can push it. >> >> I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? >> >> -- Chris >> >>> >>> By the way, the makefile changes in ppc64.make will follow in patch 8 for >>> linux [1] and patch 14 for aix [2]. >>> The implementation of the stubs will be in patch 9 for linux [3] and patch >>> 15 for aix [4] (only the signal handling part). >>> >>> Regards, >>> Volker >>> >>> [1] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>> [2] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>> [3] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>> [4] >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>> >>> >>> >>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>> goetz.lindenmaier at sap.com> wrote: >>> >>>> Hi,**** >>>> >>>> ** ** >>>> >>>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>>> >>>> have problems with inline assembly, especially with non-gcc**** >>>> >>>> compilers. Stub routines allow to implement safefetch without**** >>>> >>>> depending on OS or compiler, as it's the case with the current**** >>>> >>>> implementation. This also allows to use a single implementation if an**** >>>> >>>> architecture is supported on several os platforms.**** >>>> >>>> ** ** >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>> >>>> ** ** >>>> >>>> Currently, we guard the code with **** >>>> >>>> #ifdef SAFEFETCH_STUBS**** >>>> >>>> which is set in ppc64.make.**** >>>> >>>> ** ** >>>> >>>> I could also imagine an implementation that uses a pd_debug flag**** >>>> >>>> or a const flag set in os_.hpp that allows the C-compiler to **** >>>> >>>> optimize, and writing the code like this:**** >>>> >>>> ** ** >>>> >>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>> >>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>>> * >>>> >>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>> >>>> if (UseSafefetchStub) {**** >>>> >>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>>> * >>>> >>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>> >>>> } else {**** >>>> >>>> pd_SafeFetch32(adr, errValue);**** >>>> >>>> }**** >>>> >>>> }**** >>>> >>>> ** ** >>>> >>>> Unfortunately this requires **** >>>> >>>> 1) setting the flag on all platforms**** >>>> >>>> 2) renaming the safefetch function on all platfoms.**** >>>> >>>> ** ** >>>> >>>> Actually I would prefer this second solution as it avoids the >>>> preprocessor, **** >>>> >>>> and am happy to edit the sources accordingly if this finds acceptance.**** >>>> >>>> ** ** >>>> >>>> For the implementation of a safefetch_stub see**** >>>> >>>> >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>> **** >>>> >>>> ** ** >>>> >>>> Could I get a review on this change, please?**** >>>> >>>> ** ** >>>> >>>> Thanks,**** >>>> >>>> Goetz.**** >>>> >> > From coleen.phillimore at oracle.com Thu Jun 20 09:26:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Jun 2013 12:26:13 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat,a space could occur when metaspace is almost empty Message-ID: <51C32D25.8050408@oracle.com> Summary: Allocate medium chunks for class metaspace when class loader has lots of classes I originally made class metaspace keep small chunks and not start allocating from medium chunks, because I thought with only Klass objects, small chunks is enough. This test has a large set of class loaders who have a lot of classes, so allocated thousands of small chunks each. Class loaders with that many classes should start allocating from medium chunks, for class metaspace. I also increased the ClassMediumChunk size to 4k and measured a lot less fragmentation waste than 1K or 2K for this test. Lastly, the AppClassLoader instance should have as large of an initial metaspace as the bootclass loader. Tested with vm.quick.testlist and the failing test. open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 Thanks, Coleen From goetz.lindenmaier at sap.com Thu Jun 20 10:14:47 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Jun 2013 17:14:47 +0000 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEC511@DEWDFEMB12A.global.corp.sap> Hi, I checked what relocations are used, see below. I also evaluated whether an additional filler is needed if we reduce the offset size by one bit. The number of extra fillers is very small, 0,1%, so that I would propose to add an extra bit to the type information. Besides breakpoint, section_word and static call the distribution is fairly even. Alternatively we remove some relocations: Which platform uses section_word? Is breakpoint necessary on sparc? Best regards, Goetz. x86_32 x86_64 ppc_64 oop 44566 37129 24090 virtual_call 10422 9265 9727 opt_virtual_call 9083 8085 8344 static_call 435 404 423 static_stub 9518 8489 8767 runtime_call 61762 57695 27899 external_word 6919 9622 0 internal_word 3747 5898 40903 poll 2807 2476 2705 poll_return 2219 1989 2188 breakpoint 0 0 0 section_word 0 0 0 trampoline_stub 0 0 30428 current fillers 2 34 3 new filler needed 9 144 0 I did this with hs24, therefore metadata is missing, but that should not affect the basic picture. From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose Sent: Dienstag, 18. Juni 2013 21:40 To: Bertrand Delsart Cc: Roland Westrelin; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs On Jun 18, 2013, at 1:36 AM, Bertrand Delsart > wrote: This change is consuming the last unused relocType (yet_unused_type_2) Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. The relocInfo records are stored as an array of unsigned shorts (u2). This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space. At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation. That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude. For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable. The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost. The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width. The variability could be encoded in the tag field itself (Huffman style, right-to-left): type_width = 4, type_width_2 = 6, type_width_2_mask = 0x0003, ... bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; } ... - John P.S. Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing. It is somewhat fragile and (I now think) over-clever. This is another thing I would like to change about the relocinfo mechanism, if it were rewritten. Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language. From vladimir.kozlov at oracle.com Thu Jun 20 12:28:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Jun 2013 12:28:26 -0700 Subject: RFR(M): 8016586: PPC64 (part 3): basic changes for PPC64 In-Reply-To: <51BC3B2E.2000205@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE3818@DEWDFEMB12A.global.corp.sap> <51BC3B2E.2000205@oracle.com> Message-ID: <51C357DA.9000502@oracle.com> I will push shortly Part 3 changes into staging repo with corresponding renaming in closed sources. And I added next to Goetz's original patch: make/linux/platform_ppc @@ -2,11 +2,11 @@ arch = ppc -arch_model = ppc +arch_model = ppc_32 os_arch = linux_ppc -os_arch_model = linux_ppc +os_arch_model = linux_ppc_32 lib_arch = ppc Thanks, Vladimir On 6/15/13 3:00 AM, David Holmes wrote: > On 14/06/2013 8:38 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> http://cr.openjdk.java.net/~goetz/webrevs/8016586-inlcudes/ >> >> This change contains the #includes we need for the linuxppc64 port, >> and some other minor changes. It decides about the >> file names in the cpu/ppc directory. >> >> We changed some of your #includes to use _32 extension, basically >> where they are guarded by TARGET_ARCH_MODEL... . I think it >> would make sense to set TARGET_ARCH_MODEL_ppc_32 instead >> of TARGET_ARCH_MODEL_ppc in your port, and name all files used >> within that define with extension _32. In the webrev this is changed >> consistently (not so in the patch). > > So this ppc32 is indeed spreading everywhere :( > > That is potentially going to require a whole bunch of changes in our > makefiles, source file renaming and possibly even build file changes. > This will take time to investigate. > > It would have been simpler to simply let ppc imply 32-bit and use ppc64 > as needed to distinguish. Our LIBARCH for this is likely to remain ppc > not change to ppc32 > > David > ----- > >> What are your politics about ordering the includes here? Most >> other includes are alpha sorted, but the platforms here are not >> at all. If you wish to, I'll establish a certain order. >> >> The changes in compileBroker.cpp and globals.hpp/EnableInvokeDynamic >> are preliminary. They'll be reverted in later changes. >> >> I would be glad if you could review this change, >> >> Best regards & thanks, >> Goetz. >> From vladimir.kozlov at oracle.com Thu Jun 20 12:49:20 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Jun 2013 12:49:20 -0700 Subject: Fwd: Review request for JDK-8017177: more explicit code location information in hs_err crash log In-Reply-To: <51C31243.3040108@oracle.com> References: <56213E63-79EF-435B-BA5F-2124D8BA4E2D@oracle.com> <51C31243.3040108@oracle.com> Message-ID: <51C35CC0.1070002@oracle.com> Hi Doug, I think this is good. One thing I would change is offset value to hexadecimal value instead of "+%d]". And you need review and sponsor from runtime group. thanks, Vladimir On 6/20/13 7:31 AM, Albert Noll wrote: > Begin forwarded message: > >> From: Doug Simon >> Subject: Review request for JDK-8017177: more explicit code location >> information in hs_err crash log >> Date: June 20, 2013 4:12:09 PM GMT+02:00 >> To: "hotspot-dev at openjdk.java.net developers" >> >> >> When debugging compiler issues, it would be useful to know where >> exactly in compiled code a crash happened. Currently, only the name >> and signature of a compiled frame is shown in a crash stack trace. If >> would be useful to know the address and offset of the crashing >> instruction. >> >> For example, instead of: >> >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> v ~DeoptimizationBlob >> J >> java.util.concurrent.ConcurrentHashMap$Segment.remove(Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object; >> >> >> one would get something like: >> >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> v ~DeoptimizationBlob >> J >> java.util.concurrent.ConcurrentHashMap$Segment.remove(Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object; >> @ 0x7f502892e095 [0x7f502892e000+149] >> >> Potential issue: may break hs_err crash log parsers >> >> open webrev at http://cr.openjdk.java.net/~dnsimon/JDK-8017177/ > > > From coleen.phillimore at oracle.com Thu Jun 20 13:11:35 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Jun 2013 16:11:35 -0400 Subject: Fwd: Review request for JDK-8017177: more explicit code location information in hs_err crash log In-Reply-To: <51C35CC0.1070002@oracle.com> References: <56213E63-79EF-435B-BA5F-2124D8BA4E2D@oracle.com> <51C31243.3040108@oracle.com> <51C35CC0.1070002@oracle.com> Message-ID: <51C361F7.3010304@oracle.com> Doug, This looks good to me too. Will you replace the %d to SIZE_FORMAT? If you send me a patch, I will commit it for you. Coleen On 06/20/2013 03:49 PM, Vladimir Kozlov wrote: > Hi Doug, > > I think this is good. One thing I would change is offset value to > hexadecimal value instead of "+%d]". > > And you need review and sponsor from runtime group. > > thanks, > Vladimir > > On 6/20/13 7:31 AM, Albert Noll wrote: >> Begin forwarded message: >> >>> From: Doug Simon >>> Subject: Review request for JDK-8017177: more explicit code location >>> information in hs_err crash log >>> Date: June 20, 2013 4:12:09 PM GMT+02:00 >>> To: "hotspot-dev at openjdk.java.net developers" >>> >>> >>> When debugging compiler issues, it would be useful to know where >>> exactly in compiled code a crash happened. Currently, only the name >>> and signature of a compiled frame is shown in a crash stack trace. If >>> would be useful to know the address and offset of the crashing >>> instruction. >>> >>> For example, instead of: >>> >>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >>> v ~DeoptimizationBlob >>> J >>> java.util.concurrent.ConcurrentHashMap$Segment.remove(Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object; >>> >>> >>> >>> one would get something like: >>> >>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >>> v ~DeoptimizationBlob >>> J >>> java.util.concurrent.ConcurrentHashMap$Segment.remove(Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object; >>> >>> @ 0x7f502892e095 [0x7f502892e000+149] >>> >>> Potential issue: may break hs_err crash log parsers >>> >>> open webrev at http://cr.openjdk.java.net/~dnsimon/JDK-8017177/ >> >> >> From mikael.gerdin at oracle.com Thu Jun 20 13:19:55 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 20 Jun 2013 22:19:55 +0200 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C32D25.8050408@oracle.com> References: <51C32D25.8050408@oracle.com> Message-ID: <51C363EB.8070902@oracle.com> Coleen, this is not a final review, just some comments on the methodology on how we make this kind of changes. On 06/20/2013 06:26 PM, Coleen Phillimore wrote: > Summary: Allocate medium chunks for class metaspace when class loader > has lots of classes > > I originally made class metaspace keep small chunks and not start > allocating from medium chunks, because I thought with only Klass > objects, small chunks is enough. This test has a large set of class > loaders who have a lot of classes, so allocated thousands of small > chunks each. Class loaders with that many classes should start > allocating from medium chunks, for class metaspace. Can you describe exactly how making use of medium chunks for class metaspace increases the memory efficiency. * Is it because of the overhead of each chunk? * Is it because the small size of the chunks lead to wasted memory at the end of each chunk? * Any other reason which I didn't mention? In the second case, can you please try with my fix for JDK-8009561? The webrev is at http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ and http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ I know you lurk on gc-dev so search for "Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk" :) > > I also increased the ClassMediumChunk size to 4k and measured a lot less > fragmentation waste than 1K or 2K for this test. Lastly, the > AppClassLoader instance should have as large of an initial metaspace as > the bootclass loader. Fragmentation in the general case or on a specific (possibly degenerate) test case? I think we need to be careful here not to optimize for some strange test which just loads a lot of classes and does nothing useful. No matter what allocation policy / chunk sizes we come up with there's always a way to design a test which will cause bad behavior. > > Tested with vm.quick.testlist and the failing test. > > open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ The changes to the preallocated exception oops are sane but should probably be done as a separate change... /Mikael > bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 > local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 > > Thanks, > Coleen > From coleen.phillimore at oracle.com Thu Jun 20 13:39:03 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Jun 2013 16:39:03 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C363EB.8070902@oracle.com> References: <51C32D25.8050408@oracle.com> <51C363EB.8070902@oracle.com> Message-ID: <51C36867.2040900@oracle.com> Hi Mikael, I don't lurk on hotspot-gc anymore! I can't keep up with the mails. :) On 06/20/2013 04:19 PM, Mikael Gerdin wrote: > Coleen, > this is not a final review, just some comments on the methodology on > how we make this kind of changes. > > On 06/20/2013 06:26 PM, Coleen Phillimore wrote: >> Summary: Allocate medium chunks for class metaspace when class loader >> has lots of classes >> >> I originally made class metaspace keep small chunks and not start >> allocating from medium chunks, because I thought with only Klass >> objects, small chunks is enough. This test has a large set of class >> loaders who have a lot of classes, so allocated thousands of small >> chunks each. Class loaders with that many classes should start >> allocating from medium chunks, for class metaspace. > > Can you describe exactly how making use of medium chunks for class > metaspace increases the memory efficiency. > * Is it because of the overhead of each chunk? > * Is it because the small size of the chunks lead to wasted memory at > the end of each chunk? > * Any other reason which I didn't mention? Reasons 1 and 2 above. > > In the second case, can you please try with my fix for JDK-8009561? > The webrev is at http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ > and http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ > I missed your fix. Even if we are reusing small chunks better, I still believe class metadata should get a medium chunk like the data metaspace. > I know you lurk on gc-dev so search for "Request for review: > JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk" > > :) > >> >> I also increased the ClassMediumChunk size to 4k and measured a lot less >> fragmentation waste than 1K or 2K for this test. Lastly, the >> AppClassLoader instance should have as large of an initial metaspace as >> the bootclass loader. > > Fragmentation in the general case or on a specific (possibly > degenerate) test case? > I think we need to be careful here not to optimize for some strange > test which just loads a lot of classes and does nothing useful. > No matter what allocation policy / chunk sizes we come up with there's > always a way to design a test which will cause bad behavior. Yes, I wish we had a good way to measure this generally. I did measure the degenerate case. > >> >> Tested with vm.quick.testlist and the failing test. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ > > The changes to the preallocated exception oops are sane but should > probably be done as a separate change... > I needed these changes to separate out which metaspace was running out of memory. I need to do this. Coleen > > /Mikael > >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >> >> Thanks, >> Coleen >> > From goetz.lindenmaier at sap.com Thu Jun 20 14:23:29 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Jun 2013 21:23:29 +0000 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> Hi, here the table from my last mail once more, with better formatting. It shows what relocations are used in a simple jvm98 run. | x86_32 | x86_64 | ppc_64 -------------------------------------------------- oop | 44566 | 37129 | 24090 virtual_call | 10422 | 9265 | 9727 opt_virtual_call | 9083 | 8085 | 8344 static_call | 435 | 404 | 423 static_stub | 9518 | 8489 | 8767 runtime_call | 61762 | 57695 | 27899 external_word | 6919 | 9622 | 0 internal_word | 3747 | 5898 | 40903 poll | 2807 | 2476 | 2705 poll_return | 2219 | 1989 | 2188 breakpoint | 0 | 0 | 0 section_word | 0 | 0 | 0 trampoline_stub | 0 | 0 | 30428 current fillers | 2 | 34 | 3 new filler needed | 9 | 144 | 0 Sum | 140176 | 130978 | 144942 I did this with hs24, therefore metadata is missing, but that should not affect the basic picture. Best regards, Goetz. From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose Sent: Dienstag, 18. Juni 2013 21:40 To: Bertrand Delsart Cc: Roland Westrelin; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs On Jun 18, 2013, at 1:36 AM, Bertrand Delsart > wrote: This change is consuming the last unused relocType (yet_unused_type_2) Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. The relocInfo records are stored as an array of unsigned shorts (u2). This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space. At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation. That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude. For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable. The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost. The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width. The variability could be encoded in the tag field itself (Huffman style, right-to-left): type_width = 4, type_width_2 = 6, type_width_2_mask = 0x0003, ... bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; } ... - John P.S. Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing. It is somewhat fragile and (I now think) over-clever. This is another thing I would like to change about the relocinfo mechanism, if it were rewritten. Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language. From serguei.spitsyn at oracle.com Thu Jun 20 14:28:59 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2013 14:28:59 -0700 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C32D25.8050408@oracle.com> References: <51C32D25.8050408@oracle.com> Message-ID: <51C3741B.2010704@oracle.com> It looks good in general. One minor comments: src/share/vm/memory/metaspace.cpp 1868 if (chunk != NULL) { *1869 while (chunk != NULL) {** **1870 if (chunk != current_chunk()) {* 1871 result += chunk->free_word_size(); *1872 }* 1873 chunk = chunk->next(); 1874 } 1875 } The surrounding conditional block L1868, L1875 is not needed. It was there before your fix though. Thanks, Serguei On 6/20/13 9:26 AM, Coleen Phillimore wrote: > Summary: Allocate medium chunks for class metaspace when class loader > has lots of classes > > I originally made class metaspace keep small chunks and not start > allocating from medium chunks, because I thought with only Klass > objects, small chunks is enough. This test has a large set of class > loaders who have a lot of classes, so allocated thousands of small > chunks each. Class loaders with that many classes should start > allocating from medium chunks, for class metaspace. > > I also increased the ClassMediumChunk size to 4k and measured a lot > less fragmentation waste than 1K or 2K for this test. Lastly, the > AppClassLoader instance should have as large of an initial metaspace > as the bootclass loader. > > Tested with vm.quick.testlist and the failing test. > > open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 > local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 > > Thanks, > Coleen > From vladimir.kozlov at oracle.com Thu Jun 20 15:12:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Jun 2013 15:12:18 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> Message-ID: <51C37E42.1070608@oracle.com> Hmm 'breakpoint_type'? I don't remember that and I only see one use place in MacroAssembler::safepoint() on sparc and that method is not used anymore. I build SPARC VM without breakpoint_Relocation class (commented out). Looks like we can remove this type. thanks, Vladimir On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: > Hi, > > here the table from my last mail once more, with better formatting. > It shows what relocations are used in a simple jvm98 run. > > | x86_32 | x86_64 | ppc_64 > -------------------------------------------------- > oop | 44566 | 37129 | 24090 > virtual_call | 10422 | 9265 | 9727 > opt_virtual_call | 9083 | 8085 | 8344 > static_call | 435 | 404 | 423 > static_stub | 9518 | 8489 | 8767 > runtime_call | 61762 | 57695 | 27899 > external_word | 6919 | 9622 | 0 > internal_word | 3747 | 5898 | 40903 > poll | 2807 | 2476 | 2705 > poll_return | 2219 | 1989 | 2188 > breakpoint | 0 | 0 | 0 > section_word | 0 | 0 | 0 > trampoline_stub | 0 | 0 | 30428 > > current fillers | 2 | 34 | 3 > new filler needed | 9 | 144 | 0 > > Sum | 140176 | 130978 | 144942 > > > I did this with hs24, therefore metadata is missing, but > that should not affect the basic picture. > > Best regards, > Goetz. > > > > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose > Sent: Dienstag, 18. Juni 2013 21:40 > To: Bertrand Delsart > Cc: Roland Westrelin; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs > > On Jun 18, 2013, at 1:36 AM, Bertrand Delsart > wrote: > > This change is consuming the last unused relocType (yet_unused_type_2) > > Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) > > This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. > > The relocInfo records are stored as an array of unsigned shorts (u2). This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space. > > At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation. That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude. > > For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable. The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost. The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width. > > The variability could be encoded in the tag field itself (Huffman style, right-to-left): > type_width = 4, > type_width_2 = 6, > type_width_2_mask = 0x0003, > ... > bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; } > ... > > - John > > P.S. Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing. It is somewhat fragile and (I now think) over-clever. This is another thing I would like to change about the relocinfo mechanism, if it were rewritten. Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language. > > From zhengyu.gu at oracle.com Thu Jun 20 17:01:12 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 21 Jun 2013 00:01:12 +0000 Subject: hg: hsx/hsx24/hotspot: 8011968: Kitchensink crashed with SIGSEGV in MemBaseline::baseline Message-ID: <20130621000117.7B36048396@hg.openjdk.java.net> Changeset: 9aba4a729302 Author: zgu Date: 2013-06-14 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9aba4a729302 8011968: Kitchensink crashed with SIGSEGV in MemBaseline::baseline Summary: Simple fix to add NULL pointer check that can cause segv Reviewed-by: coleenp, ctornqvi ! src/share/vm/services/memBaseline.cpp From coleen.phillimore at oracle.com Thu Jun 20 20:03:01 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 20 Jun 2013 23:03:01 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C363EB.8070902@oracle.com> References: <51C32D25.8050408@oracle.com> <51C363EB.8070902@oracle.com> Message-ID: <51C3C265.8060806@oracle.com> Hi Mikael, I tested this with your patch and without my patch, we still get OOM [Class] Metadata space. With both patches it doesn't. At the end this is one of the class loaders that's left. There were others of these class loaders but they get unloaded. 1091) Metachunk: bottom 0x00000007724ed800 top 0x00000007724ede70 end 0x00000007724ee000 size 256 used 206 free 50 1092) Metachunk: bottom 0x00000007724ed000 top 0x00000007724ed670 end 0x00000007724ed800 size 256 used 206 free 50 total of all chunks 279808 used 225026 free 182 capacity 279808 waste 63344 Even though this is an extreme case, going to 4K word medium chunks after using up 4x 256 word small chunks for class metaspace still makes sense. Maybe 4k could be 2k. I think class loaders either allocate few or many classes. We should tune this more for some in-house applications when some of the other problems are resolved. thanks, Coleen On 6/20/2013 4:19 PM, Mikael Gerdin wrote: > Coleen, > this is not a final review, just some comments on the methodology on > how we make this kind of changes. > > On 06/20/2013 06:26 PM, Coleen Phillimore wrote: >> Summary: Allocate medium chunks for class metaspace when class loader >> has lots of classes >> >> I originally made class metaspace keep small chunks and not start >> allocating from medium chunks, because I thought with only Klass >> objects, small chunks is enough. This test has a large set of class >> loaders who have a lot of classes, so allocated thousands of small >> chunks each. Class loaders with that many classes should start >> allocating from medium chunks, for class metaspace. > > Can you describe exactly how making use of medium chunks for class > metaspace increases the memory efficiency. > * Is it because of the overhead of each chunk? > * Is it because the small size of the chunks lead to wasted memory at > the end of each chunk? > * Any other reason which I didn't mention? > > In the second case, can you please try with my fix for JDK-8009561? > The webrev is at http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ > and http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ > > I know you lurk on gc-dev so search for "Request for review: > JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk" > > :) > >> >> I also increased the ClassMediumChunk size to 4k and measured a lot less >> fragmentation waste than 1K or 2K for this test. Lastly, the >> AppClassLoader instance should have as large of an initial metaspace as >> the bootclass loader. > > Fragmentation in the general case or on a specific (possibly > degenerate) test case? > I think we need to be careful here not to optimize for some strange > test which just loads a lot of classes and does nothing useful. > No matter what allocation policy / chunk sizes we come up with there's > always a way to design a test which will cause bad behavior. > >> >> Tested with vm.quick.testlist and the failing test. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ > > The changes to the preallocated exception oops are sane but should > probably be done as a separate change... > > > /Mikael > >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >> >> Thanks, >> Coleen >> > From vladimir.kozlov at oracle.com Thu Jun 20 20:16:46 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 21 Jun 2013 03:16:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 12 new changesets Message-ID: <20130621031717.47EE54839D@hg.openjdk.java.net> Changeset: 8d52e305a777 Author: morris Date: 2013-06-07 07:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8d52e305a777 8015437: SPARC cbcond branch offset out of 10-bit range Summary: Forced SPARC MacroAssembler eden_alloate to use long branch to slow case Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/macroAssembler_sparc.cpp Changeset: ea60d1de6735 Author: kvn Date: 2013-06-07 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea60d1de6735 Merge Changeset: 46c544b8fbfc Author: morris Date: 2013-06-07 16:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/46c544b8fbfc 8008407: remove SPARC V8 support Summary: Removed most of the SPARC V8 instructions Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/share/vm/runtime/arguments.cpp Changeset: e7f5651d459c Author: twisti Date: 2013-06-11 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e7f5651d459c 8003268: SharedRuntime::generate_native_wrapper doesn't save all registers across runtime tracing calls for JNI critical native methods Reviewed-by: kvn ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 693e4d04fd09 Author: drchase Date: 2013-06-11 16:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/693e4d04fd09 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit Summary: Insert extra checks and bailouts for too many nodes Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/matcher.cpp Changeset: bc8956037049 Author: kvn Date: 2013-06-11 16:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bc8956037049 Merge Changeset: c52abc8a0b08 Author: drchase Date: 2013-06-13 15:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c52abc8a0b08 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink Summary: replace linked data structure with array (performance) Reviewed-by: kvn Contributed-by: christian.thalinger at oracle.com, david.r.chase at oracle.com ! src/share/vm/prims/jvm.cpp Changeset: 7fa25f5575c9 Author: adlertz Date: 2013-06-14 01:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7fa25f5575c9 8016157: During CTW: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Summary: Disable rematerialization for negD node Reviewed-by: kvn, roland ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp Changeset: ac91879aa56f Author: kvn Date: 2013-06-14 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ac91879aa56f Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/prims/jvm.cpp Changeset: 87a6f2df28e2 Author: drchase Date: 2013-06-17 12:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/87a6f2df28e2 8002160: Compilation issue with adlc using latest SunStudio compilers Summary: modify declaration of 'swap' overloading; dodge optimizer bug in c1_LIR.cpp Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/share/vm/c1/c1_LIR.cpp Changeset: 08d35fd1b599 Author: adlertz Date: 2013-06-19 00:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/08d35fd1b599 8001345: VM crashes with assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove unnecessary LoadN / DecodeN nodes at MemBarAcquire nodes. Reviewed-by: kvn, roland ! src/share/vm/opto/memnode.cpp Changeset: b88209cf98c0 Author: kvn Date: 2013-06-20 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b88209cf98c0 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/arguments.cpp From john.coomes at oracle.com Thu Jun 20 20:31:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jun 2013 03:31:47 +0000 Subject: hg: hsx/hotspot-main/corba: 2 new changesets Message-ID: <20130621033152.0DEA94839F@hg.openjdk.java.net> Changeset: 2cf36f43df36 Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/2cf36f43df36 Added tag jdk8-b94 for changeset 22f5d7f261d9 ! .hgtags Changeset: c68c35f50413 Author: katleman Date: 2013-06-20 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/c68c35f50413 Added tag jdk8-b95 for changeset 2cf36f43df36 ! .hgtags From john.coomes at oracle.com Thu Jun 20 20:31:57 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jun 2013 03:31:57 +0000 Subject: hg: hsx/hotspot-main/jaxp: 6 new changesets Message-ID: <20130621033217.C4B89483A0@hg.openjdk.java.net> Changeset: f117a66f337c Author: lana Date: 2013-06-03 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f117a66f337c Merge Changeset: 5b958f0a5498 Author: joehw Date: 2013-06-04 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/5b958f0a5498 8015630: Remove default restriction settings of jaxp 1.5 properties in JDK8 Reviewed-by: alanb ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java Changeset: e996ea806630 Author: lana Date: 2013-06-04 21:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e996ea806630 Merge Changeset: c84658e1740d Author: lana Date: 2013-06-10 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/c84658e1740d Merge Changeset: b8c5f4b6f0ff Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b8c5f4b6f0ff Added tag jdk8-b94 for changeset c84658e1740d ! .hgtags Changeset: e68a5d2efcae Author: katleman Date: 2013-06-20 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e68a5d2efcae Added tag jdk8-b95 for changeset b8c5f4b6f0ff ! .hgtags From john.coomes at oracle.com Thu Jun 20 20:32:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jun 2013 03:32:21 +0000 Subject: hg: hsx/hotspot-main/jaxws: 2 new changesets Message-ID: <20130621033230.5CE31483A1@hg.openjdk.java.net> Changeset: 1468c94135f9 Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/1468c94135f9 Added tag jdk8-b94 for changeset 254c53fd97ab ! .hgtags Changeset: 7de08fa7cb34 Author: katleman Date: 2013-06-20 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/7de08fa7cb34 Added tag jdk8-b95 for changeset 1468c94135f9 ! .hgtags From john.coomes at oracle.com Thu Jun 20 20:31:42 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jun 2013 03:31:42 +0000 Subject: hg: hsx/hotspot-main: 10 new changesets Message-ID: <20130621033143.8EC594839E@hg.openjdk.java.net> Changeset: 198d25db45da Author: erikj Date: 2013-06-11 13:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/198d25db45da 8008707: build-infra: Closed (deploy) can't be built using environment from SDK SetEnv.cmd Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 3cbcc2b6ba41 Author: erikj Date: 2013-06-11 13:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3cbcc2b6ba41 8010785: JDK 8 build on Linux fails with new build mechanism Reviewed-by: dholmes, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 50d2bde060f2 Author: erikj Date: 2013-06-12 10:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/50d2bde060f2 Merge Changeset: 6337f652e71f Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6337f652e71f Added tag jdk8-b94 for changeset 50d2bde060f2 ! .hgtags Changeset: c961c8972485 Author: erikj Date: 2013-06-13 14:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c961c8972485 8014231: --with-alsa configuration options don't add include or lib directories to proper flags Reviewed-by: tbell ! common/autoconf/spec.gmk.in Changeset: 0c540b1505e3 Author: erikj Date: 2013-06-14 13:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0c540b1505e3 8016520: jdk native build does not fail on compilation error on windows Reviewed-by: tbell ! common/makefiles/NativeCompilation.gmk Changeset: 0d1e8518c722 Author: erikj Date: 2013-06-18 11:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0d1e8518c722 8014404: Debug flag not added to jdk native compile when --enable-debug is set Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: c0fa87863427 Author: erikj Date: 2013-06-18 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c0fa87863427 8015377: Support using compiler devkits on Linux Reviewed-by: tbell, dholmes ! common/autoconf/basics.m4 ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 + common/makefiles/devkit/Makefile + common/makefiles/devkit/Tools.gmk Changeset: 785d07fe3890 Author: katleman Date: 2013-06-18 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/785d07fe3890 Merge Changeset: 794cceb5dc82 Author: katleman Date: 2013-06-20 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/794cceb5dc82 Added tag jdk8-b95 for changeset 785d07fe3890 ! .hgtags From john.coomes at oracle.com Thu Jun 20 20:53:28 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jun 2013 03:53:28 +0000 Subject: hg: hsx/hotspot-main/langtools: 18 new changesets Message-ID: <20130621035424.9CEDF483A4@hg.openjdk.java.net> Changeset: 9f11c7676cd5 Author: vromero Date: 2013-05-31 10:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9f11c7676cd5 7179353: try-with-resources fails to compile with generic exception parameters Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T7179353/GenericsAndTWRCompileErrorTest.java Changeset: e9855150c5b0 Author: vromero Date: 2013-06-01 21:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e9855150c5b0 8010737: javac, known parameter's names should be copied to automatically generated constructors for inner classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/ReflectionVisitor.java + test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java Changeset: ec871c3e8337 Author: vromero Date: 2013-06-01 22:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ec871c3e8337 6695379: Copy method annotations and parameter annotations to synthetic bridge methods Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/ReflectionVisitor.java ! test/tools/javac/MethodParameters/Tester.java + test/tools/javac/T6695379/AnnotationsAreNotCopiedToBridgeMethodsTest.java Changeset: 391f97e270c2 Author: jjg Date: 2013-06-03 16:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/391f97e270c2 8013405: DocLint should support
  • Reviewed-by: ksrini ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/html/ListTagsTest.java + test/tools/doclint/html/ListTagsTest.out Changeset: 8258f84a8649 Author: lana Date: 2013-06-03 16:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8258f84a8649 Merge Changeset: 7a4fd1076b15 Author: lana Date: 2013-06-03 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7a4fd1076b15 Merge Changeset: 242bcad5be74 Author: jjg Date: 2013-06-03 17:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/242bcad5be74 8006615: [doclint] move remaining messages into resource bundle Reviewed-by: mcimadamore, vromero ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/ResourceTest.java ! test/tools/doclint/tool/RunTest.java Changeset: 019063968164 Author: jjg Date: 2013-06-03 17:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/019063968164 8007687: javadoc -X does not include -Xdoclint Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java + test/com/sun/javadoc/testXOption/TestXOption.java Changeset: 5cd3cb69c8b3 Author: mcimadamore Date: 2013-06-04 11:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5cd3cb69c8b3 7116676: RichDiagnosticFormatter throws NPE when formatMessage is called directly Summary: Fix NPE in RichDiagnosticFormatter.formatMessage Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/7116676/T7116676.java Changeset: 32c50b5f70b5 Author: mcimadamore Date: 2013-06-04 11:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/32c50b5f70b5 8008160: Five lambda TargetType tests have @ignore Summary: Remove @ignore flags from tests that now pass Reviewed-by: jjg ! test/tools/javac/lambda/TargetType53.java ! test/tools/javac/lambda/TargetType54.java ! test/tools/javac/lambda/TargetType58.java ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java Changeset: c8acc254b6d7 Author: mcimadamore Date: 2013-06-04 11:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c8acc254b6d7 8015505: Spurious inference error when return type of generic method requires unchecked conversion to target Summary: Use check context compatibility during 15.12.2.8 check (only when JDK 8 inference is enabled) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8015505/T8015505.java + test/tools/javac/generics/inference/8015505/T8015505.out ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java Changeset: 775a51e3276f Author: vromero Date: 2013-06-04 13:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/775a51e3276f 7165659: javac incorrectly sets strictfp access flag on inner-classes Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/T7165659/InnerClassAttrMustNotHaveStrictFPFlagTest.java Changeset: 8fb68f73d4b1 Author: jjg Date: 2013-06-04 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8fb68f73d4b1 8004643: Reduce javac space overhead introduced with compiler support for repeating annotations Reviewed-by: mcimadamore, jfranck ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.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/ClassReader.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/JNIWriter.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lib/DPrinter.java Changeset: 9acd0f8d6e44 Author: lana Date: 2013-06-04 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9acd0f8d6e44 Merge Changeset: 79fd9cfa55f2 Author: kizune Date: 2013-06-05 16:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/79fd9cfa55f2 7186887: Test T6567415.java can fail on a slow machine Reviewed-by: jjg, ksrini ! test/tools/javac/6567415/T6567415.java Changeset: 48c6e6ab7c81 Author: lana Date: 2013-06-10 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/48c6e6ab7c81 Merge Changeset: 4cb113623127 Author: katleman Date: 2013-06-13 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4cb113623127 Added tag jdk8-b94 for changeset 48c6e6ab7c81 ! .hgtags Changeset: 3478b1e81baf Author: katleman Date: 2013-06-20 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3478b1e81baf Added tag jdk8-b95 for changeset 4cb113623127 ! .hgtags From john.coomes at oracle.com Thu Jun 20 20:54:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jun 2013 03:54:32 +0000 Subject: hg: hsx/hotspot-main/nashorn: 27 new changesets Message-ID: <20130621035454.4052A483A5@hg.openjdk.java.net> Changeset: 7e105c2f3167 Author: lana Date: 2013-06-03 16:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7e105c2f3167 Merge Changeset: d2bd881976b5 Author: lana Date: 2013-06-04 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d2bd881976b5 Merge Changeset: 66b2fde90c9d Author: jlaskey Date: 2013-05-29 16:23 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/66b2fde90c9d 8015636: Add more typed arrays code coverage tests. Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/typedarrays.js Changeset: eda227663eda Author: sundar Date: 2013-05-30 16:49 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/eda227663eda 8015353: Date.parse illegal string parsing issues Reviewed-by: jlaskey, lagergren - src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/NativeDate.java + src/jdk/nashorn/internal/parser/DateParser.java + test/script/basic/JDK-8015353.js Changeset: 818946884410 Author: attila Date: 2013-05-31 12:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/818946884410 8015693: reduce NodeLiteralNode to NullLiteralNode Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/ir/LiteralNode.java Changeset: d8a7727a519e Author: attila Date: 2013-05-31 12:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d8a7727a519e 8015684: FieldObjectCreator.putField ignores getValueType Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java Changeset: cab639125b98 Author: attila Date: 2013-05-31 12:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/cab639125b98 8015674: CodeGenerator.initSymbols mutates a list Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java Changeset: 11b81fa7125a Author: attila Date: 2013-05-31 12:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/11b81fa7125a 8015673: Type for :e symbol is wrong Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java Changeset: b4e6cc05ce09 Author: sundar Date: 2013-05-31 17:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b4e6cc05ce09 8012164: Error.stack needs trimming Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8012164.js + test/script/basic/JDK-8012164.js.EXPECTED ! test/script/basic/NASHORN-108.js.EXPECTED ! test/script/basic/NASHORN-109.js.EXPECTED ! test/script/basic/errorstack.js.EXPECTED Changeset: 64250b3a2f2a Author: jlaskey Date: 2013-05-31 13:04 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/64250b3a2f2a 8015727: Thread safe print function Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/Global.java Changeset: 295c91f5fdde Author: sundar Date: 2013-06-03 15:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/295c91f5fdde 8015345: Function("}),print('test'),({") should throw SyntaxError Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8015345.js + test/script/basic/JDK-8015345.js.EXPECTED ! test/script/basic/funcconstructor.js.EXPECTED Changeset: 08a8fda6c0bf Author: jlaskey Date: 2013-06-03 08:34 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/08a8fda6c0bf 8015741: Need a global.load function that starts with a new global scope. Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8015741.js + test/script/basic/JDK-8015741.js.EXPECTED Changeset: 2df08f4c531d Author: jlaskey Date: 2013-06-03 11:16 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2df08f4c531d 8015796: Race condition in RuntimeCallsites Reviewed-by: lagergren, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java Changeset: 0946c8a60f39 Author: jlaskey Date: 2013-06-03 12:57 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0946c8a60f39 8015814: loadWithNewGlobal needs to wrap createGlobal in AccessController.doPrivileged Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 78113cda23bf Author: sundar Date: 2013-06-04 17:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/78113cda23bf 8015855: test/script/basic/JDK-8012164.js fails on Windows Reviewed-by: hannesw, lagergren, jlaskey ! test/script/basic/JDK-8012164.js Changeset: c70f60578385 Author: sundar Date: 2013-06-04 22:31 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c70f60578385 8015830: Javascript mapping of ScriptEngine bindings does not expose keys Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8015830.js + test/script/basic/JDK-8015830.js.EXPECTED Changeset: 62b096f7bac3 Author: sundar Date: 2013-06-05 12:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/62b096f7bac3 8015945: loadWithNewGlobal return value has to be properly wrapped Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8015945.js + test/script/basic/JDK-8015945.js.EXPECTED Changeset: c6c05f23bca4 Author: sundar Date: 2013-06-05 13:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c6c05f23bca4 Merge - src/jdk/nashorn/internal/objects/DateParser.java Changeset: 0feca8a93cb3 Author: attila Date: 2013-06-05 10:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0feca8a93cb3 8015955: ObjectNode.elements should be stronger typed Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java Changeset: 9374c04f38fe Author: attila Date: 2013-06-05 12:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9374c04f38fe 8015961: Several small code-gardening fixes Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java Changeset: 60bc560df392 Author: hannesw Date: 2013-06-05 12:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/60bc560df392 8015350: Array.prototype.reduceRight issue with large length and index Reviewed-by: attila, sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + test/script/basic/JDK-8015350.js + test/script/basic/JDK-8015350.js.EXPECTED Changeset: 35bba63990b7 Author: jlaskey Date: 2013-06-05 10:32 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/35bba63990b7 8015911: $EXEC does not handle large outputs Reviewed-by: sundar, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java Changeset: 16219bef66ec Author: jlaskey Date: 2013-06-05 12:41 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/16219bef66ec 8015910: Nashorn JavaFX includes are out of sync with JavaFX repo Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/controls.js ! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js ! src/jdk/nashorn/internal/runtime/resources/fx/swt.js ! src/jdk/nashorn/internal/runtime/resources/fx/web.js Changeset: e3bd0ed64da8 Author: jlaskey Date: 2013-06-05 12:54 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e3bd0ed64da8 Merge Changeset: d92b756bc739 Author: lana Date: 2013-06-10 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d92b756bc739 Merge - src/jdk/nashorn/internal/objects/DateParser.java Changeset: cbc9926f5b40 Author: katleman Date: 2013-06-13 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/cbc9926f5b40 Added tag jdk8-b94 for changeset d92b756bc739 ! .hgtags Changeset: b031efa535ad Author: katleman Date: 2013-06-20 10:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b031efa535ad Added tag jdk8-b95 for changeset cbc9926f5b40 ! .hgtags From john.r.rose at oracle.com Thu Jun 20 21:22:50 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 20 Jun 2013 21:22:50 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51C37E42.1070608@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> Message-ID: <8EF9CDF9-1FAB-4DB3-8D98-E6FE59BFBD7E@oracle.com> On Jun 20, 2013, at 3:12 PM, Vladimir Kozlov wrote: > Hmm 'breakpoint_type'? I don't remember that and I only see one use place in MacroAssembler::safepoint() on sparc and that method is not used anymore. > I build SPARC VM without breakpoint_Relocation class (commented out). Looks like we can remove this type. If that relocation type doesn't occur in the sources (or any recent version of them), remove it. Goetz, thank you for the interesting numbers. They make it clear that the cost of the extra fillers is negligible, so I recommend that if or when we need more than 16 codes, just steal the bit from the offsets. ? John From john.coomes at oracle.com Thu Jun 20 20:34:13 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jun 2013 03:34:13 +0000 Subject: hg: hsx/hotspot-main/jdk: 77 new changesets Message-ID: <20130621035027.6167F483A2@hg.openjdk.java.net> Changeset: fd377533608b Author: andrew Date: 2013-05-30 16:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd377533608b 8011693: Remove redundant fontconfig files Summary: Remove unused fontconfig files from OpenJDK GNU/Linux builds Reviewed-by: andrew, prr Contributed-by: Jiri Vanek ! make/sun/awt/Makefile ! makefiles/GendataFontConfig.gmk - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties Changeset: b9b73bf450a4 Author: bae Date: 2013-05-31 14:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b9b73bf450a4 8015606: Text is not rendered correctly if destination buffer is custom Reviewed-by: prr, vadim ! src/share/classes/sun/java2d/loops/MaskFill.java + test/sun/java2d/loops/RenderToCustomBufferTest.java Changeset: 0a17344d074e Author: prr Date: 2013-05-31 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a17344d074e 8015556: [macosx] surrogate pairs do not render properly. Reviewed-by: bae, jchen ! src/macosx/classes/sun/font/CCharToGlyphMapper.java + test/java/awt/FontClass/SurrogateTest/SuppCharTest.java Changeset: 3af3981dee11 Author: lana Date: 2013-06-05 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3af3981dee11 Merge - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Changeset: 768fcc36182a Author: anthony Date: 2013-05-30 18:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/768fcc36182a 8015303: [macosx] Application launched via custom URL Scheme does not receive URL Summary: Make copies of event parameters Reviewed-by: anthony, swingler, serb Contributed-by: James Tomson ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Changeset: 8472c148688c Author: ant Date: 2013-05-30 18:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8472c148688c 8013424: Regression: java.awt.datatransfer.FlavorListeners not notified on Linux/Java 7 Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XClipboard.java Changeset: 56512cfccef9 Author: ant Date: 2013-05-30 18:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/56512cfccef9 8013773: requestFocusInWindow to a disabled component prevents window of getting focused Reviewed-by: leonidr, alexsch ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java + test/java/awt/Focus/ResetMostRecentFocusOwnerTest/ResetMostRecentFocusOwnerTest.java Changeset: b0eab0f8b503 Author: anthony Date: 2013-05-31 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b0eab0f8b503 8013189: JMenuItems draw behind TextArea Summary: Untie XTextAreaPeer internal components from the TextArea parent to prevent its invalidation. I.e. force the java.awt.smartInvalidate=true locally. Reviewed-by: art, serb ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/TextArea/Mixing/TextAreaMixing.java Changeset: 481476e941fd Author: ant Date: 2013-05-31 15:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/481476e941fd 8015589: Test java/awt/Window/Grab/GrabTest.java fails on MacOSX Reviewed-by: anthony ! test/java/awt/Window/Grab/GrabTest.java Changeset: 611f8664c96c Author: malenkov Date: 2013-05-31 18:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/611f8664c96c 8013557: XMLEncoder in 1.7 can't encode objects initialized in no argument constructor Reviewed-by: alexsch ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test6989223.java + test/java/beans/XMLEncoder/Test7080156.java + test/java/beans/XMLEncoder/Test8013557.java Changeset: a4356b90f57d Author: vkarnauk Date: 2013-05-31 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a4356b90f57d 7068740: If you wrap a JTable in a JLayer you can't use the page up and page down cmds Reviewed-by: alexsch, alexp ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java + test/javax/swing/JTable/7068740/bug7068740.java Changeset: 791fd2ef87b3 Author: vkarnauk Date: 2013-05-31 19:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/791fd2ef87b3 6436314: Vector could be created with appropriate size in DefaultComboBoxModel Reviewed-by: alexsch, alexp ! src/share/classes/javax/swing/DefaultComboBoxModel.java Changeset: ae4683a6b860 Author: pchelko Date: 2013-06-03 10:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ae4683a6b860 8015477: Support single threaded AWT/FX mode. Reviewed-by: ant, anthony ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CDropTargetContextPeer.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAccessor.java + src/share/classes/sun/awt/FwDispatcher.java Changeset: 43f82f573c01 Author: alitvinov Date: 2013-06-03 14:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/43f82f573c01 7151823: The test incorrectly recognizing OS Reviewed-by: serb, alexp ! test/javax/swing/JTabbedPane/4624207/bug4624207.java Changeset: d378104e52e3 Author: anthony Date: 2013-06-03 16:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d378104e52e3 8015500: Prevent sending multiple WINDOW_CLOSED events for already disposed windows Reviewed-by: anthony, serb Contributed-by: Jose Luis Martin ! src/share/classes/java/awt/Window.java + test/java/awt/Window/WindowClosedEvents/WindowClosedEventOnDispose.java Changeset: 9a8e0140123a Author: alitvinov Date: 2013-06-03 16:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9a8e0140123a 6337518: Null Arrow Button Throws Exception in BasicComboBoxUI Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java + test/javax/swing/JComboBox/6337518/bug6337518.java Changeset: 8b274eccd94a Author: mcherkas Date: 2013-06-05 14:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b274eccd94a 8015375: Edits to text components hang for clipboard access Reviewed-by: art, anthony Contributed-by: Dmitry Markov ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 1390369d4457 Author: vkarnauk Date: 2013-06-05 16:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1390369d4457 8015425: [macosx] A follow-up for the fix 8010721 Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: a4af3d10d19e Author: ant Date: 2013-06-05 17:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a4af3d10d19e 8015339: Correct a wording in javadoc of java.awt.ContainerOrderFocusTraversalPolicy Reviewed-by: art, anthony ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java Changeset: 6802f71a5eb2 Author: malenkov Date: 2013-06-05 18:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6802f71a5eb2 8013370: Null pointer exception when adding more than 9 accelators to a JMenuBar Reviewed-by: serb ! src/share/classes/javax/swing/KeyboardManager.java + test/javax/swing/KeyboardManager/8013370/Test8013370.java Changeset: e246bc03c8cb Author: lana Date: 2013-06-05 00:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e246bc03c8cb Merge - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Changeset: 3e904a3f3c9f Author: lana Date: 2013-06-05 09:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3e904a3f3c9f Merge Changeset: f272934d41fb Author: lana Date: 2013-06-05 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f272934d41fb Merge Changeset: 90df6756406f Author: sherman Date: 2013-05-29 19:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/90df6756406f 4759491: method ZipEntry.setTime(long) works incorrectly 6303183: Support NTFS and Unix-style timestamps for entries in Zip files 7012856: (zipfs) Newly created entry in zip file system should set all file times non-null values. 7012868: (zipfs) file times of entry in zipfs should always be the same regardless of TimeZone. Summary: to add suuport of Info-ZIP extended timestamp in extra data fields Reviewed-by: martin, alanb ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java + src/share/classes/java/util/zip/ZipUtils.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh ! test/java/util/jar/TestExtra.java ! test/java/util/zip/StoredCRC.java + test/java/util/zip/TestExtraTime.java ! test/java/util/zip/ZipFile/Assortment.java Changeset: 6df9b071b04d Author: jzavgren Date: 2013-05-30 12:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6df9b071b04d 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c Reviewed-by: martin, dholmes, chegar, ksrini ! src/solaris/bin/java_md_solinux.c Changeset: dc22b7241a70 Author: jbachorik Date: 2013-05-30 13:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dc22b7241a70 8015627: test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails in agentvm mode Reviewed-by: alanb, chegar ! test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java Changeset: 156ee44cd456 Author: psandoz Date: 2013-05-30 16:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/156ee44cd456 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Summary: Also fixes documentation on StreamBuilder.OfDouble Reviewed-by: alanb, chegar, mduigou ! src/share/classes/java/util/stream/StreamBuilder.java Changeset: b4742d038100 Author: psandoz Date: 2013-05-28 15:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4742d038100 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Reviewed-by: alanb, chegar ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java Changeset: b588955b7e5b Author: sherman Date: 2013-05-30 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b588955b7e5b 8015271: Conversion table for EUC-KR is incorrect Summary: to add the requested postal code mark character u+327e Reviewed-by: alanb ! make/tools/CharsetMapping/EUC_KR.map Changeset: 6407106f1b1c Author: xuelei Date: 2013-05-30 22:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6407106f1b1c 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Reviewed-by: xuelei Contributed-by: Pasi Eronen ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/util/KeyUtil.java + test/com/sun/crypto/provider/TLS/TestLeadingZeroes.java + test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java Changeset: 8402ef8fabde Author: ascarpino Date: 2013-05-30 22:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8402ef8fabde 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called Reviewed-by: mullan, xuelei ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/javax/crypto/CipherInputStream.java ! src/share/classes/javax/crypto/CipherOutputStream.java + test/javax/crypto/Cipher/CipherStreamClose.java Changeset: 6cb09d3cd309 Author: valeriep Date: 2013-05-29 20:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6cb09d3cd309 8013069: javax.crypto tests fail with new PBE algorithm names Summary: Shouldn't auto-generate default parameters for MAC objects. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/MacClone.java Changeset: 918d9ac17740 Author: ascarpino Date: 2013-05-30 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/918d9ac17740 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherSpi.java Changeset: b47044426bcd Author: psandoz Date: 2013-05-31 09:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b47044426bcd 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown Summary: A minor documentation issue (not a spec issue). Reviewed-by: chegar, dl ! src/share/classes/java/util/Spliterator.java Changeset: dcf42861b5b1 Author: chegar Date: 2013-05-31 09:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dcf42861b5b1 7107883: getNetworkPrefixLength() does not return correct prefix length Reviewed-by: alanb, michaelm ! src/solaris/native/java/net/NetworkInterface.c ! test/java/net/InterfaceAddress/NetworkPrefixLength.java Changeset: 243cd682c47b Author: alanb Date: 2013-05-31 12:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/243cd682c47b 8014854: (bf) CharBuffer.chars too slow with default implementation Reviewed-by: erikj, briangoetz, henryjen, psandoz, mduigou ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcBuffer.gmk ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template + src/share/classes/java/nio/CharBufferSpliterator.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/Heap-X-Buffer.java.template ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template + test/java/nio/Buffer/Chars.java Changeset: 933b1338b99c Author: naoto Date: 2013-05-31 11:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/933b1338b99c 7006052: awt_InputMethod.c cleanup is needed Reviewed-by: anthony ! src/solaris/native/sun/awt/awt_InputMethod.c Changeset: f522bbdf2859 Author: dxu Date: 2013-05-31 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f522bbdf2859 8015628: Test Failure in closed/java/io/pathNames/GeneralSolaris.java Reviewed-by: alanb ! test/java/io/pathNames/General.java ! test/java/io/pathNames/GeneralWin32.java Changeset: 11cdcf87ad5d Author: jzavgren Date: 2013-05-31 15:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11cdcf87ad5d 8008972: Memory leak: Java_java_net_TwoStacksPlainDatagramSocketImpl_receive0 [parfait] Summary: Modified the code so that "jumbo frames" are truncated before buffer allocation is considered. This makes the buffer length a reliable indication that a buffer has been allocated, and it can then be used during clean up. Reviewed-by: chegar, khazra, alanb Contributed-by: john.zavgren at oracle.com ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: f6e6c27c19f3 Author: jzavgren Date: 2013-05-31 15:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f6e6c27c19f3 7188517: Check on '$' character is missing in the HttpCookie class constructor Summary: Modified the constructor code so that the cookie names are examined for leading dollar signs and if they do, an illegal argument exception is thrown. Reviewed-by: chegar, khazra, michaelm Contributed-by: john.zavgren at oracle.com ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: fc0b3e86fdcf Author: mduigou Date: 2013-05-31 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fc0b3e86fdcf 8015686: {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException Reviewed-by: dholmes, alanb, psandoz ! src/share/classes/java/util/IntSummaryStatistics.java ! src/share/classes/java/util/LongSummaryStatistics.java Changeset: 198de8103df2 Author: mduigou Date: 2013-05-31 17:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/198de8103df2 Merge Changeset: c8410ce73ad6 Author: mduigou Date: 2013-02-12 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c8410ce73ad6 8007398: Peformance improvements to Integer and Long string formatting. Reviewed-by: mduigou, martin, darcy, briangoetz Contributed-by: Steven Schlansker , Mike Duigou ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java + test/java/lang/IntegralPrimitiveToString.java Changeset: f3c7c5f753dc Author: psandoz Date: 2013-06-03 10:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3c7c5f753dc 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE Reviewed-by: chegar ! src/share/classes/java/util/PrimitiveIterator.java + test/java/util/Iterator/PrimitiveIteratorDefaults.java Changeset: 44ef47f3efed Author: psandoz Date: 2013-06-03 10:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44ef47f3efed 8014731: j.u.stream.StreamSupport class has default constructor generated Summary: This change set also fixes broken links Reviewed-by: alanb, chegar Contributed-by: Paul Sandoz , Henry Jen ! src/share/classes/java/util/stream/StreamSupport.java Changeset: 33d1376bf725 Author: nloodin Date: 2013-06-03 16:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/33d1376bf725 6526682: JConsole shows negative CPU Usage Reviewed-by: alanb, mchung ! src/share/classes/sun/tools/jconsole/SummaryTab.java Changeset: 3d4d7ed93731 Author: emc Date: 2013-06-03 10:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3d4d7ed93731 8014834: shell tests don't begin with #!/bin/sh Summary: Some shell tests don't begin with the command interpreter line Reviewed-by: alanb, ksrini ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/Locale/data/deflocale.sh ! test/java/util/PluggableLocale/BreakIteratorProviderTest.sh ! test/java/util/PluggableLocale/CalendarDataProviderTest.sh ! test/java/util/PluggableLocale/ClasspathTest.sh ! test/java/util/PluggableLocale/CollatorProviderTest.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/DateFormatProviderTest.sh ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/GenericTest.sh ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/NumberFormatProviderTest.sh ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/rmi/rmic/newrmic/equivalence/batch.sh ! test/tools/launcher/MultipleJRE.sh Changeset: a79e2683eae3 Author: psandoz Date: 2013-06-03 17:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a79e2683eae3 8014383: StringJoiner example in class description not in sync with streams API Reviewed-by: alanb ! src/share/classes/java/util/StringJoiner.java Changeset: 62d3c82b4509 Author: shade Date: 2013-06-03 22:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/62d3c82b4509 8014966: Add the proper Javadoc to @Contended Summary: more extensive description. Reviewed-by: dholmes, mduigou, martin ! src/share/classes/sun/misc/Contended.java Changeset: f4e2a70260cf Author: ksrini Date: 2013-06-03 13:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4e2a70260cf 8015813: add test/tools/pack200/TimeStamp.java to ProblemsList Reviewed-by: sherman ! test/ProblemList.txt Changeset: 1fd682e7110b Author: lana Date: 2013-06-03 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1fd682e7110b Merge Changeset: 25cf25fb8c68 Author: sla Date: 2013-06-04 09:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25cf25fb8c68 8015856: Remove java/lang/instrument/IsModifiableClassAgent.java from ProblemList.txt Reviewed-by: dholmes ! test/ProblemList.txt Changeset: 5223d3228658 Author: bchristi Date: 2013-06-04 10:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5223d3228658 8005698: Handle Frequent HashMap Collisions with Balanced Trees Summary: HashMap bins with many collisions store entries in balanced trees Reviewed-by: alanb, dl, mduigou ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/sun/misc/Hashing.java + test/java/util/Map/CheckRandomHashSeed.java ! test/java/util/Map/Collisions.java + test/java/util/Map/InPlaceOpsCollisions.java + test/java/util/Map/TreeBinSplitBackToEntries.java + test/java/util/Spliterator/SpliteratorCollisions.java Changeset: fad4ef2123ca Author: psandoz Date: 2013-06-04 11:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fad4ef2123ca 8015790: Remove duplicate spliterator tests Reviewed-by: alanb, mduigou - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java Changeset: f8b071428ca5 Author: michaelm Date: 2013-06-04 10:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8b071428ca5 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing Reviewed-by: alanb, chegar ! src/share/classes/java/net/HttpURLPermission.java ! test/ProblemList.txt Changeset: 780fbbd50ce4 Author: alanb Date: 2013-06-04 11:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/780fbbd50ce4 8015872: ProblemList.txt updates (6/2013) Reviewed-by: chegar ! test/ProblemList.txt Changeset: 25a8e6fd0210 Author: alanb Date: 2013-06-04 15:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25a8e6fd0210 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported Reviewed-by: alanb Contributed-by: henry.jen at oracle.com ! test/java/nio/file/Files/StreamTest.java Changeset: 379e1bcae693 Author: naoto Date: 2013-06-04 10:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/379e1bcae693 8013903: Japanese calendar field names are not displayed with -Djava.locale.providers=HOST on Windows Reviewed-by: okutsu ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: d6401129327e Author: dl Date: 2013-06-04 21:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d6401129327e 8005704: Update ConcurrentHashMap to v8 Reviewed-by: chegar, mduigou ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: bd84bad9ee99 Author: jdn Date: 2013-06-04 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bd84bad9ee99 8014097: add doPrivileged methods with limited privilege scope Reviewed-by: mchung ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java + test/java/security/AccessController/LimitedDoPrivileged.java Changeset: bb71021af586 Author: lana Date: 2013-06-04 21:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb71021af586 Merge Changeset: 8a9f897a57d6 Author: alanb Date: 2013-06-05 11:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a9f897a57d6 8003895: java/nio/channels/AsynchronousChannelGroup/Unbounded.java failing again [win64] Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: de11b20f8c01 Author: psandoz Date: 2013-05-31 10:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/de11b20f8c01 8013649: HashMap spliterator tryAdvance() encounters remaining elements after forEachRemaining() Reviewed-by: chegar ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/WeakHashMap.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: ae700bdb68b6 Author: alanb Date: 2013-06-05 13:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ae700bdb68b6 8015880: GenerateBreakIteratorData build warning Reviewed-by: peytoia ! make/tools/src/build/tools/generatebreakiteratordata/CharSet.java Changeset: df1b35c7901d Author: dsamersoff Date: 2013-06-05 18:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/df1b35c7901d 8015604: JDP packets containing ideographic characters are broken Summary: Code uses string length rather than byte array length and non ascii entry brakes packet. Reviewed-by: dholmes, jbachorik, sla ! src/share/classes/sun/management/jdp/JdpPacketWriter.java ! test/sun/management/jdp/JdpUnitTest.java Changeset: 5edcc8ca4146 Author: chegar Date: 2013-06-05 16:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5edcc8ca4146 8011719: Properties.loadFromXML fails with a chunked HTTP connection Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/HttpStreams.java Changeset: c1af6b5a979a Author: chegar Date: 2013-06-05 16:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1af6b5a979a 8015963: Add at since tags to new ConcurrentHashMap methods Reviewed-by: shade, martin ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: e857b2a3ecee Author: fparain Date: 2013-06-05 08:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e857b2a3ecee 7150256: Add back Diagnostic Command JMX API Reviewed-by: mchung, jbachorik ! make/java/management/Exportedfiles.gmk ! make/java/management/FILES_c.gmk ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers + src/share/classes/com/sun/management/DiagnosticCommandMBean.java ! src/share/classes/java/lang/management/ManagementFactory.java + src/share/classes/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/sun/management/DiagnosticCommandImpl.java + src/share/classes/sun/management/DiagnosticCommandInfo.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h + src/share/native/sun/management/DiagnosticCommandImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java ! test/java/lang/management/MXBean/MXBeanBehavior.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java Changeset: 388b4d4cae3b Author: lana Date: 2013-06-05 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/388b4d4cae3b Merge - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java Changeset: 080449feeca9 Author: lana Date: 2013-06-10 17:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/080449feeca9 Merge - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java Changeset: e833fa13dce3 Author: erikj Date: 2013-06-11 13:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e833fa13dce3 8010785: JDK 8 build on Linux fails with new build mechanism Reviewed-by: dholmes, tbell ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/Import.gmk ! makefiles/Setup.gmk Changeset: 51479fa56b7c Author: erikj Date: 2013-06-12 10:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/51479fa56b7c Merge Changeset: 992b39afdcb9 Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/992b39afdcb9 Added tag jdk8-b94 for changeset 51479fa56b7c ! .hgtags Changeset: 1f855dd74077 Author: amurillo Date: 2013-06-14 07:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1f855dd74077 Merge ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 3531945431aa Author: erikj Date: 2013-06-13 14:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3531945431aa 8014231: --with-alsa configuration options don't add include or lib directories to proper flags Reviewed-by: tbell ! makefiles/CompileNativeLibraries.gmk Changeset: 42aa9f182885 Author: katleman Date: 2013-06-18 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42aa9f182885 Merge ! makefiles/CompileNativeLibraries.gmk Changeset: 0c4db4782114 Author: katleman Date: 2013-06-20 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c4db4782114 Added tag jdk8-b95 for changeset 42aa9f182885 ! .hgtags From daniel.daugherty at oracle.com Thu Jun 20 23:21:13 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 21 Jun 2013 06:21:13 +0000 Subject: hg: hsx/hsx24/hotspot: 8014326: [OSX] All libjvm symbols are exported Message-ID: <20130621062118.372C4483C9@hg.openjdk.java.net> Changeset: b964a67d19df Author: dholmes Date: 2013-06-20 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b964a67d19df 8014326: [OSX] All libjvm symbols are exported Summary: Add support for a MacOS X compatible form of the libjvm mapfile. Reviewed-by: dcubed, rdurbin, coleenp ! make/bsd/makefiles/build_vm_def.sh ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product From goetz.lindenmaier at sap.com Fri Jun 21 01:55:00 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Jun 2013 08:55:00 +0000 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51C37E42.1070608@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> Hi, I removed the breakpoint_Relocation, see http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ It builds and runs on sparc_64 and linuxx86_64. section_word_Relocation can not be removed simply. Internal_word relocations are changed to section_word by pack_data_to. I counted the relocations where they are generated, so I did not catch this. So I didn't remove them. I guess we should make an extra change for this, maybe even push it to the hotspot-comp repository? It's got nothing to do with the port. Bertrand, can I push 8016696: PPC64 (part 4), now as the problem with the enum is solved? It will not conflict with 0003, as they touch different files. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 21. Juni 2013 00:12 To: Lindenmaier, Goetz Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs Hmm 'breakpoint_type'? I don't remember that and I only see one use place in MacroAssembler::safepoint() on sparc and that method is not used anymore. I build SPARC VM without breakpoint_Relocation class (commented out). Looks like we can remove this type. thanks, Vladimir On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: > Hi, > > here the table from my last mail once more, with better formatting. > It shows what relocations are used in a simple jvm98 run. > > | x86_32 | x86_64 | ppc_64 > -------------------------------------------------- > oop | 44566 | 37129 | 24090 > virtual_call | 10422 | 9265 | 9727 > opt_virtual_call | 9083 | 8085 | 8344 > static_call | 435 | 404 | 423 > static_stub | 9518 | 8489 | 8767 > runtime_call | 61762 | 57695 | 27899 > external_word | 6919 | 9622 | 0 > internal_word | 3747 | 5898 | 40903 > poll | 2807 | 2476 | 2705 > poll_return | 2219 | 1989 | 2188 > breakpoint | 0 | 0 | 0 > section_word | 0 | 0 | 0 > trampoline_stub | 0 | 0 | 30428 > > current fillers | 2 | 34 | 3 > new filler needed | 9 | 144 | 0 > > Sum | 140176 | 130978 | 144942 > > > I did this with hs24, therefore metadata is missing, but > that should not affect the basic picture. > > Best regards, > Goetz. > > > > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose > Sent: Dienstag, 18. Juni 2013 21:40 > To: Bertrand Delsart > Cc: Roland Westrelin; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs > > On Jun 18, 2013, at 1:36 AM, Bertrand Delsart > wrote: > > This change is consuming the last unused relocType (yet_unused_type_2) > > Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) > > This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. > > The relocInfo records are stored as an array of unsigned shorts (u2). This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space. > > At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation. That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude. > > For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable. The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost. The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width. > > The variability could be encoded in the tag field itself (Huffman style, right-to-left): > type_width = 4, > type_width_2 = 6, > type_width_2_mask = 0x0003, > ... > bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; } > ... > > - John > > P.S. Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing. It is somewhat fragile and (I now think) over-clever. This is another thing I would like to change about the relocinfo mechanism, if it were rewritten. Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language. > > From bertrand.delsart at oracle.com Fri Jun 21 02:40:12 2013 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 21 Jun 2013 11:40:12 +0200 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> Message-ID: <51C41F7C.4060604@oracle.com> That's OK for me. Thanks for identifying a reloc type that could easily be recycled. Bertrand. On 06/21/13 10:55 AM, Lindenmaier, Goetz wrote: > Hi, > > I removed the breakpoint_Relocation, see > http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ > It builds and runs on sparc_64 and linuxx86_64. > > section_word_Relocation can not be removed simply. > Internal_word relocations are changed to section_word > by pack_data_to. I counted the relocations where they > are generated, so I did not catch this. So I didn't remove > them. > > I guess we should make an extra change for this, maybe even > push it to the hotspot-comp repository? It's got nothing to > do with the port. > > Bertrand, can I push 8016696: PPC64 (part 4), now as the problem > with the enum is solved? > It will not conflict with 0003, as they touch different files. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 21. Juni 2013 00:12 > To: Lindenmaier, Goetz > Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs > > Hmm 'breakpoint_type'? I don't remember that and I only see one use > place in MacroAssembler::safepoint() on sparc and that method is not > used anymore. > I build SPARC VM without breakpoint_Relocation class (commented out). > Looks like we can remove this type. > > thanks, > Vladimir > > On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> here the table from my last mail once more, with better formatting. >> It shows what relocations are used in a simple jvm98 run. >> >> | x86_32 | x86_64 | ppc_64 >> -------------------------------------------------- >> oop | 44566 | 37129 | 24090 >> virtual_call | 10422 | 9265 | 9727 >> opt_virtual_call | 9083 | 8085 | 8344 >> static_call | 435 | 404 | 423 >> static_stub | 9518 | 8489 | 8767 >> runtime_call | 61762 | 57695 | 27899 >> external_word | 6919 | 9622 | 0 >> internal_word | 3747 | 5898 | 40903 >> poll | 2807 | 2476 | 2705 >> poll_return | 2219 | 1989 | 2188 >> breakpoint | 0 | 0 | 0 >> section_word | 0 | 0 | 0 >> trampoline_stub | 0 | 0 | 30428 >> >> current fillers | 2 | 34 | 3 >> new filler needed | 9 | 144 | 0 >> >> Sum | 140176 | 130978 | 144942 >> >> >> I did this with hs24, therefore metadata is missing, but >> that should not affect the basic picture. >> >> Best regards, >> Goetz. >> >> >> >> From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose >> Sent: Dienstag, 18. Juni 2013 21:40 >> To: Bertrand Delsart >> Cc: Roland Westrelin; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs >> >> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart > wrote: >> >> This change is consuming the last unused relocType (yet_unused_type_2) >> >> Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) >> >> This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. >> >> The relocInfo records are stored as an array of unsigned shorts (u2). This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space. >> >> At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation. That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude. > >> >> For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable. The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost. The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width. >> >> The variability could be encoded in the tag field itself (Huffman style, right-to-left): >> type_width = 4, >> type_width_2 = 6, >> type_width_2_mask = 0x0003, >> ... >> bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; } >> ... >> >> - John >> >> P.S. Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing. It is somewhat fragile and (I now think) over-clever. This is another thing I would like to change about the relocinfo mechanism, if it were rewritten. Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language. >> >> -- Bertrand Delsart, bertrand.delsart at oracle.com Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From alejandro.murillo at oracle.com Fri Jun 21 04:34:19 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 21 Jun 2013 11:34:19 +0000 Subject: hg: hsx/hsx25/hotspot: 42 new changesets Message-ID: <20130621113550.19661483CF@hg.openjdk.java.net> Changeset: aaa45012be98 Author: katleman Date: 2013-06-20 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aaa45012be98 Added tag jdk8-b95 for changeset 5d65c078cd0a ! .hgtags Changeset: f9709e27a876 Author: amurillo Date: 2013-06-14 07:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f9709e27a876 8016567: new hotspot build - hs25-b38 Reviewed-by: jcoomes ! make/hotspot_version Changeset: a837fa3d3f86 Author: dcubed Date: 2013-06-13 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a837fa3d3f86 8013057: assert(_needs_gc || SafepointSynchronize::is_at_safepoint()) failed: only read at safepoint Summary: Detect mmap() commit failures in Linux and Solaris os::commit_memory() impls and call vm_exit_out_of_memory(). Add os::commit_memory_or_exit(). Also tidy up some NMT accounting and some mmap() return value checking. Reviewed-by: zgu, stefank, dholmes, dsamersoff ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 2bffd20a0fcc Author: ctornqvi Date: 2013-06-13 21:57 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2bffd20a0fcc 8016065: Write regression test for 7167142 Summary: Regression tests written for both test cases (.hotspotrc and .hotspot_compiler). Also reviewed by mikhailo.seledtsov at oracle.com Reviewed-by: zgu, coleenp + test/runtime/CommandLine/CompilerConfigFileWarning.java + test/runtime/CommandLine/ConfigFileWarning.java Changeset: 1e9094165098 Author: ctornqvi Date: 2013-06-13 22:00 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1e9094165098 8015324: Create tests for CDS feature Summary: Wrote tests for use of CDS with ObjectAlignmentInBytes CL option Reviewed-by: coleenp, ctornqvi, hseigel Contributed-by: Mikhailo Seledtsov + test/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java + test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java + test/testlibrary/com/oracle/java/testlibrary/Platform.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: a0a47b2649a2 Author: ctornqvi Date: 2013-06-14 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a0a47b2649a2 Merge Changeset: ef57c43512d6 Author: ccheung Date: 2013-06-13 22:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ef57c43512d6 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux Reviewed-by: dholmes, coleenp Contributed-by: jeremymanson at google.com, calvin.cheung at oracle.com ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/genericSignatures.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: bcb96b2922f2 Author: zgu Date: 2013-06-14 07:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bcb96b2922f2 Merge Changeset: ab313d4e9a8b Author: zgu Date: 2013-06-14 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ab313d4e9a8b 8011968: Kitchensink crashed with SIGSEGV in MemBaseline::baseline Summary: Simple fix to add NULL pointer check that can cause segv Reviewed-by: coleenp, ctornqvi ! src/share/vm/services/memBaseline.cpp Changeset: dba2306ee2e3 Author: zgu Date: 2013-06-14 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dba2306ee2e3 Merge Changeset: 3aaa16611c30 Author: zgu Date: 2013-06-14 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3aaa16611c30 Merge Changeset: e95fc50106cf Author: rdurbin Date: 2013-06-14 07:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e95fc50106cf 7178026: os::close can restart ::close but that is not a restartable syscall Summary: Removed restart macros from all os:close calls on Solaris, Linux, MacOS X platforms. Reviewed-by: dcubed, dholmes ! src/os/bsd/dtrace/jvm_dtrace.c ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp Changeset: f2d56a269345 Author: dcubed Date: 2013-06-14 08:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f2d56a269345 Merge Changeset: c7242a797916 Author: dcubed Date: 2013-06-14 19:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c7242a797916 Merge Changeset: 5c89346f2bdd Author: sspitsyn Date: 2013-06-14 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5c89346f2bdd 6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description Summary: A typo in the parameter spelling, a bound update missed when the parameter was renamed Reviewed-by: sla, minqi Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmti.xml Changeset: 7fa28f3d3f62 Author: sspitsyn Date: 2013-06-14 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7fa28f3d3f62 Merge Changeset: abbd5c660b48 Author: mgronlun Date: 2013-06-15 13:17 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/abbd5c660b48 8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp Reviewed-by: sla, rbackman ! src/share/vm/memory/allocation.hpp Changeset: cd2118b62475 Author: zgu Date: 2013-06-10 10:45 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cd2118b62475 8013917: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Simple fix when memory allocation site is gone, NMT should report 0 memory size, instead old memory size. Reviewed-by: dcubed, ctornqvi ! src/share/vm/services/memReporter.cpp Changeset: ef748153ee8f Author: sla Date: 2013-06-17 18:35 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ef748153ee8f 8016304: ThreadMXBean.getDeadlockedThreads reports bogus deadlocks on JDK 8 Reviewed-by: dcubed, mgronlun ! src/share/vm/services/threadService.cpp + test/serviceability/threads/TestFalseDeadLock.java Changeset: 1f4355cee9a2 Author: zgu Date: 2013-06-18 08:44 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1f4355cee9a2 8013651: NMT: reserve/release sequence id's in incorrect order due to race Summary: Fixed NMT race condition for realloc, uncommit and release Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: a5904a086d9f Author: zgu Date: 2013-06-18 09:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a5904a086d9f Merge Changeset: cd54c7e92908 Author: minqi Date: 2013-06-18 09:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cd54c7e92908 8015660: Test8009761.java "Failed: init recursive calls: 24. After deopt 25" Summary: Windows reserves and only partially commits thread stack. For detecting more thread stack space for execution, Windows installs one-shot page as guard page just before the current commited edge. It will trigger STACK_OVERFLOW_EXCEPTION when lands on last 4 pages of thread stack space. StackYellowPages default value is 2 on Windows (plus 1 page of StackRedPages, 3 pages guarded by hotspot) so the exception happens one page before Yellow pages. Same route executed second time will have one more page brought in, this leads same execution with different stack depth(interpreter mode). We need match Windows settings so the stack overflow exception will not happen before Yellow pages. Reviewed-by: dholmes Contributed-by: andreas.schoesser at sap.com ! src/cpu/x86/vm/globals_x86.hpp Changeset: 726d2d4913fc Author: nloodin Date: 2013-06-19 18:13 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/726d2d4913fc Merge Changeset: 0abfeed51c9e Author: brutisso Date: 2013-06-14 08:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0abfeed51c9e 8012265: VM often crashes on solaris with a lot of memory Summary: Increase HeapBaseMinAddress for G1 from 256m to 1g on Solaris x86 Reviewed-by: mgerdin, coleenp, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 01522ca68fc7 Author: johnc Date: 2013-06-18 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/01522ca68fc7 8015237: Parallelize string table scanning during strong root processing Summary: Parallelize the scanning of the intern string table by having each GC worker claim a given number of buckets. Changes were also reviewed by Per Liden . Reviewed-by: tschatzl, stefank, twisti ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: b9d151496930 Author: brutisso Date: 2013-06-18 22:45 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b9d151496930 8016556: G1: Use ArrayAllocator for BitMaps Reviewed-by: tschatzl, dholmes, coleenp, johnc ! src/share/vm/memory/allocation.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp Changeset: 493089fd29df Author: poonam Date: 2013-06-19 06:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/493089fd29df 8015903: Format issue with -XX:+PrintAdaptiveSizePolicy on JDK8 Summary: Missing linebreak in hotspot log. Reviewed-by: brutisso, tschatzl Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp Changeset: 9f9c0a163cc5 Author: ehelin Date: 2013-06-20 10:03 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9f9c0a163cc5 Merge ! src/share/vm/memory/allocation.hpp Changeset: 8d52e305a777 Author: morris Date: 2013-06-07 07:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8d52e305a777 8015437: SPARC cbcond branch offset out of 10-bit range Summary: Forced SPARC MacroAssembler eden_alloate to use long branch to slow case Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/macroAssembler_sparc.cpp Changeset: ea60d1de6735 Author: kvn Date: 2013-06-07 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ea60d1de6735 Merge Changeset: 46c544b8fbfc Author: morris Date: 2013-06-07 16:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/46c544b8fbfc 8008407: remove SPARC V8 support Summary: Removed most of the SPARC V8 instructions Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/share/vm/runtime/arguments.cpp Changeset: e7f5651d459c Author: twisti Date: 2013-06-11 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e7f5651d459c 8003268: SharedRuntime::generate_native_wrapper doesn't save all registers across runtime tracing calls for JNI critical native methods Reviewed-by: kvn ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 693e4d04fd09 Author: drchase Date: 2013-06-11 16:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/693e4d04fd09 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit Summary: Insert extra checks and bailouts for too many nodes Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/matcher.cpp Changeset: bc8956037049 Author: kvn Date: 2013-06-11 16:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bc8956037049 Merge Changeset: c52abc8a0b08 Author: drchase Date: 2013-06-13 15:39 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c52abc8a0b08 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink Summary: replace linked data structure with array (performance) Reviewed-by: kvn Contributed-by: christian.thalinger at oracle.com, david.r.chase at oracle.com ! src/share/vm/prims/jvm.cpp Changeset: 7fa25f5575c9 Author: adlertz Date: 2013-06-14 01:19 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7fa25f5575c9 8016157: During CTW: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Summary: Disable rematerialization for negD node Reviewed-by: kvn, roland ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp Changeset: ac91879aa56f Author: kvn Date: 2013-06-14 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ac91879aa56f Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/prims/jvm.cpp Changeset: 87a6f2df28e2 Author: drchase Date: 2013-06-17 12:35 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/87a6f2df28e2 8002160: Compilation issue with adlc using latest SunStudio compilers Summary: modify declaration of 'swap' overloading; dodge optimizer bug in c1_LIR.cpp Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/share/vm/c1/c1_LIR.cpp Changeset: 08d35fd1b599 Author: adlertz Date: 2013-06-19 00:41 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/08d35fd1b599 8001345: VM crashes with assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove unnecessary LoadN / DecodeN nodes at MemBarAcquire nodes. Reviewed-by: kvn, roland ! src/share/vm/opto/memnode.cpp Changeset: b88209cf98c0 Author: kvn Date: 2013-06-20 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b88209cf98c0 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 2cc5a9d1ba66 Author: amurillo Date: 2013-06-21 00:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2cc5a9d1ba66 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 3bdeff4a6ca7 Author: amurillo Date: 2013-06-21 00:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3bdeff4a6ca7 Added tag hs25-b38 for changeset 2cc5a9d1ba66 ! .hgtags From vladimir.kozlov at oracle.com Fri Jun 21 06:14:25 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 21 Jun 2013 13:14:25 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130621131434.85D0B483D4@hg.openjdk.java.net> Changeset: 1aa21f922568 Author: kvn Date: 2013-06-20 19:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1aa21f922568 8007028: java/util/NavigableMap/LockStep hit assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr Summary: do not allow switch on EliminateAutoBox in hs24. Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp Changeset: fde31393d1ce Author: adlertz Date: 2013-06-03 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fde31393d1ce 8005956: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Summary: Disable re-materialization of reaching definitions (which have live inputs) for phi nodes when spilling. Reviewed-by: twisti, kvn ! src/share/vm/opto/reg_split.cpp Changeset: cf6a8e400e0f Author: kvn Date: 2013-06-20 23:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cf6a8e400e0f Merge From alejandro.murillo at oracle.com Fri Jun 21 07:57:08 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 21 Jun 2013 14:57:08 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130621145719.92495483DA@hg.openjdk.java.net> Changeset: aaa45012be98 Author: katleman Date: 2013-06-20 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aaa45012be98 Added tag jdk8-b95 for changeset 5d65c078cd0a ! .hgtags Changeset: 2cc5a9d1ba66 Author: amurillo Date: 2013-06-21 00:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2cc5a9d1ba66 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 3bdeff4a6ca7 Author: amurillo Date: 2013-06-21 00:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3bdeff4a6ca7 Added tag hs25-b38 for changeset 2cc5a9d1ba66 ! .hgtags Changeset: fc8a1a5de78e Author: amurillo Date: 2013-06-21 00:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fc8a1a5de78e 8017253: new hotspot build - hs25-b39 Reviewed-by: jcoomes ! make/hotspot_version From kevin.walls at oracle.com Fri Jun 21 08:10:14 2013 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Fri, 21 Jun 2013 15:10:14 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130621151021.A65DB483DB@hg.openjdk.java.net> Changeset: 011c19ff2552 Author: minqi Date: 2013-01-31 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/011c19ff2552 8000973: SA on windows thread inspection is broken Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. Reviewed-by: nloodin, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java Changeset: 0464a0d982b3 Author: kevinw Date: 2013-06-21 12:56 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0464a0d982b3 Merge Changeset: 0b260439fc78 Author: kevinw Date: 2013-06-21 15:17 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0b260439fc78 Merge From vladimir.kozlov at oracle.com Fri Jun 21 08:35:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Jun 2013 08:35:53 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> Message-ID: <51C472D9.2050908@oracle.com> Goetz, Thank you for preparing patch. Yes, we better do it separate in our repo because we may need to change closed sources also. The marge with your (part 4) changes later will be pain but we will manage. Thanks, Vladimir On 6/21/13 1:55 AM, Lindenmaier, Goetz wrote: > Hi, > > I removed the breakpoint_Relocation, see > http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ > It builds and runs on sparc_64 and linuxx86_64. > > section_word_Relocation can not be removed simply. > Internal_word relocations are changed to section_word > by pack_data_to. I counted the relocations where they > are generated, so I did not catch this. So I didn't remove > them. > > I guess we should make an extra change for this, maybe even > push it to the hotspot-comp repository? It's got nothing to > do with the port. > > Bertrand, can I push 8016696: PPC64 (part 4), now as the problem > with the enum is solved? > It will not conflict with 0003, as they touch different files. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 21. Juni 2013 00:12 > To: Lindenmaier, Goetz > Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs > > Hmm 'breakpoint_type'? I don't remember that and I only see one use > place in MacroAssembler::safepoint() on sparc and that method is not > used anymore. > I build SPARC VM without breakpoint_Relocation class (commented out). > Looks like we can remove this type. > > thanks, > Vladimir > > On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> here the table from my last mail once more, with better formatting. >> It shows what relocations are used in a simple jvm98 run. >> >> | x86_32 | x86_64 | ppc_64 >> -------------------------------------------------- >> oop | 44566 | 37129 | 24090 >> virtual_call | 10422 | 9265 | 9727 >> opt_virtual_call | 9083 | 8085 | 8344 >> static_call | 435 | 404 | 423 >> static_stub | 9518 | 8489 | 8767 >> runtime_call | 61762 | 57695 | 27899 >> external_word | 6919 | 9622 | 0 >> internal_word | 3747 | 5898 | 40903 >> poll | 2807 | 2476 | 2705 >> poll_return | 2219 | 1989 | 2188 >> breakpoint | 0 | 0 | 0 >> section_word | 0 | 0 | 0 >> trampoline_stub | 0 | 0 | 30428 >> >> current fillers | 2 | 34 | 3 >> new filler needed | 9 | 144 | 0 >> >> Sum | 140176 | 130978 | 144942 >> >> >> I did this with hs24, therefore metadata is missing, but >> that should not affect the basic picture. >> >> Best regards, >> Goetz. >> >> >> >> From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose >> Sent: Dienstag, 18. Juni 2013 21:40 >> To: Bertrand Delsart >> Cc: Roland Westrelin; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs >> >> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart > wrote: >> >> This change is consuming the last unused relocType (yet_unused_type_2) >> >> Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-)) >> >> This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType. >> >> The relocInfo records are stored as an array of unsigned shorts (u2). This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space. >> >> At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation. That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude. > >> >> For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable. The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost. The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width. >> >> The variability could be encoded in the tag field itself (Huffman style, right-to-left): >> type_width = 4, >> type_width_2 = 6, >> type_width_2_mask = 0x0003, >> ... >> bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; } >> ... >> >> - John >> >> P.S. Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing. It is somewhat fragile and (I now think) over-clever. This is another thing I would like to change about the relocinfo mechanism, if it were rewritten. Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language. >> >> From volker.simonis at gmail.com Fri Jun 21 08:48:43 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Jun 2013 17:48:43 +0200 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51C472D9.2050908@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> <51C472D9.2050908@oracle.com> Message-ID: What do you think how much time it will take to push this change to hsx/ and jdk8/hotspot (as far as I see it is already reviewed - right?). If you could do it fast, perhaps we can wait until it arrives in the staging repository from up-stream (anyway we wanted to sync regularly with upstream). I think omitting this patch will not block the next few changes we have and if it will arrive in jdk8/hotspot within 2 or 3 weeks it may save us the pain of the merging. What do you think? Volker On Fri, Jun 21, 2013 at 5:35 PM, Vladimir Kozlov wrote: > Goetz, > > Thank you for preparing patch. Yes, we better do it separate in our repo > because we may need to change closed sources also. The marge with your (part > 4) changes later will be pain but we will manage. > > Thanks, > Vladimir > > > On 6/21/13 1:55 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> I removed the breakpoint_Relocation, see >> http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ >> It builds and runs on sparc_64 and linuxx86_64. >> >> section_word_Relocation can not be removed simply. >> Internal_word relocations are changed to section_word >> by pack_data_to. I counted the relocations where they >> are generated, so I did not catch this. So I didn't remove >> them. >> >> I guess we should make an extra change for this, maybe even >> push it to the hotspot-comp repository? It's got nothing to >> do with the port. >> >> Bertrand, can I push 8016696: PPC64 (part 4), now as the problem >> with the enum is solved? >> It will not conflict with 0003, as they touch different files. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Freitag, 21. Juni 2013 00:12 >> To: Lindenmaier, Goetz >> Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll >> (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; >> 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >> trampoline stubs >> >> Hmm 'breakpoint_type'? I don't remember that and I only see one use >> place in MacroAssembler::safepoint() on sparc and that method is not >> used anymore. >> I build SPARC VM without breakpoint_Relocation class (commented out). >> Looks like we can remove this type. >> >> thanks, >> Vladimir >> >> On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> here the table from my last mail once more, with better formatting. >>> It shows what relocations are used in a simple jvm98 run. >>> >>> | x86_32 | x86_64 | ppc_64 >>> -------------------------------------------------- >>> oop | 44566 | 37129 | 24090 >>> virtual_call | 10422 | 9265 | 9727 >>> opt_virtual_call | 9083 | 8085 | 8344 >>> static_call | 435 | 404 | 423 >>> static_stub | 9518 | 8489 | 8767 >>> runtime_call | 61762 | 57695 | 27899 >>> external_word | 6919 | 9622 | 0 >>> internal_word | 3747 | 5898 | 40903 >>> poll | 2807 | 2476 | 2705 >>> poll_return | 2219 | 1989 | 2188 >>> breakpoint | 0 | 0 | 0 >>> section_word | 0 | 0 | 0 >>> trampoline_stub | 0 | 0 | 30428 >>> >>> current fillers | 2 | 34 | 3 >>> new filler needed | 9 | 144 | 0 >>> >>> Sum | 140176 | 130978 | 144942 >>> >>> >>> I did this with hs24, therefore metadata is missing, but >>> that should not affect the basic picture. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> From: >>> ppc-aix-port-dev-bounces at openjdk.java.net >>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose >>> Sent: Dienstag, 18. Juni 2013 21:40 >>> To: Bertrand Delsart >>> Cc: Roland Westrelin; >>> ppc-aix-port-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>> trampoline stubs >>> >>> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart >>> > wrote: >>> >>> This change is consuming the last unused relocType (yet_unused_type_2) >>> >>> Unfortunately, that relocType is also used for other projects both within >>> the embedded team and the compiler team (you should not which one I am >>> speaking about Roland :-)) >>> >>> This means relocType will no longer fit into 4 bits. I'll let you see >>> with the compiler team whether this can easily be solved (by increasing the >>> size or recycling other reloc types) or whether we need to discuss more >>> before deciding how to use the last available relocType. >>> >>> The relocInfo records are stored as an array of unsigned shorts (u2). >>> This slightly simplifies random access compared with a CompressedStream >>> representation, but otherwise is less dense and pits tag space directly >>> against offset space. >>> >>> At some point I would like to see them re-engineered using >>> CompressedStream, which is built on the more robust UNSIGNED5 >>> representation. That would allow reloc info tokens to be built from 32-bit >>> values, as long as most of them were small in magnitude. >> >> >>> >>> For now, as an incremental change, it would be reasonable to make the tag >>> width (type_width) be variable. The most common tags could be encoded as 4 >>> bits and the least common 25% in (say) 6, giving a 75% increase in coding >>> space at small cost. The extra tag bits would break into the value field >>> (for the less-common tags). There is already a mechanism for dealing with >>> value field overflow, which could be adapted to be sensitive to the tag >>> width. >>> >>> The variability could be encoded in the tag field itself (Huffman style, >>> right-to-left): >>> type_width = 4, >>> type_width_2 = 6, >>> type_width_2_mask = 0x0003, >>> ... >>> bool type_width() { (_value & type_width_2_mask) == type_width_2_mask >>> ? type_width_2 : type_width; } >>> ... >>> >>> - John >>> >>> P.S. Back in the day, I wrote the flyweight object mechanism by which >>> reloc info streams are loaded with objects that are both by-value and >>> virtual-function-bearing. It is somewhat fragile and (I now think) >>> over-clever. This is another thing I would like to change about the >>> relocinfo mechanism, if it were rewritten. Since then other parts of the >>> JVM have used stream-like structs like RelocIterator, but they don't mess >>> around with vtables in rewritable stack objects, which (IMO) are at the edge >>> of the C++ language. >>> >>> > From coleen.phillimore at oracle.com Fri Jun 21 09:35:31 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 21 Jun 2013 12:35:31 -0400 Subject: RFR 8016325: JVM hangs verifying system dictionary Message-ID: <51C480D3.1050100@oracle.com> Summary: Minimize redundant verifications of Klasses. Also removed is_metadata() because checking that metadata is not in the Java heap doesn't make sense anymore and could slow down verification also. Some cases that aren't statically checked by the compiler now call is_metaspace_object() under assert for verification. Tested by nsk.quick.testlist, and failing SQE test. open webrev at http://cr.openjdk.java.net/~coleenp/8016325/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8016325 local bug link https://jbs.oracle.com/bugs/browse/JDK-8016325 thanks, Coleen From vladimir.kozlov at oracle.com Fri Jun 21 09:38:56 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Jun 2013 09:38:56 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> <51C472D9.2050908@oracle.com> Message-ID: <51C481A0.4040801@oracle.com> It should be in jdk8/hotspot in 2 weeks. We will push in comp repo today or on Monday. It would be best if you can wait. I will file next bugs for part 6 and part 7 so we can start working on them. About my push for 'part 3'. I used it for an experiment :) which was not successful :( . We have several JPRT connected systems and I tried to keep files on one system with bigger disk space but to run on an other JPRT with much less jobs in queue. And it was disaster - job did not complete after 14 hours (NFS access was terrible). So I am rerunning it again in local JPRT. That was the reason why it was not pushed yet. I also want to do sync from main forest after that, we pushed big changes there this week. Thanks, Vladimir On 6/21/13 8:48 AM, Volker Simonis wrote: > What do you think how much time it will take to push this change to > hsx/ and jdk8/hotspot (as far as I see it is already reviewed - > right?). If you could do it fast, perhaps we can wait until it arrives > in the staging repository from up-stream (anyway we wanted to sync > regularly with upstream). > > I think omitting this patch will not block the next few changes we > have and if it will arrive in jdk8/hotspot within 2 or 3 weeks it may > save us the pain of the merging. > > What do you think? > Volker > > > On Fri, Jun 21, 2013 at 5:35 PM, Vladimir Kozlov > wrote: >> Goetz, >> >> Thank you for preparing patch. Yes, we better do it separate in our repo >> because we may need to change closed sources also. The marge with your (part >> 4) changes later will be pain but we will manage. >> >> Thanks, >> Vladimir >> >> >> On 6/21/13 1:55 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> I removed the breakpoint_Relocation, see >>> http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ >>> It builds and runs on sparc_64 and linuxx86_64. >>> >>> section_word_Relocation can not be removed simply. >>> Internal_word relocations are changed to section_word >>> by pack_data_to. I counted the relocations where they >>> are generated, so I did not catch this. So I didn't remove >>> them. >>> >>> I guess we should make an extra change for this, maybe even >>> push it to the hotspot-comp repository? It's got nothing to >>> do with the port. >>> >>> Bertrand, can I push 8016696: PPC64 (part 4), now as the problem >>> with the enum is solved? >>> It will not conflict with 0003, as they touch different files. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Freitag, 21. Juni 2013 00:12 >>> To: Lindenmaier, Goetz >>> Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll >>> (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; >>> 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>> trampoline stubs >>> >>> Hmm 'breakpoint_type'? I don't remember that and I only see one use >>> place in MacroAssembler::safepoint() on sparc and that method is not >>> used anymore. >>> I build SPARC VM without breakpoint_Relocation class (commented out). >>> Looks like we can remove this type. >>> >>> thanks, >>> Vladimir >>> >>> On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> here the table from my last mail once more, with better formatting. >>>> It shows what relocations are used in a simple jvm98 run. >>>> >>>> | x86_32 | x86_64 | ppc_64 >>>> -------------------------------------------------- >>>> oop | 44566 | 37129 | 24090 >>>> virtual_call | 10422 | 9265 | 9727 >>>> opt_virtual_call | 9083 | 8085 | 8344 >>>> static_call | 435 | 404 | 423 >>>> static_stub | 9518 | 8489 | 8767 >>>> runtime_call | 61762 | 57695 | 27899 >>>> external_word | 6919 | 9622 | 0 >>>> internal_word | 3747 | 5898 | 40903 >>>> poll | 2807 | 2476 | 2705 >>>> poll_return | 2219 | 1989 | 2188 >>>> breakpoint | 0 | 0 | 0 >>>> section_word | 0 | 0 | 0 >>>> trampoline_stub | 0 | 0 | 30428 >>>> >>>> current fillers | 2 | 34 | 3 >>>> new filler needed | 9 | 144 | 0 >>>> >>>> Sum | 140176 | 130978 | 144942 >>>> >>>> >>>> I did this with hs24, therefore metadata is missing, but >>>> that should not affect the basic picture. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> From: >>>> ppc-aix-port-dev-bounces at openjdk.java.net >>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose >>>> Sent: Dienstag, 18. Juni 2013 21:40 >>>> To: Bertrand Delsart >>>> Cc: Roland Westrelin; >>>> ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>>> trampoline stubs >>>> >>>> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart >>>> > wrote: >>>> >>>> This change is consuming the last unused relocType (yet_unused_type_2) >>>> >>>> Unfortunately, that relocType is also used for other projects both within >>>> the embedded team and the compiler team (you should not which one I am >>>> speaking about Roland :-)) >>>> >>>> This means relocType will no longer fit into 4 bits. I'll let you see >>>> with the compiler team whether this can easily be solved (by increasing the >>>> size or recycling other reloc types) or whether we need to discuss more >>>> before deciding how to use the last available relocType. >>>> >>>> The relocInfo records are stored as an array of unsigned shorts (u2). >>>> This slightly simplifies random access compared with a CompressedStream >>>> representation, but otherwise is less dense and pits tag space directly >>>> against offset space. >>>> >>>> At some point I would like to see them re-engineered using >>>> CompressedStream, which is built on the more robust UNSIGNED5 >>>> representation. That would allow reloc info tokens to be built from 32-bit >>>> values, as long as most of them were small in magnitude. >>> >>> >>>> >>>> For now, as an incremental change, it would be reasonable to make the tag >>>> width (type_width) be variable. The most common tags could be encoded as 4 >>>> bits and the least common 25% in (say) 6, giving a 75% increase in coding >>>> space at small cost. The extra tag bits would break into the value field >>>> (for the less-common tags). There is already a mechanism for dealing with >>>> value field overflow, which could be adapted to be sensitive to the tag >>>> width. >>>> >>>> The variability could be encoded in the tag field itself (Huffman style, >>>> right-to-left): >>>> type_width = 4, >>>> type_width_2 = 6, >>>> type_width_2_mask = 0x0003, >>>> ... >>>> bool type_width() { (_value & type_width_2_mask) == type_width_2_mask >>>> ? type_width_2 : type_width; } >>>> ... >>>> >>>> - John >>>> >>>> P.S. Back in the day, I wrote the flyweight object mechanism by which >>>> reloc info streams are loaded with objects that are both by-value and >>>> virtual-function-bearing. It is somewhat fragile and (I now think) >>>> over-clever. This is another thing I would like to change about the >>>> relocinfo mechanism, if it were rewritten. Since then other parts of the >>>> JVM have used stream-like structs like RelocIterator, but they don't mess >>>> around with vtables in rewritable stack objects, which (IMO) are at the edge >>>> of the C++ language. >>>> >>>> >> From volker.simonis at gmail.com Fri Jun 21 09:47:18 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Jun 2013 18:47:18 +0200 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51C481A0.4040801@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> <51C472D9.2050908@oracle.com> <51C481A0.4040801@oracle.com> Message-ID: Sounds good (I mean the "should be there in two weeks" part :) Thanks, Volker On Fri, Jun 21, 2013 at 6:38 PM, Vladimir Kozlov wrote: > It should be in jdk8/hotspot in 2 weeks. We will push in comp repo today or > on Monday. It would be best if you can wait. I will file next bugs for part > 6 and part 7 so we can start working on them. > > About my push for 'part 3'. I used it for an experiment :) which was not > successful :( . We have several JPRT connected systems and I tried to keep > files on one system with bigger disk space but to run on an other JPRT with > much less jobs in queue. And it was disaster - job did not complete after 14 > hours (NFS access was terrible). So I am rerunning it again in local JPRT. > That was the reason why it was not pushed yet. > > I also want to do sync from main forest after that, we pushed big changes > there this week. > > Thanks, > Vladimir > > > On 6/21/13 8:48 AM, Volker Simonis wrote: >> >> What do you think how much time it will take to push this change to >> hsx/ and jdk8/hotspot (as far as I see it is already reviewed - >> right?). If you could do it fast, perhaps we can wait until it arrives >> in the staging repository from up-stream (anyway we wanted to sync >> regularly with upstream). >> >> I think omitting this patch will not block the next few changes we >> have and if it will arrive in jdk8/hotspot within 2 or 3 weeks it may >> save us the pain of the merging. >> >> What do you think? >> Volker >> >> >> On Fri, Jun 21, 2013 at 5:35 PM, Vladimir Kozlov >> wrote: >>> >>> Goetz, >>> >>> Thank you for preparing patch. Yes, we better do it separate in our repo >>> because we may need to change closed sources also. The marge with your >>> (part >>> 4) changes later will be pain but we will manage. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 6/21/13 1:55 AM, Lindenmaier, Goetz wrote: >>>> >>>> >>>> Hi, >>>> >>>> I removed the breakpoint_Relocation, see >>>> http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ >>>> It builds and runs on sparc_64 and linuxx86_64. >>>> >>>> section_word_Relocation can not be removed simply. >>>> Internal_word relocations are changed to section_word >>>> by pack_data_to. I counted the relocations where they >>>> are generated, so I did not catch this. So I didn't remove >>>> them. >>>> >>>> I guess we should make an extra change for this, maybe even >>>> push it to the hotspot-comp repository? It's got nothing to >>>> do with the port. >>>> >>>> Bertrand, can I push 8016696: PPC64 (part 4), now as the problem >>>> with the enum is solved? >>>> It will not conflict with 0003, as they touch different files. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Freitag, 21. Juni 2013 00:12 >>>> To: Lindenmaier, Goetz >>>> Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll >>>> (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; >>>> 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>>> trampoline stubs >>>> >>>> Hmm 'breakpoint_type'? I don't remember that and I only see one use >>>> place in MacroAssembler::safepoint() on sparc and that method is not >>>> used anymore. >>>> I build SPARC VM without breakpoint_Relocation class (commented out). >>>> Looks like we can remove this type. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> here the table from my last mail once more, with better formatting. >>>>> It shows what relocations are used in a simple jvm98 run. >>>>> >>>>> | x86_32 | x86_64 | ppc_64 >>>>> -------------------------------------------------- >>>>> oop | 44566 | 37129 | 24090 >>>>> virtual_call | 10422 | 9265 | 9727 >>>>> opt_virtual_call | 9083 | 8085 | 8344 >>>>> static_call | 435 | 404 | 423 >>>>> static_stub | 9518 | 8489 | 8767 >>>>> runtime_call | 61762 | 57695 | 27899 >>>>> external_word | 6919 | 9622 | 0 >>>>> internal_word | 3747 | 5898 | 40903 >>>>> poll | 2807 | 2476 | 2705 >>>>> poll_return | 2219 | 1989 | 2188 >>>>> breakpoint | 0 | 0 | 0 >>>>> section_word | 0 | 0 | 0 >>>>> trampoline_stub | 0 | 0 | 30428 >>>>> >>>>> current fillers | 2 | 34 | 3 >>>>> new filler needed | 9 | 144 | 0 >>>>> >>>>> Sum | 140176 | 130978 | 144942 >>>>> >>>>> >>>>> I did this with hs24, therefore metadata is missing, but >>>>> that should not affect the basic picture. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> From: >>>>> >>>>> ppc-aix-port-dev-bounces at openjdk.java.net >>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John >>>>> Rose >>>>> Sent: Dienstag, 18. Juni 2013 21:40 >>>>> To: Bertrand Delsart >>>>> Cc: Roland Westrelin; >>>>> >>>>> ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>>>> trampoline stubs >>>>> >>>>> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart >>>>> > >>>>> wrote: >>>>> >>>>> This change is consuming the last unused relocType (yet_unused_type_2) >>>>> >>>>> Unfortunately, that relocType is also used for other projects both >>>>> within >>>>> the embedded team and the compiler team (you should not which one I am >>>>> speaking about Roland :-)) >>>>> >>>>> This means relocType will no longer fit into 4 bits. I'll let you see >>>>> with the compiler team whether this can easily be solved (by increasing >>>>> the >>>>> size or recycling other reloc types) or whether we need to discuss more >>>>> before deciding how to use the last available relocType. >>>>> >>>>> The relocInfo records are stored as an array of unsigned shorts (u2). >>>>> This slightly simplifies random access compared with a CompressedStream >>>>> representation, but otherwise is less dense and pits tag space directly >>>>> against offset space. >>>>> >>>>> At some point I would like to see them re-engineered using >>>>> CompressedStream, which is built on the more robust UNSIGNED5 >>>>> representation. That would allow reloc info tokens to be built from >>>>> 32-bit >>>>> values, as long as most of them were small in magnitude. >>>> >>>> >>>> >>>>> >>>>> For now, as an incremental change, it would be reasonable to make the >>>>> tag >>>>> width (type_width) be variable. The most common tags could be encoded >>>>> as 4 >>>>> bits and the least common 25% in (say) 6, giving a 75% increase in >>>>> coding >>>>> space at small cost. The extra tag bits would break into the value >>>>> field >>>>> (for the less-common tags). There is already a mechanism for dealing >>>>> with >>>>> value field overflow, which could be adapted to be sensitive to the tag >>>>> width. >>>>> >>>>> The variability could be encoded in the tag field itself (Huffman >>>>> style, >>>>> right-to-left): >>>>> type_width = 4, >>>>> type_width_2 = 6, >>>>> type_width_2_mask = 0x0003, >>>>> ... >>>>> bool type_width() { (_value & type_width_2_mask) == >>>>> type_width_2_mask >>>>> ? type_width_2 : type_width; } >>>>> ... >>>>> >>>>> - John >>>>> >>>>> P.S. Back in the day, I wrote the flyweight object mechanism by which >>>>> reloc info streams are loaded with objects that are both by-value and >>>>> virtual-function-bearing. It is somewhat fragile and (I now think) >>>>> over-clever. This is another thing I would like to change about the >>>>> relocinfo mechanism, if it were rewritten. Since then other parts of >>>>> the >>>>> JVM have used stream-like structs like RelocIterator, but they don't >>>>> mess >>>>> around with vtables in rewritable stack objects, which (IMO) are at the >>>>> edge >>>>> of the C++ language. >>>>> >>>>> >>> > From markus.gronlund at oracle.com Fri Jun 21 12:55:10 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Fri, 21 Jun 2013 19:55:10 +0000 Subject: hg: hsx/hsx24/hotspot: 8016735: Remove superfluous EnableInvokeDynamic warning from UnlockDiagnosticVMOptions check Message-ID: <20130621195514.90E61483F3@hg.openjdk.java.net> Changeset: 1c45f52dad23 Author: mgronlun Date: 2013-06-21 18:51 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1c45f52dad23 8016735: Remove superfluous EnableInvokeDynamic warning from UnlockDiagnosticVMOptions check Reviewed-by: sla, dholmes ! src/share/vm/runtime/globals.cpp From goetz.lindenmaier at sap.com Fri Jun 21 15:30:40 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Jun 2013 22:30:40 +0000 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <51C481A0.4040801@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> <51C472D9.2050908@oracle.com> <51C481A0.4040801@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFED5E1@DEWDFEMB12A.global.corp.sap> Hi, that all sounds fine to me. I will wait pushing 4 until the bp_reloc removal change shows up in the staging repo. But we could go without that change, anyways. We need a bugid for the bp_reloc removal, please. I can make a webrev against the current hotspot-comp. It's good if you update the repository, because I have to do some changes to the patches queue, e.g., do the SuspendResume changes as they come with JEP 167 on aix. And I assume 8016157 will help the port, at least we had similar problems with rematerialization in our VM and the port. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, June 21, 2013 6:39 PM To: Volker Simonis Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Bertrand Delsart; John Rose Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs It should be in jdk8/hotspot in 2 weeks. We will push in comp repo today or on Monday. It would be best if you can wait. I will file next bugs for part 6 and part 7 so we can start working on them. About my push for 'part 3'. I used it for an experiment :) which was not successful :( . We have several JPRT connected systems and I tried to keep files on one system with bigger disk space but to run on an other JPRT with much less jobs in queue. And it was disaster - job did not complete after 14 hours (NFS access was terrible). So I am rerunning it again in local JPRT. That was the reason why it was not pushed yet. I also want to do sync from main forest after that, we pushed big changes there this week. Thanks, Vladimir On 6/21/13 8:48 AM, Volker Simonis wrote: > What do you think how much time it will take to push this change to > hsx/ and jdk8/hotspot (as far as I see it is already reviewed - > right?). If you could do it fast, perhaps we can wait until it arrives > in the staging repository from up-stream (anyway we wanted to sync > regularly with upstream). > > I think omitting this patch will not block the next few changes we > have and if it will arrive in jdk8/hotspot within 2 or 3 weeks it may > save us the pain of the merging. > > What do you think? > Volker > > > On Fri, Jun 21, 2013 at 5:35 PM, Vladimir Kozlov > wrote: >> Goetz, >> >> Thank you for preparing patch. Yes, we better do it separate in our repo >> because we may need to change closed sources also. The marge with your (part >> 4) changes later will be pain but we will manage. >> >> Thanks, >> Vladimir >> >> >> On 6/21/13 1:55 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> I removed the breakpoint_Relocation, see >>> http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ >>> It builds and runs on sparc_64 and linuxx86_64. >>> >>> section_word_Relocation can not be removed simply. >>> Internal_word relocations are changed to section_word >>> by pack_data_to. I counted the relocations where they >>> are generated, so I did not catch this. So I didn't remove >>> them. >>> >>> I guess we should make an extra change for this, maybe even >>> push it to the hotspot-comp repository? It's got nothing to >>> do with the port. >>> >>> Bertrand, can I push 8016696: PPC64 (part 4), now as the problem >>> with the enum is solved? >>> It will not conflict with 0003, as they touch different files. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Freitag, 21. Juni 2013 00:12 >>> To: Lindenmaier, Goetz >>> Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll >>> (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; >>> 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>> trampoline stubs >>> >>> Hmm 'breakpoint_type'? I don't remember that and I only see one use >>> place in MacroAssembler::safepoint() on sparc and that method is not >>> used anymore. >>> I build SPARC VM without breakpoint_Relocation class (commented out). >>> Looks like we can remove this type. >>> >>> thanks, >>> Vladimir >>> >>> On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> here the table from my last mail once more, with better formatting. >>>> It shows what relocations are used in a simple jvm98 run. >>>> >>>> | x86_32 | x86_64 | ppc_64 >>>> -------------------------------------------------- >>>> oop | 44566 | 37129 | 24090 >>>> virtual_call | 10422 | 9265 | 9727 >>>> opt_virtual_call | 9083 | 8085 | 8344 >>>> static_call | 435 | 404 | 423 >>>> static_stub | 9518 | 8489 | 8767 >>>> runtime_call | 61762 | 57695 | 27899 >>>> external_word | 6919 | 9622 | 0 >>>> internal_word | 3747 | 5898 | 40903 >>>> poll | 2807 | 2476 | 2705 >>>> poll_return | 2219 | 1989 | 2188 >>>> breakpoint | 0 | 0 | 0 >>>> section_word | 0 | 0 | 0 >>>> trampoline_stub | 0 | 0 | 30428 >>>> >>>> current fillers | 2 | 34 | 3 >>>> new filler needed | 9 | 144 | 0 >>>> >>>> Sum | 140176 | 130978 | 144942 >>>> >>>> >>>> I did this with hs24, therefore metadata is missing, but >>>> that should not affect the basic picture. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> From: >>>> ppc-aix-port-dev-bounces at openjdk.java.net >>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose >>>> Sent: Dienstag, 18. Juni 2013 21:40 >>>> To: Bertrand Delsart >>>> Cc: Roland Westrelin; >>>> ppc-aix-port-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>>> trampoline stubs >>>> >>>> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart >>>> > wrote: >>>> >>>> This change is consuming the last unused relocType (yet_unused_type_2) >>>> >>>> Unfortunately, that relocType is also used for other projects both within >>>> the embedded team and the compiler team (you should not which one I am >>>> speaking about Roland :-)) >>>> >>>> This means relocType will no longer fit into 4 bits. I'll let you see >>>> with the compiler team whether this can easily be solved (by increasing the >>>> size or recycling other reloc types) or whether we need to discuss more >>>> before deciding how to use the last available relocType. >>>> >>>> The relocInfo records are stored as an array of unsigned shorts (u2). >>>> This slightly simplifies random access compared with a CompressedStream >>>> representation, but otherwise is less dense and pits tag space directly >>>> against offset space. >>>> >>>> At some point I would like to see them re-engineered using >>>> CompressedStream, which is built on the more robust UNSIGNED5 >>>> representation. That would allow reloc info tokens to be built from 32-bit >>>> values, as long as most of them were small in magnitude. >>> >>> >>>> >>>> For now, as an incremental change, it would be reasonable to make the tag >>>> width (type_width) be variable. The most common tags could be encoded as 4 >>>> bits and the least common 25% in (say) 6, giving a 75% increase in coding >>>> space at small cost. The extra tag bits would break into the value field >>>> (for the less-common tags). There is already a mechanism for dealing with >>>> value field overflow, which could be adapted to be sensitive to the tag >>>> width. >>>> >>>> The variability could be encoded in the tag field itself (Huffman style, >>>> right-to-left): >>>> type_width = 4, >>>> type_width_2 = 6, >>>> type_width_2_mask = 0x0003, >>>> ... >>>> bool type_width() { (_value & type_width_2_mask) == type_width_2_mask >>>> ? type_width_2 : type_width; } >>>> ... >>>> >>>> - John >>>> >>>> P.S. Back in the day, I wrote the flyweight object mechanism by which >>>> reloc info streams are loaded with objects that are both by-value and >>>> virtual-function-bearing. It is somewhat fragile and (I now think) >>>> over-clever. This is another thing I would like to change about the >>>> relocinfo mechanism, if it were rewritten. Since then other parts of the >>>> JVM have used stream-like structs like RelocIterator, but they don't mess >>>> around with vtables in rewritable stack objects, which (IMO) are at the edge >>>> of the C++ language. >>>> >>>> >> From vladimir.kozlov at oracle.com Fri Jun 21 15:41:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Jun 2013 15:41:29 -0700 Subject: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFED5E1@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE97C9@DEWDFEMB12A.global.corp.sap> <51BF3922.2030100@oracle.com> <51C01C1D.6040205@oracle.com> <37A5E32D-3EC2-497C-ABD9-C396BE7A940A@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEC51E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC9E9@DEWDFEMB12A.global.corp.sap> <51C37E42.1070608@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFECC14@DEWDFEMB12A.global.corp.sap> <51C472D9.2050908@oracle.com> <51C481A0.4040801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFED5E1@DEWDFEMB12A.global.corp.sap> Message-ID: <51C4D699.8060109@oracle.com> Hi, On 6/21/13 3:30 PM, Lindenmaier, Goetz wrote: > Hi, > > that all sounds fine to me. I will wait pushing 4 until the > bp_reloc removal change shows up in the staging repo. > But we could go without that change, anyways. > We need a bugid for the bp_reloc removal, please. > I can make a webrev against the current hotspot-comp. I already prepared patch with you as author (now we can do that ;) ) so you don't need to do anything additional. Note that I swapped unused types: yet_unused_type_1 = 13, // Still unused yet_unused_type_2 = 14, // Still unused I sent request for corresponding closed source changes. When it is reviewed I will push these changes into hotspot-comp. We have few days before regular sync from comp to main (and I am gatekeeper this month :) ). Bug is: 8017308: Remove unused breakpoint relocation type > > It's good if you update the repository, because I have to > do some changes to the patches queue, e.g., do the > SuspendResume changes as they come with JEP 167 on aix. > And I assume 8016157 will help the port, at least we had similar > problems with rematerialization in our VM and the port. Good. Thanks, Vladimir > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, June 21, 2013 6:39 PM > To: Volker Simonis > Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Bertrand Delsart; John Rose > Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs > > It should be in jdk8/hotspot in 2 weeks. We will push in comp repo today > or on Monday. It would be best if you can wait. I will file next bugs > for part 6 and part 7 so we can start working on them. > > About my push for 'part 3'. I used it for an experiment :) which was not > successful :( . We have several JPRT connected systems and I tried to > keep files on one system with bigger disk space but to run on an other > JPRT with much less jobs in queue. And it was disaster - job did not > complete after 14 hours (NFS access was terrible). So I am rerunning it > again in local JPRT. That was the reason why it was not pushed yet. > > I also want to do sync from main forest after that, we pushed big > changes there this week. > > Thanks, > Vladimir > > On 6/21/13 8:48 AM, Volker Simonis wrote: >> What do you think how much time it will take to push this change to >> hsx/ and jdk8/hotspot (as far as I see it is already reviewed - >> right?). If you could do it fast, perhaps we can wait until it arrives >> in the staging repository from up-stream (anyway we wanted to sync >> regularly with upstream). >> >> I think omitting this patch will not block the next few changes we >> have and if it will arrive in jdk8/hotspot within 2 or 3 weeks it may >> save us the pain of the merging. >> >> What do you think? >> Volker >> >> >> On Fri, Jun 21, 2013 at 5:35 PM, Vladimir Kozlov >> wrote: >>> Goetz, >>> >>> Thank you for preparing patch. Yes, we better do it separate in our repo >>> because we may need to change closed sources also. The marge with your (part >>> 4) changes later will be pain but we will manage. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 6/21/13 1:55 AM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> I removed the breakpoint_Relocation, see >>>> http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/ >>>> It builds and runs on sparc_64 and linuxx86_64. >>>> >>>> section_word_Relocation can not be removed simply. >>>> Internal_word relocations are changed to section_word >>>> by pack_data_to. I counted the relocations where they >>>> are generated, so I did not catch this. So I didn't remove >>>> them. >>>> >>>> I guess we should make an extra change for this, maybe even >>>> push it to the hotspot-comp repository? It's got nothing to >>>> do with the port. >>>> >>>> Bertrand, can I push 8016696: PPC64 (part 4), now as the problem >>>> with the enum is solved? >>>> It will not conflict with 0003, as they touch different files. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Freitag, 21. Juni 2013 00:12 >>>> To: Lindenmaier, Goetz >>>> Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll >>>> (albert.noll at oracle.com)'; 'ppc-aix-port-dev at openjdk.java.net'; >>>> 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>>> trampoline stubs >>>> >>>> Hmm 'breakpoint_type'? I don't remember that and I only see one use >>>> place in MacroAssembler::safepoint() on sparc and that method is not >>>> used anymore. >>>> I build SPARC VM without breakpoint_Relocation class (commented out). >>>> Looks like we can remove this type. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote: >>>>> >>>>> Hi, >>>>> >>>>> here the table from my last mail once more, with better formatting. >>>>> It shows what relocations are used in a simple jvm98 run. >>>>> >>>>> | x86_32 | x86_64 | ppc_64 >>>>> -------------------------------------------------- >>>>> oop | 44566 | 37129 | 24090 >>>>> virtual_call | 10422 | 9265 | 9727 >>>>> opt_virtual_call | 9083 | 8085 | 8344 >>>>> static_call | 435 | 404 | 423 >>>>> static_stub | 9518 | 8489 | 8767 >>>>> runtime_call | 61762 | 57695 | 27899 >>>>> external_word | 6919 | 9622 | 0 >>>>> internal_word | 3747 | 5898 | 40903 >>>>> poll | 2807 | 2476 | 2705 >>>>> poll_return | 2219 | 1989 | 2188 >>>>> breakpoint | 0 | 0 | 0 >>>>> section_word | 0 | 0 | 0 >>>>> trampoline_stub | 0 | 0 | 30428 >>>>> >>>>> current fillers | 2 | 34 | 3 >>>>> new filler needed | 9 | 144 | 0 >>>>> >>>>> Sum | 140176 | 130978 | 144942 >>>>> >>>>> >>>>> I did this with hs24, therefore metadata is missing, but >>>>> that should not affect the basic picture. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> From: >>>>> ppc-aix-port-dev-bounces at openjdk.java.net >>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose >>>>> Sent: Dienstag, 18. Juni 2013 21:40 >>>>> To: Bertrand Delsart >>>>> Cc: Roland Westrelin; >>>>> ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for >>>>> trampoline stubs >>>>> >>>>> On Jun 18, 2013, at 1:36 AM, Bertrand Delsart >>>>> > wrote: >>>>> >>>>> This change is consuming the last unused relocType (yet_unused_type_2) >>>>> >>>>> Unfortunately, that relocType is also used for other projects both within >>>>> the embedded team and the compiler team (you should not which one I am >>>>> speaking about Roland :-)) >>>>> >>>>> This means relocType will no longer fit into 4 bits. I'll let you see >>>>> with the compiler team whether this can easily be solved (by increasing the >>>>> size or recycling other reloc types) or whether we need to discuss more >>>>> before deciding how to use the last available relocType. >>>>> >>>>> The relocInfo records are stored as an array of unsigned shorts (u2). >>>>> This slightly simplifies random access compared with a CompressedStream >>>>> representation, but otherwise is less dense and pits tag space directly >>>>> against offset space. >>>>> >>>>> At some point I would like to see them re-engineered using >>>>> CompressedStream, which is built on the more robust UNSIGNED5 >>>>> representation. That would allow reloc info tokens to be built from 32-bit >>>>> values, as long as most of them were small in magnitude. >>>> >>>> >>>>> >>>>> For now, as an incremental change, it would be reasonable to make the tag >>>>> width (type_width) be variable. The most common tags could be encoded as 4 >>>>> bits and the least common 25% in (say) 6, giving a 75% increase in coding >>>>> space at small cost. The extra tag bits would break into the value field >>>>> (for the less-common tags). There is already a mechanism for dealing with >>>>> value field overflow, which could be adapted to be sensitive to the tag >>>>> width. >>>>> >>>>> The variability could be encoded in the tag field itself (Huffman style, >>>>> right-to-left): >>>>> type_width = 4, >>>>> type_width_2 = 6, >>>>> type_width_2_mask = 0x0003, >>>>> ... >>>>> bool type_width() { (_value & type_width_2_mask) == type_width_2_mask >>>>> ? type_width_2 : type_width; } >>>>> ... >>>>> >>>>> - John >>>>> >>>>> P.S. Back in the day, I wrote the flyweight object mechanism by which >>>>> reloc info streams are loaded with objects that are both by-value and >>>>> virtual-function-bearing. It is somewhat fragile and (I now think) >>>>> over-clever. This is another thing I would like to change about the >>>>> relocinfo mechanism, if it were rewritten. Since then other parts of the >>>>> JVM have used stream-like structs like RelocIterator, but they don't mess >>>>> around with vtables in rewritable stack objects, which (IMO) are at the edge >>>>> of the C++ language. >>>>> >>>>> >>> From christian.thalinger at oracle.com Fri Jun 21 18:16:06 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 22 Jun 2013 01:16:06 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130622011613.1613348412@hg.openjdk.java.net> Changeset: 7217cb314c66 Author: twisti Date: 2013-06-21 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7217cb314c66 8003268: SharedRuntime::generate_native_wrapper doesn't save all registers across runtime tracing calls for JNI critical native methods Reviewed-by: kvn ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: d229f7a57af7 Author: twisti Date: 2013-06-21 12:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d229f7a57af7 Merge From alejandro.murillo at oracle.com Fri Jun 21 22:45:39 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 22 Jun 2013 05:45:39 +0000 Subject: hg: hsx/hsx24/hotspot: 9 new changesets Message-ID: <20130622054601.21C8C48418@hg.openjdk.java.net> Changeset: 0344da726f70 Author: mullan Date: 2013-06-10 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0344da726f70 8001330: Improve on checking order 8011896: Add check for invalid offset for new AccessControlContext isAuthorized field Reviewed-by: acorn, hawtin ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: ed3ac73a70ab Author: hseigel Date: 2013-06-10 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ed3ac73a70ab 7158805: Better rewriting of nested subroutine calls Reviewed-by: mschoene, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/oops/generateOopMap.cpp Changeset: a5da0a17dfee Author: asaha Date: 2013-06-13 17:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a5da0a17dfee Merge Changeset: 278de9dd7354 Author: asaha Date: 2013-06-18 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/278de9dd7354 Merge ! src/share/vm/memory/allocation.inline.hpp - src/share/vm/memory/klassInfoClosure.hpp Changeset: cf93da767489 Author: asaha Date: 2013-06-18 09:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cf93da767489 Merge ! src/share/vm/memory/allocation.inline.hpp - src/share/vm/memory/klassInfoClosure.hpp Changeset: 24f785f94d2f Author: asaha Date: 2013-06-18 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/24f785f94d2f Merge Changeset: ae4adc1492d1 Author: katleman Date: 2013-06-21 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ae4adc1492d1 Added tag jdk7u40-b30 for changeset 24f785f94d2f ! .hgtags Changeset: 41118cf72ace Author: amurillo Date: 2013-06-21 18:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/41118cf72ace Merge ! src/share/vm/memory/allocation.hpp Changeset: 645b68762a36 Author: amurillo Date: 2013-06-21 18:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/645b68762a36 Added tag hs24-b50 for changeset 41118cf72ace ! .hgtags From alejandro.murillo at oracle.com Sat Jun 22 05:14:02 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 22 Jun 2013 12:14:02 +0000 Subject: hg: hsx/hsx24/hotspot: 8017252: new hotspot build - hs24-b51 Message-ID: <20130622121407.90EB248421@hg.openjdk.java.net> Changeset: 0125094eb636 Author: amurillo Date: 2013-06-21 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0125094eb636 8017252: new hotspot build - hs24-b51 Reviewed-by: jcoomes ! make/hotspot_version From erik.helin at oracle.com Sat Jun 22 07:26:15 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Sat, 22 Jun 2013 14:26:15 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130622142622.340D248422@hg.openjdk.java.net> Changeset: 707635752c58 Author: ehelin Date: 2013-06-22 10:42 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/707635752c58 8016734: Remove extra code due to duplicated push Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 913ce96aaa86 Author: ehelin Date: 2013-06-22 14:16 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/913ce96aaa86 Merge From goetz.lindenmaier at sap.com Mon Jun 24 07:34:06 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 24 Jun 2013 14:34:06 +0000 Subject: 2 issues with hs25-b37 Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> Hi, I detected two issues with hs25-b37. First, hotspot can not be built with a recent VM any more, as with JEP 185 -Djavax.xml.accessExternalDTD=file must be set in trace.make. http://cr.openjdk.java.net/~goetz/webrevs/fix_for_JEP185/ Further, 8010460 breaks bytecodeInterpreter.cpp, as it uses Method::extra_stack_entries_for_indy, where I think Method::extra_stack_entries_for_jsr292 is meant. Also, it should use labs(). http://cr.openjdk.java.net/~goetz/webrevs/fix_after_8010460/ Is there already a fix for these issues? Could you else please open a bugid for this? Best regards, Goetz. From Alan.Bateman at oracle.com Mon Jun 24 07:54:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Jun 2013 15:54:35 +0100 Subject: 2 issues with hs25-b37 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> Message-ID: <51C85DAB.6010008@oracle.com> On 24/06/2013 15:34, Lindenmaier, Goetz wrote: > Hi, > > I detected two issues with hs25-b37. > > First, hotspot can not be built with a recent VM any more, as > > with JEP 185 -Djavax.xml.accessExternalDTD=file must be set > > in trace.make. Have you tried jdk8-b94 or newer? There was a temporary compatibility issue that should have been resolved in b94 (I'm assuming that jvmtiGen doesn't enable feature secure processing). -Alan From volker.simonis at gmail.com Mon Jun 24 08:56:58 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 24 Jun 2013 17:56:58 +0200 Subject: 2 issues with hs25-b37 In-Reply-To: <51C85DAB.6010008@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> <51C85DAB.6010008@oracle.com> Message-ID: On Mon, Jun 24, 2013 at 4:54 PM, Alan Bateman wrote: > On 24/06/2013 15:34, Lindenmaier, Goetz wrote: >> >> Hi, >> >> I detected two issues with hs25-b37. >> >> First, hotspot can not be built with a recent VM any more, as >> >> with JEP 185 -Djavax.xml.accessExternalDTD=file must be set >> >> in trace.make. > > Have you tried jdk8-b94 or newer? There was a temporary compatibility issue > that should have been resolved in b94 (I'm assuming that jvmtiGen doesn't > enable feature secure processing). > Do you mean "8015630 : Remove default restriction settings of jaxp 1.5 properties in JDK8" (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015630)? I think that will indeed fix the problem. It's just the chicken/egg problem when bootstrapping a port. We'll first have to use an older JDK to build a new version which can then be used as bootstrap-JDK again - but I think we can cope with that:) > -Alan From John.Coomes at oracle.com Mon Jun 24 09:51:14 2013 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 24 Jun 2013 09:51:14 -0700 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <20936.30978.332760.107112@oracle.com> Vote: yes -John From harold.seigel at oracle.com Mon Jun 24 10:21:51 2013 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 24 Jun 2013 13:21:51 -0400 Subject: RFR 8016325: JVM hangs verifying system dictionary In-Reply-To: <51C480D3.1050100@oracle.com> References: <51C480D3.1050100@oracle.com> Message-ID: <51C8802F.60807@oracle.com> Hi Coleen, These changes look good. Harold On 6/21/2013 12:35 PM, Coleen Phillimore wrote: > Summary: Minimize redundant verifications of Klasses. > > Also removed is_metadata() because checking that metadata is not in > the Java heap doesn't make sense anymore and could slow down > verification also. Some cases that aren't statically checked by the > compiler now call is_metaspace_object() under assert for verification. > > Tested by nsk.quick.testlist, and failing SQE test. > > open webrev at http://cr.openjdk.java.net/~coleenp/8016325/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8016325 > local bug link https://jbs.oracle.com/bugs/browse/JDK-8016325 > > thanks, > Coleen From serguei.spitsyn at oracle.com Mon Jun 24 10:33:39 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 24 Jun 2013 10:33:39 -0700 Subject: CFV: New hsx Committer: Tao Mao In-Reply-To: <20918.1511.548877.879954@oracle.com> References: <20918.1511.548877.879954@oracle.com> Message-ID: <51C882F3.7010703@oracle.com> Vote: yes Thanks, Serguei On 6/10/13 9:59 AM, John Coomes wrote: > I hereby nominate Tao Mao to hsx Committer. > > Tao is a member of the HotSpot garbage collection team at Oracle and > has contributed 13 changesets to date, which have improved or fixed > bugs in various GC components including ergonomics, G1 and serial gc. > Ten of the changesets can be seen at [1]. > > Votes are due by Mon, June 24, 2013 5:00pm UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [1] http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=tao.mao > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Tao+Mao&iso=20130624T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From christian.thalinger at oracle.com Mon Jun 24 10:48:12 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Jun 2013 10:48:12 -0700 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> Message-ID: <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" wrote: > Hi, > > I implemented the safefetch stubs for x86 and sparc (was quiet simple). > This way I could clean up the #define right away. > > I tested it thouroughly on > x86_64: bsd, nt, linux, solaris > x86_32: nt, linux > by adding it into our internal VM. > Tonight I will get build/test on > sparc_64 solaris > sparc_32 solaris > x86_64 nt, linux > with the openjdk ppc port, but I tested that before submitting in a smaller > extend, too. > > Here the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ I like this change. It removes a lot of duplication. One comment: + static bool is_safefetch_fault(address pc) { + return pc != NULL && + (pc == _safefetch32_fault_pc || + pc == _safefetchN_fault_pc); + } checks for pc != null. Should we remove the check here? + if (pc && StubRoutines::is_safefetch_fault(pc)) { + set_cont_address(uc, address(StubRoutines::continuation_for_safefetch_fault(pc))); return true; } -- Chris > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 18. Juni 2013 22:44 > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" wrote: > >> Ok, I will implement it on x86. >> >> To get a single change, you can give me the sparc patch, >> or you extend the webrev once I updated it with the >> x86 code. > > Sounds good. Let me know when it's there. > > -- Chris > >> If you prefer, you can also push it to some other repository, it >> will end up in the ppc repo in time I guess. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Tuesday, June 18, 2013 6:59 PM >> To: Lindenmaier, Goetz >> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >> >> >> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi, >>> >>> We have it on these platforms: >>> ia64 (nt, linux, hp_ux) >>> parisc (hp_ux) >>> zArch (linux) >>> ppc (aix, linux) >>> >>> I would implement it on x86 & friends, you do it on sparc and wherever >>> else you like it? >> >> That sounds reasonable. Are we pushing this to the ppc repository then? >> >> -- Chris >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Dienstag, 18. Juni 2013 07:13 >>> To: Volker Simonis >>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>> >>> >>> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: >>> >>>> Hi Goetz, >>>> >>>> I think the change is good and if the other reviewers don't decide to >>>> implement it for the current platforms we can push it. >>> >>> I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? >>> >>> -- Chris >>> >>>> >>>> By the way, the makefile changes in ppc64.make will follow in patch 8 for >>>> linux [1] and patch 14 for aix [2]. >>>> The implementation of the stubs will be in patch 9 for linux [3] and patch >>>> 15 for aix [4] (only the signal handling part). >>>> >>>> Regards, >>>> Volker >>>> >>>> [1] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>> [2] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>> [3] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>> [4] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>> >>>> >>>> >>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>> goetz.lindenmaier at sap.com> wrote: >>>> >>>>> Hi,**** >>>>> >>>>> ** ** >>>>> >>>>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>>>> >>>>> have problems with inline assembly, especially with non-gcc**** >>>>> >>>>> compilers. Stub routines allow to implement safefetch without**** >>>>> >>>>> depending on OS or compiler, as it's the case with the current**** >>>>> >>>>> implementation. This also allows to use a single implementation if an**** >>>>> >>>>> architecture is supported on several os platforms.**** >>>>> >>>>> ** ** >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>> >>>>> ** ** >>>>> >>>>> Currently, we guard the code with **** >>>>> >>>>> #ifdef SAFEFETCH_STUBS**** >>>>> >>>>> which is set in ppc64.make.**** >>>>> >>>>> ** ** >>>>> >>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>> >>>>> or a const flag set in os_.hpp that allows the C-compiler to **** >>>>> >>>>> optimize, and writing the code like this:**** >>>>> >>>>> ** ** >>>>> >>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>> >>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>>>> * >>>>> >>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>> >>>>> if (UseSafefetchStub) {**** >>>>> >>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>>>> * >>>>> >>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>> >>>>> } else {**** >>>>> >>>>> pd_SafeFetch32(adr, errValue);**** >>>>> >>>>> }**** >>>>> >>>>> }**** >>>>> >>>>> ** ** >>>>> >>>>> Unfortunately this requires **** >>>>> >>>>> 1) setting the flag on all platforms**** >>>>> >>>>> 2) renaming the safefetch function on all platfoms.**** >>>>> >>>>> ** ** >>>>> >>>>> Actually I would prefer this second solution as it avoids the >>>>> preprocessor, **** >>>>> >>>>> and am happy to edit the sources accordingly if this finds acceptance.**** >>>>> >>>>> ** ** >>>>> >>>>> For the implementation of a safefetch_stub see**** >>>>> >>>>> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> Could I get a review on this change, please?**** >>>>> >>>>> ** ** >>>>> >>>>> Thanks,**** >>>>> >>>>> Goetz.**** >>>>> >>> >> > From jon.masamitsu at oracle.com Mon Jun 24 10:46:08 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 24 Jun 2013 10:46:08 -0700 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C32D25.8050408@oracle.com> References: <51C32D25.8050408@oracle.com> Message-ID: <51C885E0.3000801@oracle.com> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html > 2673 size_t specialized_count = 0, small_count = 0, medium_count = 0, large_count = 0; > 2675 size_t cls_specialized_count = 0, cls_small_count = 0, cls_medium_count = 0, cls_large_count = 0; Not introduced by your change but humongous_count instead of large_count and cls_humongous_count instead of cls_large_count would be more consistent. http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html I'd suggest adding Metaspace::AppClassMetaspaceType > 385 } else if (SystemDictionary::is_app_class_loader(class_loader())) { > 386 if (TraceClassLoaderData && Verbose && class_loader() != NULL) { > 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class loader"); > 388 } > 389 set_metaspace(new Metaspace(_metaspace_lock, Metaspace::BootMetaspaceType)); and adding a flag InitialAppClassLoaderMetaspaceSize. It's not obvious to me that we should always be reserving the same amount of space for the AppClassLoader as the BootClassLoader. The same default is OK with me. Rest looks good. Jon On 6/20/13 9:26 AM, Coleen Phillimore wrote: > Summary: Allocate medium chunks for class metaspace when class loader > has lots of classes > > I originally made class metaspace keep small chunks and not start > allocating from medium chunks, because I thought with only Klass > objects, small chunks is enough. This test has a large set of class > loaders who have a lot of classes, so allocated thousands of small > chunks each. Class loaders with that many classes should start > allocating from medium chunks, for class metaspace. > > I also increased the ClassMediumChunk size to 4k and measured a lot > less fragmentation waste than 1K or 2K for this test. Lastly, the > AppClassLoader instance should have as large of an initial metaspace > as the bootclass loader. > > Tested with vm.quick.testlist and the failing test. > > open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 > local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 > > Thanks, > Coleen > From Alan.Bateman at oracle.com Mon Jun 24 11:13:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Jun 2013 19:13:18 +0100 Subject: 2 issues with hs25-b37 In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> <51C85DAB.6010008@oracle.com> Message-ID: <51C88C3E.3000807@oracle.com> On 24/06/2013 16:56, Volker Simonis wrote: > : > Do you mean "8015630 : Remove default restriction settings of jaxp 1.5 > properties in JDK8" > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015630)? > > I think that will indeed fix the problem. It's just the chicken/egg > problem when bootstrapping a port. We'll first have to use an older > JDK to build a new version which can then be used as bootstrap-JDK > again - but I think we can cope with that:) > Yes, 8015630 sorted out the compatibility issue in JAXP and the only remaining (and deliberate) difference to long standing behavior will be when feature secure processing is enabled (which you have to opt-in). I'm not sure that I understand the chicken & egg situation that you are running into. Normally the boot JDK for jdk8 is a jdk7 build. It sounds like you might be using a jdk8 build as the boot JDK but that is only guaranteed to work if the matches exactly the jdk8 that you are building. When you do a bootcycle-images build then it will of course be guarantee to match because the newly built JDK will be used to build it (so they will match). -Alan. From goetz.lindenmaier at sap.com Mon Jun 24 11:20:12 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 24 Jun 2013 18:20:12 +0000 Subject: 2 issues with hs25-b37 In-Reply-To: <51C88C3E.3000807@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> <51C85DAB.6010008@oracle.com> <51C88C3E.3000807@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEDB54@DEWDFEMB12A.global.corp.sap> Hi Alan, you were right, with a later jdk it works again. Yes, we are using a jdk8 as boot jdk. But there won't be a problem, I checked in the fix I proposed to the jdk8 repo (not the staging, naturally). Thanks for the help, Goetz. -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Monday, June 24, 2013 8:13 PM To: Volker Simonis Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: 2 issues with hs25-b37 On 24/06/2013 16:56, Volker Simonis wrote: > : > Do you mean "8015630 : Remove default restriction settings of jaxp 1.5 > properties in JDK8" > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015630)? > > I think that will indeed fix the problem. It's just the chicken/egg > problem when bootstrapping a port. We'll first have to use an older > JDK to build a new version which can then be used as bootstrap-JDK > again - but I think we can cope with that:) > Yes, 8015630 sorted out the compatibility issue in JAXP and the only remaining (and deliberate) difference to long standing behavior will be when feature secure processing is enabled (which you have to opt-in). I'm not sure that I understand the chicken & egg situation that you are running into. Normally the boot JDK for jdk8 is a jdk7 build. It sounds like you might be using a jdk8 build as the boot JDK but that is only guaranteed to work if the matches exactly the jdk8 that you are building. When you do a bootcycle-images build then it will of course be guarantee to match because the newly built JDK will be used to build it (so they will match). -Alan. From jon.masamitsu at oracle.com Mon Jun 24 11:21:23 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 24 Jun 2013 11:21:23 -0700 Subject: RFR 8016325: JVM hangs verifying system dictionary In-Reply-To: <51C480D3.1050100@oracle.com> References: <51C480D3.1050100@oracle.com> Message-ID: <51C88E23.3070105@oracle.com> Coleen, http://cr.openjdk.java.net/~coleenp/8016325/src/share/vm/oops/klass.cpp.frames.html 650 void Klass::verify_on(outputStream* st, bool in_dictionary) { "in_dictionary" is not used, right? http://cr.openjdk.java.net/~coleenp/8016325/src/share/vm/oops/klass.hpp.frames.html So do you need this change to add the parameter "check_dictionary"? > 706 virtual void verify_on(outputStream* st, bool check_dictionary = true); > 707 void verify(bool check_dictionary = true) { verify_on(tty, check_dictionary); } > 708 If you do, is the "virtual" on 706 needed? And are the number of lines you would have to change if "check_dictionary" does not have a default (not a fan of defaults), so large? What's the rule about when to use is_metaspace_object() to do an assertion check? Rest looks good. Jon On 6/21/13 9:35 AM, Coleen Phillimore wrote: > Summary: Minimize redundant verifications of Klasses. > > Also removed is_metadata() because checking that metadata is not in > the Java heap doesn't make sense anymore and could slow down > verification also. Some cases that aren't statically checked by the > compiler now call is_metaspace_object() under assert for verification. > > Tested by nsk.quick.testlist, and failing SQE test. > > open webrev at http://cr.openjdk.java.net/~coleenp/8016325/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8016325 > local bug link https://jbs.oracle.com/bugs/browse/JDK-8016325 > > thanks, > Coleen From coleen.phillimore at oracle.com Mon Jun 24 11:23:28 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Jun 2013 14:23:28 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C885E0.3000801@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> Message-ID: <51C88EA0.9090208@oracle.com> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: > http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html > >> 2673 size_t specialized_count = 0, small_count = 0, medium_count = 0, large_count = 0; >> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, cls_medium_count = 0, cls_large_count = 0; > > Not introduced by your change but > > humongous_count instead of large_count > and > cls_humongous_count instead of cls_large_count > > would be more consistent. Yes, it is. I changed it. > > http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html > > I'd suggest adding Metaspace::AppClassMetaspaceType >> 385 } else if (SystemDictionary::is_app_class_loader(class_loader())) { >> 386 if (TraceClassLoaderData && Verbose && class_loader() != NULL) { >> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class loader"); >> 388 } >> 389 set_metaspace(new Metaspace(_metaspace_lock, Metaspace::BootMetaspaceType)); > and adding a flag InitialAppClassLoaderMetaspaceSize. It's not > obvious to me > that we should always be reserving the same amount of space for the > AppClassLoader > as the BootClassLoader. The same default is OK with me. Hmm. Ok. I don't like adding new flags, so can I add an AppMetaspaceType and give it the same initial size as BootMetaspaceSize until proven that it doesn't need to be the same size. I suppose adding an AppMetaspaceInitialSize flag will give me more to talk about at the Permgen Elimination JavaOne talk though (but I'd still rather not). Coleen > > Rest looks good. > > Jon > > > On 6/20/13 9:26 AM, Coleen Phillimore wrote: >> Summary: Allocate medium chunks for class metaspace when class loader >> has lots of classes >> >> I originally made class metaspace keep small chunks and not start >> allocating from medium chunks, because I thought with only Klass >> objects, small chunks is enough. This test has a large set of class >> loaders who have a lot of classes, so allocated thousands of small >> chunks each. Class loaders with that many classes should start >> allocating from medium chunks, for class metaspace. >> >> I also increased the ClassMediumChunk size to 4k and measured a lot >> less fragmentation waste than 1K or 2K for this test. Lastly, the >> AppClassLoader instance should have as large of an initial metaspace >> as the bootclass loader. >> >> Tested with vm.quick.testlist and the failing test. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >> >> Thanks, >> Coleen >> > From jon.masamitsu at oracle.com Mon Jun 24 11:43:51 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 24 Jun 2013 11:43:51 -0700 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C88EA0.9090208@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> Message-ID: <51C89367.3080708@oracle.com> On 6/24/13 11:23 AM, Coleen Phillimore wrote: > > On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >> >>> 2673 size_t specialized_count = 0, small_count = 0, medium_count = 0, large_count = 0; >>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, cls_medium_count = 0, cls_large_count = 0; >> >> Not introduced by your change but >> >> humongous_count instead of large_count >> and >> cls_humongous_count instead of cls_large_count >> >> would be more consistent. > > Yes, it is. I changed it. > >> >> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >> >> I'd suggest adding Metaspace::AppClassMetaspaceType >>> 385 } else if (SystemDictionary::is_app_class_loader(class_loader())) { >>> 386 if (TraceClassLoaderData && Verbose && class_loader() != NULL) { >>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class loader"); >>> 388 } >>> 389 set_metaspace(new Metaspace(_metaspace_lock, Metaspace::BootMetaspaceType)); >> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >> obvious to me >> that we should always be reserving the same amount of space for the >> AppClassLoader >> as the BootClassLoader. The same default is OK with me. > > Hmm. Ok. I don't like adding new flags, so can I add an > AppMetaspaceType and give it the same initial size as > BootMetaspaceSize until proven that it doesn't need to be the same size. With the BootClassLoader the space for the initial Metaspace is committed when the first system class is loaded. The same would be true for any Java application (all have some type of AppLoader, right)? We know we're going to use the space committed for the BootClassLoader Metaspace. Are we going to get yelled at for committing 4m and not using it. > > I suppose adding an AppMetaspaceInitialSize flag will give me more to > talk about at the Permgen Elimination JavaOne talk though (but I'd > still rather not). When you have 100000000000000000 flags, who's going to notice the 100000000000000001-st :-) Jon > > Coleen > >> >> Rest looks good. >> >> Jon >> >> >> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>> Summary: Allocate medium chunks for class metaspace when class >>> loader has lots of classes >>> >>> I originally made class metaspace keep small chunks and not start >>> allocating from medium chunks, because I thought with only Klass >>> objects, small chunks is enough. This test has a large set of class >>> loaders who have a lot of classes, so allocated thousands of small >>> chunks each. Class loaders with that many classes should start >>> allocating from medium chunks, for class metaspace. >>> >>> I also increased the ClassMediumChunk size to 4k and measured a lot >>> less fragmentation waste than 1K or 2K for this test. Lastly, the >>> AppClassLoader instance should have as large of an initial metaspace >>> as the bootclass loader. >>> >>> Tested with vm.quick.testlist and the failing test. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>> >>> Thanks, >>> Coleen >>> >> > From John.Coomes at oracle.com Mon Jun 24 12:08:53 2013 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 24 Jun 2013 12:08:53 -0700 Subject: Result: New hsx Committer: Tao Mao References: <20918.1511.548877.879954@oracle.com> Message-ID: <20936.39237.235202.191252@oracle.com> Voting for Tao Mao [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. John Coomes [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-June/009829.html From goetz.lindenmaier at sap.com Mon Jun 24 12:31:59 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 24 Jun 2013 19:31:59 +0000 Subject: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch In-Reply-To: <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFE9848@DEWDFEMB12A.global.corp.sap> <7D0A3D84-A235-4400-8406-95D5EE765E55@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFE9ADF@DEWDFEMB12A.global.corp.sap> <8AA57E4C-80A8-4D10-AE68-64FCB113CC33@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEADA2@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFEC4BA@DEWDFEMB12A.global.corp.sap> <6D628389-7082-450E-AF0E-1EC3249058F7@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEDBDE@DEWDFEMB12A.global.corp.sap> Hi, you are right, the check is redundant. I removed it and updated the webrev and also based it on the recent staging repo: http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, June 24, 2013 7:48 PM To: Lindenmaier, Goetz Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch On Jun 20, 2013, at 7:01 AM, "Lindenmaier, Goetz" wrote: > Hi, > > I implemented the safefetch stubs for x86 and sparc (was quiet simple). > This way I could clean up the #define right away. > > I tested it thouroughly on > x86_64: bsd, nt, linux, solaris > x86_32: nt, linux > by adding it into our internal VM. > Tonight I will get build/test on > sparc_64 solaris > sparc_32 solaris > x86_64 nt, linux > with the openjdk ppc port, but I tested that before submitting in a smaller > extend, too. > > Here the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8016697-all/ I like this change. It removes a lot of duplication. One comment: + static bool is_safefetch_fault(address pc) { + return pc != NULL && + (pc == _safefetch32_fault_pc || + pc == _safefetchN_fault_pc); + } checks for pc != null. Should we remove the check here? + if (pc && StubRoutines::is_safefetch_fault(pc)) { + set_cont_address(uc, address(StubRoutines::continuation_for_safefetch_fault(pc))); return true; } -- Chris > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 18. Juni 2013 22:44 > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch > > > On Jun 18, 2013, at 1:18 PM, "Lindenmaier, Goetz" wrote: > >> Ok, I will implement it on x86. >> >> To get a single change, you can give me the sparc patch, >> or you extend the webrev once I updated it with the >> x86 code. > > Sounds good. Let me know when it's there. > > -- Chris > >> If you prefer, you can also push it to some other repository, it >> will end up in the ppc repo in time I guess. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Tuesday, June 18, 2013 6:59 PM >> To: Lindenmaier, Goetz >> Cc: Volker Simonis; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >> >> >> On Jun 18, 2013, at 1:50 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi, >>> >>> We have it on these platforms: >>> ia64 (nt, linux, hp_ux) >>> parisc (hp_ux) >>> zArch (linux) >>> ppc (aix, linux) >>> >>> I would implement it on x86 & friends, you do it on sparc and wherever >>> else you like it? >> >> That sounds reasonable. Are we pushing this to the ppc repository then? >> >> -- Chris >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Dienstag, 18. Juni 2013 07:13 >>> To: Volker Simonis >>> Cc: Lindenmaier, Goetz; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8016697: PPC64 (part 5): Use stubs to implement safefetch >>> >>> >>> On Jun 17, 2013, at 10:08 AM, Volker Simonis wrote: >>> >>>> Hi Goetz, >>>> >>>> I think the change is good and if the other reviewers don't decide to >>>> implement it for the current platforms we can push it. >>> >>> I talked with Vladimir about this today and I my opinion we should use this stub on all platforms. On which other platforms are you guys having this? >>> >>> -- Chris >>> >>>> >>>> By the way, the makefile changes in ppc64.make will follow in patch 8 for >>>> linux [1] and patch 14 for aix [2]. >>>> The implementation of the stubs will be in patch 9 for linux [3] and patch >>>> 15 for aix [4] (only the signal handling part). >>>> >>>> Regards, >>>> Volker >>>> >>>> [1] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0008_linux_ppc_make_changes.patch >>>> [2] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0014_aix_make_changes.patch >>>> [3] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0009_linux_ppc_files.patch >>>> [4] >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/tip/ppc_patches/0015_aix_ppc_files.patch >>>> >>>> >>>> >>>> On Mon, Jun 17, 2013 at 3:55 PM, Lindenmaier, Goetz < >>>> goetz.lindenmaier at sap.com> wrote: >>>> >>>>> Hi,**** >>>>> >>>>> ** ** >>>>> >>>>> the PPC64 port uses stub routines to implement safefetch. We had and**** >>>>> >>>>> have problems with inline assembly, especially with non-gcc**** >>>>> >>>>> compilers. Stub routines allow to implement safefetch without**** >>>>> >>>>> depending on OS or compiler, as it's the case with the current**** >>>>> >>>>> implementation. This also allows to use a single implementation if an**** >>>>> >>>>> architecture is supported on several os platforms.**** >>>>> >>>>> ** ** >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8016697-safefetch/**** >>>>> >>>>> ** ** >>>>> >>>>> Currently, we guard the code with **** >>>>> >>>>> #ifdef SAFEFETCH_STUBS**** >>>>> >>>>> which is set in ppc64.make.**** >>>>> >>>>> ** ** >>>>> >>>>> I could also imagine an implementation that uses a pd_debug flag**** >>>>> >>>>> or a const flag set in os_.hpp that allows the C-compiler to **** >>>>> >>>>> optimize, and writing the code like this:**** >>>>> >>>>> ** ** >>>>> >>>>> extern "C" int pd_SafeFetch32 (int * adr, int errValue) ;**** >>>>> >>>>> extern "C" intptr_t pd_SafeFetchN (intptr_t * adr, intptr_t errValue) ;*** >>>>> * >>>>> >>>>> inline int SafeFetch32(int* adr, int errValue) {**** >>>>> >>>>> if (UseSafefetchStub) {**** >>>>> >>>>> assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");*** >>>>> * >>>>> >>>>> return StubRoutines::SafeFetch32_stub()(adr, errValue);**** >>>>> >>>>> } else {**** >>>>> >>>>> pd_SafeFetch32(adr, errValue);**** >>>>> >>>>> }**** >>>>> >>>>> }**** >>>>> >>>>> ** ** >>>>> >>>>> Unfortunately this requires **** >>>>> >>>>> 1) setting the flag on all platforms**** >>>>> >>>>> 2) renaming the safefetch function on all platfoms.**** >>>>> >>>>> ** ** >>>>> >>>>> Actually I would prefer this second solution as it avoids the >>>>> preprocessor, **** >>>>> >>>>> and am happy to edit the sources accordingly if this finds acceptance.**** >>>>> >>>>> ** ** >>>>> >>>>> For the implementation of a safefetch_stub see**** >>>>> >>>>> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/fce884e5ba0b/src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> Could I get a review on this change, please?**** >>>>> >>>>> ** ** >>>>> >>>>> Thanks,**** >>>>> >>>>> Goetz.**** >>>>> >>> >> > From coleen.phillimore at oracle.com Mon Jun 24 14:03:36 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Jun 2013 17:03:36 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C89367.3080708@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> <51C89367.3080708@oracle.com> Message-ID: <51C8B428.3090507@oracle.com> On 06/24/2013 02:43 PM, Jon Masamitsu wrote: > > On 6/24/13 11:23 AM, Coleen Phillimore wrote: >> >> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >>> >>>> 2673 size_t specialized_count = 0, small_count = 0, medium_count = 0, large_count = 0; >>>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, cls_medium_count = 0, cls_large_count = 0; >>> >>> Not introduced by your change but >>> >>> humongous_count instead of large_count >>> and >>> cls_humongous_count instead of cls_large_count >>> >>> would be more consistent. >> >> Yes, it is. I changed it. >> >>> >>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >>> >>> I'd suggest adding Metaspace::AppClassMetaspaceType >>>> 385 } else if (SystemDictionary::is_app_class_loader(class_loader())) { >>>> 386 if (TraceClassLoaderData && Verbose && class_loader() != NULL) { >>>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class loader"); >>>> 388 } >>>> 389 set_metaspace(new Metaspace(_metaspace_lock, Metaspace::BootMetaspaceType)); >>> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >>> obvious to me >>> that we should always be reserving the same amount of space for the >>> AppClassLoader >>> as the BootClassLoader. The same default is OK with me. >> >> Hmm. Ok. I don't like adding new flags, so can I add an >> AppMetaspaceType and give it the same initial size as >> BootMetaspaceSize until proven that it doesn't need to be the same size. > > With the BootClassLoader the space for the initial Metaspace is committed > when the first system class is loaded. The same would be true for any > Java application (all have some type of AppLoader, right)? We know we're > going to use the space committed for the BootClassLoader Metaspace. Are > we going to get yelled at for committing 4m and not using it. >> >> I suppose adding an AppMetaspaceInitialSize flag will give me more to >> talk about at the Permgen Elimination JavaOne talk though (but I'd >> still rather not). > > When you have 100000000000000000 flags, who's going to > notice the 100000000000000001-st :-) Okay, you convinced me to revert this part of the change. It wasn't necessary to make this stress test finish and there hasn't been very much tuning for "normal" application classes, just a suspicion of mine. Committing an extra 4m might be bad for embedded platforms. Thanks, Coleen > > Jon >> >> Coleen >> >>> >>> Rest looks good. >>> >>> Jon >>> >>> >>> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>>> Summary: Allocate medium chunks for class metaspace when class >>>> loader has lots of classes >>>> >>>> I originally made class metaspace keep small chunks and not start >>>> allocating from medium chunks, because I thought with only Klass >>>> objects, small chunks is enough. This test has a large set of >>>> class loaders who have a lot of classes, so allocated thousands of >>>> small chunks each. Class loaders with that many classes should >>>> start allocating from medium chunks, for class metaspace. >>>> >>>> I also increased the ClassMediumChunk size to 4k and measured a lot >>>> less fragmentation waste than 1K or 2K for this test. Lastly, the >>>> AppClassLoader instance should have as large of an initial >>>> metaspace as the bootclass loader. >>>> >>>> Tested with vm.quick.testlist and the failing test. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>>> >>>> Thanks, >>>> Coleen >>>> >>> >> > From coleen.phillimore at oracle.com Mon Jun 24 14:20:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Jun 2013 17:20:15 -0400 Subject: RFR 8016325: JVM hangs verifying system dictionary In-Reply-To: <51C88E23.3070105@oracle.com> References: <51C480D3.1050100@oracle.com> <51C88E23.3070105@oracle.com> Message-ID: <51C8B80F.9080807@oracle.com> Thanks Jon for looking at this. On 06/24/2013 02:21 PM, Jon Masamitsu wrote: > Coleen, > > http://cr.openjdk.java.net/~coleenp/8016325/src/share/vm/oops/klass.cpp.frames.html > > > 650 void Klass::verify_on(outputStream* st, bool in_dictionary) { > > > "in_dictionary" is not used, right? It isn't used but I forgot to change the name of the parameter to check_dictionary which has the opposite sense. > > http://cr.openjdk.java.net/~coleenp/8016325/src/share/vm/oops/klass.hpp.frames.html > > > So do you need this change to add the parameter "check_dictionary"? >> 706 virtual void verify_on(outputStream* st, bool >> check_dictionary = true); >> 707 void verify(bool check_dictionary = true) { verify_on(tty, >> check_dictionary); } >> 708 > If you do, is the "virtual" on 706 needed? And are the number of > lines you would > have to change if "check_dictionary" does not have a default (not a > fan of defaults), > so large? Yes, it's needed because then InstanceKlass::verify_on will override this versions. It won't if the parameters don't match. We definitely want verify_on() to be virtual. I'm afraid the number of lines would be pretty large if there wasn't a default parameter. > > What's the rule about when to use is_metaspace_object() to > do an assertion check? The rule I applied was to use this test if the metadata object was coming from some location where non-metadata could also be stored by mistake (like the frame_x86.hpp example). In the verification code the compiler's static type checking code can do the job for us so that's why I removed them. Thanks, Coleen > > Rest looks good. > > Jon > > > On 6/21/13 9:35 AM, Coleen Phillimore wrote: >> Summary: Minimize redundant verifications of Klasses. >> >> Also removed is_metadata() because checking that metadata is not in >> the Java heap doesn't make sense anymore and could slow down >> verification also. Some cases that aren't statically checked by the >> compiler now call is_metaspace_object() under assert for verification. >> >> Tested by nsk.quick.testlist, and failing SQE test. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8016325/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8016325 >> local bug link https://jbs.oracle.com/bugs/browse/JDK-8016325 >> >> thanks, >> Coleen > From vladimir.kozlov at oracle.com Mon Jun 24 14:20:40 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 24 Jun 2013 21:20:40 +0000 Subject: hg: hsx/hsx24/hotspot: 8016157: During CTW: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Message-ID: <20130624212048.5631E48463@hg.openjdk.java.net> Changeset: c0643ff8feb5 Author: adlertz Date: 2013-06-14 01:19 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c0643ff8feb5 8016157: During CTW: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Summary: Disable rematerialization for negD node Reviewed-by: kvn, roland ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp From vladimir.kozlov at oracle.com Mon Jun 24 15:31:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 24 Jun 2013 15:31:03 -0700 Subject: 2 issues with hs25-b37 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEDA67@DEWDFEMB12A.global.corp.sap> Message-ID: <51C8C8A7.4090606@oracle.com> Hi, Goetz I created 8017531: 8010460 changes broke bytecodeInterpreter.cpp Thanks for reporting. Vladimir On 6/24/13 7:34 AM, Lindenmaier, Goetz wrote: > Hi, > > I detected two issues with hs25-b37. > > First, hotspot can not be built with a recent VM any more, as > > with JEP 185 -Djavax.xml.accessExternalDTD=file must be set > > in trace.make. > http://cr.openjdk.java.net/~goetz/webrevs/fix_for_JEP185/ > > Further, 8010460 breaks bytecodeInterpreter.cpp, as it uses > > Method::extra_stack_entries_for_indy, where I think > > Method::extra_stack_entries_for_jsr292 is meant. > > Also, it should use labs(). > > http://cr.openjdk.java.net/~goetz/webrevs/fix_after_8010460/ > > > > Is there already a fix for these issues? Could you else please > > open a bugid for this? > > > > Best regards, > > Goetz. > > > > > > > > > From jon.masamitsu at oracle.com Mon Jun 24 16:07:19 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 24 Jun 2013 16:07:19 -0700 Subject: RFR 8016325: JVM hangs verifying system dictionary In-Reply-To: <51C8B80F.9080807@oracle.com> References: <51C480D3.1050100@oracle.com> <51C88E23.3070105@oracle.com> <51C8B80F.9080807@oracle.com> Message-ID: <51C8D127.8060002@oracle.com> On 6/24/13 2:20 PM, Coleen Phillimore wrote: > > Thanks Jon for looking at this. > > On 06/24/2013 02:21 PM, Jon Masamitsu wrote: >> Coleen, >> >> http://cr.openjdk.java.net/~coleenp/8016325/src/share/vm/oops/klass.cpp.frames.html >> >> >> 650 void Klass::verify_on(outputStream* st, bool in_dictionary) { >> >> >> "in_dictionary" is not used, right? > > It isn't used but I forgot to change the name of the parameter to > check_dictionary which has the opposite sense. I'm confused by that statement. >> >> http://cr.openjdk.java.net/~coleenp/8016325/src/share/vm/oops/klass.hpp.frames.html >> >> >> So do you need this change to add the parameter "check_dictionary"? >>> 706 virtual void verify_on(outputStream* st, bool >>> check_dictionary = true); >>> 707 void verify(bool check_dictionary = true) { verify_on(tty, >>> check_dictionary); } >>> 708 >> If you do, is the "virtual" on 706 needed? And are the number of >> lines you would >> have to change if "check_dictionary" does not have a default (not a >> fan of defaults), >> so large? > > Yes, it's needed because then InstanceKlass::verify_on will override > this versions. It won't if the parameters don't match. We definitely > want verify_on() to be virtual. Ok. > > I'm afraid the number of lines would be pretty large if there wasn't a > default parameter. > The clean coding book would not be happy. Your call, but are you sure you don't want to tidy it up now? >> >> What's the rule about when to use is_metaspace_object() to >> do an assertion check? > > The rule I applied was to use this test if the metadata object was > coming from some location where non-metadata could also be stored by > mistake (like the frame_x86.hpp example). In the verification code > the compiler's static type checking code can do the job for us so > that's why I removed them. Thanks. Jon > > Thanks, > Coleen > >> >> Rest looks good. >> >> Jon >> >> >> On 6/21/13 9:35 AM, Coleen Phillimore wrote: >>> Summary: Minimize redundant verifications of Klasses. >>> >>> Also removed is_metadata() because checking that metadata is not in >>> the Java heap doesn't make sense anymore and could slow down >>> verification also. Some cases that aren't statically checked by >>> the compiler now call is_metaspace_object() under assert for >>> verification. >>> >>> Tested by nsk.quick.testlist, and failing SQE test. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8016325/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8016325 >>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8016325 >>> >>> thanks, >>> Coleen >> > From christian.thalinger at oracle.com Mon Jun 24 16:16:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Jun 2013 16:16:59 -0700 Subject: RFR (XXS): 8017538: Clang support broke slowdebug build for i586 Message-ID: 8017538: Clang support broke slowdebug build for i586 Reviewed-by: Bill Pittore found this problem. diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make --- a/make/linux/makefiles/gcc.make +++ b/make/linux/makefiles/gcc.make @@ -350,9 +350,9 @@ ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) ifeq ($(USE_CLANG), true) # Clang doesn't understand -gstabs - OPT_CFLAGS += -g + DEBUG_CFLAGS += -g else - OPT_CFLAGS += -gstabs + DEBUG_CFLAGS += -gstabs endif endif @@ -365,9 +365,9 @@ ifeq ($(FASTDEBUG_CFLAGS/$(BUILDARCH)),) ifeq ($(USE_CLANG), true) # Clang doesn't understand -gstabs - OPT_CFLAGS += -g + FASTDEBUG_CFLAGS += -g else - OPT_CFLAGS += -gstabs + FASTDEBUG_CFLAGS += -gstabs endif endif From vladimir.kozlov at oracle.com Mon Jun 24 16:36:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 24 Jun 2013 16:36:15 -0700 Subject: RFR (XXS): 8017538: Clang support broke slowdebug build for i586 In-Reply-To: References: Message-ID: <51C8D7EF.9020405@oracle.com> Good. Vladimir On 6/24/13 4:16 PM, Christian Thalinger wrote: > 8017538: Clang support broke slowdebug build for i586 > Reviewed-by: > > Bill Pittore found this problem. > > diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make > +++ b/make/linux/makefiles/gcc.make > @@ -350,9 +350,9 @@ > ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) > ifeq ($(USE_CLANG), true) > # Clang doesn't understand -gstabs > - OPT_CFLAGS += -g > + DEBUG_CFLAGS += -g > else > - OPT_CFLAGS += -gstabs > + DEBUG_CFLAGS += -gstabs > endif > endif > > @@ -365,9 +365,9 @@ > ifeq ($(FASTDEBUG_CFLAGS/$(BUILDARCH)),) > ifeq ($(USE_CLANG), true) > # Clang doesn't understand -gstabs > - OPT_CFLAGS += -g > + FASTDEBUG_CFLAGS += -g > else > - OPT_CFLAGS += -gstabs > + FASTDEBUG_CFLAGS += -gstabs > endif > endif > > From john.cuthbertson at oracle.com Mon Jun 24 17:18:08 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 25 Jun 2013 00:18:08 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130625001818.4DF11484A5@hg.openjdk.java.net> Changeset: 76e9dce17c31 Author: johnc Date: 2013-06-24 10:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/76e9dce17c31 8015237: Parallelize string table scanning during strong root processing Summary: Parallelize the scanning of the intern string table by having each GC worker claim a given number of buckets. Changes were also reviewed by Per Liden . Reviewed-by: tschatzl, stefank, twisti ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: 7c945fe9f388 Author: johnc Date: 2013-06-24 10:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7c945fe9f388 Merge Changeset: b986e7953c87 Author: johnc Date: 2013-06-24 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b986e7953c87 Merge From christian.thalinger at oracle.com Mon Jun 24 17:41:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Jun 2013 17:41:52 -0700 Subject: RFR (XXS): 8017538: Clang support broke slowdebug build for i586 In-Reply-To: <51C8D7EF.9020405@oracle.com> References: <51C8D7EF.9020405@oracle.com> Message-ID: <1A36A797-72E0-4890-B640-D6419ED15ECC@oracle.com> Thank you, Vladimir. -- Chris On Jun 24, 2013, at 4:36 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 6/24/13 4:16 PM, Christian Thalinger wrote: >> 8017538: Clang support broke slowdebug build for i586 >> Reviewed-by: >> >> Bill Pittore found this problem. >> >> diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make >> --- a/make/linux/makefiles/gcc.make >> +++ b/make/linux/makefiles/gcc.make >> @@ -350,9 +350,9 @@ >> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) >> ifeq ($(USE_CLANG), true) >> # Clang doesn't understand -gstabs >> - OPT_CFLAGS += -g >> + DEBUG_CFLAGS += -g >> else >> - OPT_CFLAGS += -gstabs >> + DEBUG_CFLAGS += -gstabs >> endif >> endif >> >> @@ -365,9 +365,9 @@ >> ifeq ($(FASTDEBUG_CFLAGS/$(BUILDARCH)),) >> ifeq ($(USE_CLANG), true) >> # Clang doesn't understand -gstabs >> - OPT_CFLAGS += -g >> + FASTDEBUG_CFLAGS += -g >> else >> - OPT_CFLAGS += -gstabs >> + FASTDEBUG_CFLAGS += -gstabs >> endif >> endif >> >> From staffan.larsen at oracle.com Tue Jun 25 01:26:54 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 25 Jun 2013 10:26:54 +0200 Subject: RFR (XS): 8017561 Build errors caused by missing .PHONY Message-ID: <534EB64B-9FF3-4F90-B947-9EA871599709@oracle.com> The build shows errors (but does not stop) that look like below because of a missing .PHONY rule in make/excludeSrc.make. webrev: http://cr.openjdk.java.net/~sla/8017561/webrev.00/ Thanks, /Staffan cd linux_amd64_compiler2/debug && make -w " LP64=1 " make[3]: Entering directory `/home/stefank/hg/hsx-gc.clean/build/linux/linux_amd64_compiler2/debug' make -f vm.make ./precompiled.hpp.gch -w INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=0 make[4]: Entering directory `/home/stefank/hg/hsx-gc.clean/build/linux/linux_amd64_compiler2/debug' Generating precompiled header precompiled.hpp.gch In file included from /home/stefank/hg/hsx-gc.clean/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp:29:0, from /home/stefank/hg/hsx-gc.clean/src/share/vm/runtime/atomic.inline.hpp:32, from /home/stefank/hg/hsx-gc.clean/src/share/vm/memory/allocation.inline.hpp:28, from /home/stefank/hg/hsx-gc.clean/src/share/vm/utilities/array.hpp:29, from /home/stefank/hg/hsx-gc.clean/src/share/vm/memory/universe.hpp:29, from /home/stefank/hg/hsx-gc.clean/src/share/vm/code/oopRecorder.hpp:28, from /home/stefank/hg/hsx-gc.clean/src/share/vm/asm/codeBuffer.hpp:28, from /home/stefank/hg/hsx-gc.clean/src/share/vm/asm/assembler.hpp:28, from /home/stefank/hg/hsx-gc.clean/src/share/vm/precompiled/precompiled.hpp:29: /home/stefank/hg/hsx-gc.clean/src/share/vm/runtime/os.hpp:28:30: fatal error: jvmtifiles/jvmti.h: No such file or directory compilation terminated. From stefan.karlsson at oracle.com Tue Jun 25 01:47:56 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 25 Jun 2013 10:47:56 +0200 Subject: RFR (XS): 8017561 Build errors caused by missing .PHONY In-Reply-To: <534EB64B-9FF3-4F90-B947-9EA871599709@oracle.com> References: <534EB64B-9FF3-4F90-B947-9EA871599709@oracle.com> Message-ID: <51C9593C.2040706@oracle.com> On 06/25/2013 10:26 AM, Staffan Larsen wrote: > The build shows errors (but does not stop) that look like below because of a missing .PHONY rule in make/excludeSrc.make. > > webrev: http://cr.openjdk.java.net/~sla/8017561/webrev.00/ Looks good. StefanK > > Thanks, > /Staffan > > > cd linux_amd64_compiler2/debug && make -w " LP64=1 " > make[3]: Entering directory `/home/stefank/hg/hsx-gc.clean/build/linux/linux_amd64_compiler2/debug' > make -f vm.make ./precompiled.hpp.gch -w > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=0 > make[4]: Entering directory `/home/stefank/hg/hsx-gc.clean/build/linux/linux_amd64_compiler2/debug' > Generating precompiled header precompiled.hpp.gch > In file included from /home/stefank/hg/hsx-gc.clean/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp:29:0, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/runtime/atomic.inline.hpp:32, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/memory/allocation.inline.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/utilities/array.hpp:29, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/memory/universe.hpp:29, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/code/oopRecorder.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/asm/codeBuffer.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/asm/assembler.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/precompiled/precompiled.hpp:29: > /home/stefank/hg/hsx-gc.clean/src/share/vm/runtime/os.hpp:28:30: fatal error: jvmtifiles/jvmti.h: No such file or directory > compilation terminated. From bengt.rutisson at oracle.com Tue Jun 25 05:10:43 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 25 Jun 2013 14:10:43 +0200 Subject: RFR (XS): 8017561 Build errors caused by missing .PHONY In-Reply-To: <534EB64B-9FF3-4F90-B947-9EA871599709@oracle.com> References: <534EB64B-9FF3-4F90-B947-9EA871599709@oracle.com> Message-ID: <51C988C3.20606@oracle.com> Staffan, Looks good to me. Bengt On 6/25/13 10:26 AM, Staffan Larsen wrote: > The build shows errors (but does not stop) that look like below because of a missing .PHONY rule in make/excludeSrc.make. > > webrev: http://cr.openjdk.java.net/~sla/8017561/webrev.00/ > > Thanks, > /Staffan > > > cd linux_amd64_compiler2/debug && make -w " LP64=1 " > make[3]: Entering directory `/home/stefank/hg/hsx-gc.clean/build/linux/linux_amd64_compiler2/debug' > make -f vm.make ./precompiled.hpp.gch -w > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=0 > make[4]: Entering directory `/home/stefank/hg/hsx-gc.clean/build/linux/linux_amd64_compiler2/debug' > Generating precompiled header precompiled.hpp.gch > In file included from /home/stefank/hg/hsx-gc.clean/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp:29:0, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/runtime/atomic.inline.hpp:32, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/memory/allocation.inline.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/utilities/array.hpp:29, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/memory/universe.hpp:29, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/code/oopRecorder.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/asm/codeBuffer.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/asm/assembler.hpp:28, > from /home/stefank/hg/hsx-gc.clean/src/share/vm/precompiled/precompiled.hpp:29: > /home/stefank/hg/hsx-gc.clean/src/share/vm/runtime/os.hpp:28:30: fatal error: jvmtifiles/jvmti.h: No such file or directory > compilation terminated. From goetz.lindenmaier at sap.com Tue Jun 25 05:44:10 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Jun 2013 12:44:10 +0000 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> Hi, We precompute the stack limit for overflow checks and save this limit in the thread. This simplifies the assembler coding checking the stack overflow. This change contains the necessary shared functionality. It can easily be ported to other platforms, too. http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ Please review this change. Best regards, Goetz. PS: I removed some parts of patch 0006 because I found a better platform-only solution. From david.holmes at oracle.com Tue Jun 25 05:52:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Jun 2013 22:52:31 +1000 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> Message-ID: <51C9928F.6070208@oracle.com> Hi Goetz, This does not sit well with me. Convince me why we should saddle all builds with this only to support the cppInterpreter? Thanks, David On 25/06/2013 10:44 PM, Lindenmaier, Goetz wrote: > Hi, > > We precompute the stack limit for overflow checks and save this > limit in the thread. This simplifies the assembler coding checking > the stack overflow. This change contains the necessary shared > functionality. It can easily be ported to other platforms, too. > http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ > > Please review this change. > > Best regards, > Goetz. > > PS: I removed some parts of patch 0006 because I found a better > platform-only solution. > From coleen.phillimore at oracle.com Tue Jun 25 05:49:22 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Jun 2013 08:49:22 -0400 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> Message-ID: <51C991D2.8050307@oracle.com> Which stack limit is this? Does it subtract off the red and yellow zones? Where do you set it? Yes, it would simplify the assembler code in the interpreter entries to use this. It might be better to rename it though if it's the usable stack (subtracting red and yellow zones) and maybe compute the value inside of Thread class (so you see it always subtracting the red and yellow zones). It's sort of ambiguous that this is happening. How about stack_overflow_limit()? Thanks, Coleen On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: > Hi, > > We precompute the stack limit for overflow checks and save this > limit in the thread. This simplifies the assembler coding checking > the stack overflow. This change contains the necessary shared > functionality. It can easily be ported to other platforms, too. > http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ > > Please review this change. > > Best regards, > Goetz. > > PS: I removed some parts of patch 0006 because I found a better > platform-only solution. From goetz.lindenmaier at sap.com Tue Jun 25 06:27:36 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Jun 2013 13:27:36 +0000 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51C991D2.8050307@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> Hi Colleen, David, I'll rename the methods to stack_overflow_limit and update the webrev, I like that name better too. We set it in os::initialize_thread(): http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp and we use it here (line427): http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp In that files the method is called [set_]memory_stack_limit(). Actually, it's got nothing to do with the cppInterpreter. I first thought so, because we only used it with the cppInterpreter when I moved this from our VM to the port (a while ago now). But look at the code in void InterpreterGenerator::generate_stack_overflow_check(void) on x86 that computes the stack bound in rax ... that's not really simple, and requires two loads (stack_base, stack_size). The difference between cppInterpreter and template interpreter is that we always check against the stack_limit in the cppInterpreter, but the templateInterpreter first checks whether the stack is < 1 page, thus experiencing less overhead from the lengthy coding. Best regards, Goetz -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Dienstag, 25. Juni 2013 14:49 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements Which stack limit is this? Does it subtract off the red and yellow zones? Where do you set it? Yes, it would simplify the assembler code in the interpreter entries to use this. It might be better to rename it though if it's the usable stack (subtracting red and yellow zones) and maybe compute the value inside of Thread class (so you see it always subtracting the red and yellow zones). It's sort of ambiguous that this is happening. How about stack_overflow_limit()? Thanks, Coleen On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: > Hi, > > We precompute the stack limit for overflow checks and save this > limit in the thread. This simplifies the assembler coding checking > the stack overflow. This change contains the necessary shared > functionality. It can easily be ported to other platforms, too. > http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ > > Please review this change. > > Best regards, > Goetz. > > PS: I removed some parts of patch 0006 because I found a better > platform-only solution. From bertrand.delsart at oracle.com Tue Jun 25 06:35:33 2013 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 25 Jun 2013 15:35:33 +0200 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51C9928F.6070208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C9928F.6070208@oracle.com> Message-ID: <51C99CA5.20002@oracle.com> This is used also for the templateInterpreter. We indeed compute the _stack_limit for all interpreter overflow checks (from _stack_base and _stack_size). Not sure this is worth optimizing if it requires an extra field and benefits only the interpreters. On the other hand, stack_base() is probably very rarely used in critical paths. Would it be worth replacing the _stack_base field by a _stack_limit field (recomputing stack_base() from _stack_limit and _stack_size) ? Regards, Bertrand. On 06/25/13 02:52 PM, David Holmes wrote: > Hi Goetz, > > This does not sit well with me. Convince me why we should saddle all > builds with this only to support the cppInterpreter? > > Thanks, > David > > On 25/06/2013 10:44 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> We precompute the stack limit for overflow checks and save this >> limit in the thread. This simplifies the assembler coding checking >> the stack overflow. This change contains the necessary shared >> functionality. It can easily be ported to other platforms, too. >> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ >> >> Please review this change. >> >> Best regards, >> Goetz. >> >> PS: I removed some parts of patch 0006 because I found a better >> platform-only solution. >> -- Bertrand Delsart, bertrand.delsart at oracle.com Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From coleen.phillimore at oracle.com Tue Jun 25 06:34:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Jun 2013 09:34:12 -0400 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> Message-ID: <51C99C54.1010909@oracle.com> Yes, I think this would be useful for the other platforms to simplify the stack overflow limit checking in the interpreter assembly code. 100 // Initialize the memory stack limit. 101 address mem_stk_limit = thread->stack_base() - thread->stack_size() + 102 ((StackShadowPages + StackYellowPages + StackRedPages) * os::vm_page_size()); 103 104 thread->set_memory_stack_limit(mem_stk_limit); My other comment was to move 101-102 into the function set_stack_overflow_limit() since nothing on those lines depends on the platform and the values used to compute this are owned by class Thread anyway. thanks, Coleen On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: > Hi Colleen, David, > > I'll rename the methods to stack_overflow_limit and update the webrev, > I like that name better too. > > We set it in os::initialize_thread(): > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > and we use it here (line427): > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp > In that files the method is called [set_]memory_stack_limit(). > > Actually, it's got nothing to do with the cppInterpreter. I first thought so, > because we only used it with the cppInterpreter when I moved this from > our VM to the port (a while ago now). But look at the code in > void InterpreterGenerator::generate_stack_overflow_check(void) on x86 that > computes the stack bound in rax ... that's not really simple, and requires > two loads (stack_base, stack_size). > > The difference between cppInterpreter and template interpreter is that > we always check against the stack_limit in the cppInterpreter, but the > templateInterpreter first checks whether the stack is < 1 page, thus > experiencing less overhead from the lengthy coding. > > Best regards, > Goetz > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Dienstag, 25. Juni 2013 14:49 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements > > > Which stack limit is this? Does it subtract off the red and yellow > zones? Where do you set it? Yes, it would simplify the assembler code > in the interpreter entries to use this. > > It might be better to rename it though if it's the usable stack > (subtracting red and yellow zones) and maybe compute the value inside of > Thread class (so you see it always subtracting the red and yellow > zones). It's sort of ambiguous that this is happening. How about > stack_overflow_limit()? > > Thanks, > Coleen > > On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> We precompute the stack limit for overflow checks and save this >> limit in the thread. This simplifies the assembler coding checking >> the stack overflow. This change contains the necessary shared >> functionality. It can easily be ported to other platforms, too. >> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ >> >> Please review this change. >> >> Best regards, >> Goetz. >> >> PS: I removed some parts of patch 0006 because I found a better >> platform-only solution. From goetz.lindenmaier at sap.com Tue Jun 25 07:07:25 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Jun 2013 14:07:25 +0000 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51C99C54.1010909@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> Hi, that's something I don't get: x86 does // Use the maximum number of pages we might bang. const int max_pages = StackShadowPages > (StackRedPages+StackYellowPages) ? StackShadowPages : (StackRedPages+StackYellowPages) and sparc __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); in generate_stack_overflow_check(). And we use the sum of all three. This is because we want to use the shadow space for exception handling, so we must overflow before we run into the shadow space. All these different values could be set in the os_cpu file. But maybe they only differ because there is no shared coding yet? And they should be harmonized? Bertrand, recomputing stack_base seems a good idea to me. But this would require that all platforms are adapted before _stack_base is removed. Best regards, Goetz. From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Dienstag, 25. Juni 2013 15:34 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; David Holmes Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements Yes, I think this would be useful for the other platforms to simplify the stack overflow limit checking in the interpreter assembly code. 100 // Initialize the memory stack limit. 101 address mem_stk_limit = thread->stack_base() - thread->stack_size() + 102 ((StackShadowPages + StackYellowPages + StackRedPages) * os::vm_page_size()); 103 104 thread->set_memory_stack_limit(mem_stk_limit); My other comment was to move 101-102 into the function set_stack_overflow_limit() since nothing on those lines depends on the platform and the values used to compute this are owned by class Thread anyway. thanks, Coleen On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: Hi Colleen, David, I'll rename the methods to stack_overflow_limit and update the webrev, I like that name better too. We set it in os::initialize_thread(): http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp and we use it here (line427): http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp In that files the method is called [set_]memory_stack_limit(). Actually, it's got nothing to do with the cppInterpreter. I first thought so, because we only used it with the cppInterpreter when I moved this from our VM to the port (a while ago now). But look at the code in void InterpreterGenerator::generate_stack_overflow_check(void) on x86 that computes the stack bound in rax ... that's not really simple, and requires two loads (stack_base, stack_size). The difference between cppInterpreter and template interpreter is that we always check against the stack_limit in the cppInterpreter, but the templateInterpreter first checks whether the stack is < 1 page, thus experiencing less overhead from the lengthy coding. Best regards, Goetz -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Dienstag, 25. Juni 2013 14:49 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements Which stack limit is this? Does it subtract off the red and yellow zones? Where do you set it? Yes, it would simplify the assembler code in the interpreter entries to use this. It might be better to rename it though if it's the usable stack (subtracting red and yellow zones) and maybe compute the value inside of Thread class (so you see it always subtracting the red and yellow zones). It's sort of ambiguous that this is happening. How about stack_overflow_limit()? Thanks, Coleen On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: Hi, We precompute the stack limit for overflow checks and save this limit in the thread. This simplifies the assembler coding checking the stack overflow. This change contains the necessary shared functionality. It can easily be ported to other platforms, too. http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ Please review this change. Best regards, Goetz. PS: I removed some parts of patch 0006 because I found a better platform-only solution. From coleen.phillimore at oracle.com Tue Jun 25 07:23:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Jun 2013 10:23:15 -0400 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> Message-ID: <51C9A7D3.50807@oracle.com> On 06/25/2013 10:07 AM, Lindenmaier, Goetz wrote: > > Hi, > > that's something I don't get: x86 does > > // Use the maximum number of pages we might bang. > > const int max_pages = StackShadowPages > > (StackRedPages+StackYellowPages) ? StackShadowPages : > > (StackRedPages+StackYellowPages) > > and sparc > > __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); > > in generate_stack_overflow_check(). > I don't know why these are different, except that they are coded separately and probably last touched at different times. > And we use the sum of all three. This is because we want to use the > > shadow space for exception handling, so we must overflow before we > > run into the shadow space. > Yes, we don't want to check that we are not pushing stack frames into the shadow space here. > All these different values could be set in the os_cpu file. > > But maybe they only differ because there is no shared coding > > yet? And they should be harmonized? > They absolutely should be harmonized, which would be good if the calculation that it uses is shared and the assembly code is simplified. We can do that after your change. > Bertrand, recomputing stack_base seems a good idea to me. > > But this would require that all platforms are adapted before > > _/stack/_base is removed. > We could do that when we fix the other platforms to use stack_overflow_limit(). The extra field in Thread is worth it. There are a lot of fields in Thread that we can remove (our out-pointer because they're never used) instead. Coleen > Best regards, > > Goetz. > > *From:*Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > *Sent:* Dienstag, 25. Juni 2013 15:34 > *To:* Lindenmaier, Goetz > *Cc:* hotspot-dev at openjdk.java.net; David Holmes > *Subject:* Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack > handling improvements > > > Yes, I think this would be useful for the other platforms to simplify > the stack overflow limit checking in the interpreter assembly code. > > 100 // Initialize the memory stack limit. > 101 address mem_stk_limit = thread->stack_base() - thread->stack_size() + > 102 ((StackShadowPages + StackYellowPages + StackRedPages) * os::vm_page_size()); > 103 > 104 thread->set_memory_stack_limit(mem_stk_limit); > > > > My other comment was to move 101-102 into the function > set_stack_overflow_limit() since nothing on those lines depends on the > platform and the values used to compute this are owned by class Thread > anyway. > > thanks, > Coleen > > On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: > > Hi Colleen, David, > > > > I'll rename the methods to stack_overflow_limit and update the webrev, > > I like that name better too. > > > > We set it in os::initialize_thread(): > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > > and we use it here (line427): > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp > > In that files the method is called [set_]memory_stack_limit(). > > > > Actually, it's got nothing to do with the cppInterpreter. I first thought so, > > because we only used it with the cppInterpreter when I moved this from > > our VM to the port (a while ago now). But look at the code in > > void InterpreterGenerator::generate_stack_overflow_check(void) on x86 that > > computes the stack bound in rax ... that's not really simple, and requires > > two loads (stack_base, stack_size). > > > > The difference between cppInterpreter and template interpreter is that > > we always check against the stack_limit in the cppInterpreter, but the > > templateInterpreter first checks whether the stack is < 1 page, thus > > experiencing less overhead from the lengthy coding. > > > > Best regards, > > Goetz > > > > > > -----Original Message----- > > From:hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > > Sent: Dienstag, 25. Juni 2013 14:49 > > To:hotspot-dev at openjdk.java.net > > Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements > > > > > > Which stack limit is this? Does it subtract off the red and yellow > > zones? Where do you set it? Yes, it would simplify the assembler code > > in the interpreter entries to use this. > > > > It might be better to rename it though if it's the usable stack > > (subtracting red and yellow zones) and maybe compute the value inside of > > Thread class (so you see it always subtracting the red and yellow > > zones). It's sort of ambiguous that this is happening. How about > > stack_overflow_limit()? > > > > Thanks, > > Coleen > > > > On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > We precompute the stack limit for overflow checks and save this > > limit in the thread. This simplifies the assembler coding checking > > the stack overflow. This change contains the necessary shared > > functionality. It can easily be ported to other platforms, too. > > http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ > > > > Please review this change. > > > > Best regards, > > Goetz. > > > > PS: I removed some parts of patch 0006 because I found a better > > platform-only solution. > > > From coleen.phillimore at oracle.com Tue Jun 25 07:33:29 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Jun 2013 10:33:29 -0400 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51C9A7D3.50807@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> <51C9A7D3.50807@oracle.com> Message-ID: <51C9AA39.2090002@oracle.com> On 06/25/2013 10:23 AM, Coleen Phillimore wrote: > Yes, we don't want to check that we are not pushing stack frames into > the shadow space here. sorry, I meant that we do want to check that we are not push the interpreter stack frame into the shadow space. From thomas.schatzl at oracle.com Tue Jun 25 08:02:35 2013 From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com) Date: Tue, 25 Jun 2013 15:02:35 +0000 Subject: hg: hsx/hsx24/hotspot: 8016740: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose Message-ID: <20130625150240.2D420484EF@hg.openjdk.java.net> Changeset: 7dd0c5a45d07 Author: tschatzl Date: 2013-06-25 09:55 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7dd0c5a45d07 8016740: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose Summary: Use GC_locker::is_active_and_needs_gc() instead of GC_locker::is_active() for providing information about the reason of heap expansion. Reviewed-by: johnc, tamao ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp From vladimir.kozlov at oracle.com Tue Jun 25 11:13:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Jun 2013 11:13:40 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51C9DAFD.3000800@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> Message-ID: <51C9DDD4.4090303@oracle.com> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have too many already)? Can you use a local constant? Where is whole Christian's mail? I redirected this RFR to hotspot-dev since it affects everyone. thanks, Vladimir On 6/25/13 11:01 AM, Tao Mao wrote: > Hi Chris, > > So you suggest the flag be "notproduct" or "develop"? > > Thanks. > Tao > > On 6/25/13 10:59 AM, Christian Thalinger wrote: >> I think we can do one step further to interpret the user's intent and >> suggest the correct VM options. Then i start to imagine that we have >> something like this From tao.mao at oracle.com Tue Jun 25 11:33:56 2013 From: tao.mao at oracle.com (Tao Mao) Date: Tue, 25 Jun 2013 11:33:56 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51C9DDD4.4090303@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> Message-ID: <51C9E294.9040506@oracle.com> OK, I'll move the flag to be local. Thanks. Tao On 6/25/13 11:13 AM, Vladimir Kozlov wrote: > Yes we need this! How many times I mistyped PrintMiscellaneous :( ? > > Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have too > many already)? Can you use a local constant? > > Where is whole Christian's mail? > > I redirected this RFR to hotspot-dev since it affects everyone. > > thanks, > Vladimir > > On 6/25/13 11:01 AM, Tao Mao wrote: >> Hi Chris, >> >> So you suggest the flag be "notproduct" or "develop"? >> >> Thanks. >> Tao >> >> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>> I think we can do one step further to interpret the user's intent and >>> suggest the correct VM options. Then i start to imagine that we have >>> something like this From weijun.wang at oracle.com Tue Jun 25 18:23:55 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Jun 2013 09:23:55 +0800 Subject: On 8017264: Java app crash on it's startup after Java updated to 7u25 from 7u21 Message-ID: <51CA42AB.5080706@oracle.com> Hi, Hotspot guys We (SE security) received a bug report on a new crash for 7u25 and need some help from you: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017264 Here the top frames look like: C [msvcr100.dll+0x10b3b] wcspbrk+0x12d V [jvm.dll+0xa9b63] C [w2k_lsa_auth.dll+0x167c] JNI_OnUnload+0x1c1 j sun.security.krb5.Credentials.acquireDefaultNativeCreds()Lsun/security/krb5/Credentials;+0 acquireDefaultNativeCreds() is a native method and it's defined at http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/3c08c9ebd1fb/src/windows/native/sun/security/krb5/NativeCreds.c I'm not sure why JNI_OnUnload is called so immediately, and as you can see it's simply 338 if ((*jvm)->GetEnv(jvm, (void **)&env, JNI_VERSION_1_2)) { 339 return; /* Nothing else we can do */ 340 } 341 342 if (ticketClass != NULL) { 343 (*env)->DeleteWeakGlobalRef(env,ticketClass); 344 } ... More DeleteWeakGlobalRefs How is it able to call wcspbrk and get crashed? BTW, the .c file has not been changed for 2 years. Also, according to the report, the customer (whose automatic reply has "out of office with no internet access till 15 July") runs 7u25 b16 but the public release on java.com is b17. Does it matter? Thanks Max From morris.meyer at oracle.com Tue Jun 25 18:40:17 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Wed, 26 Jun 2013 01:40:17 +0000 Subject: hg: hsx/hsx24/hotspot: 8013546: compiler/8011901/Test8011901.java fails with CompilationError: Compilation failed Message-ID: <20130626014019.829FE4852F@hg.openjdk.java.net> Changeset: 3500f22d989d Author: morris Date: 2013-06-25 11:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3500f22d989d 8013546: compiler/8011901/Test8011901.java fails with CompilationError: Compilation failed Summary: Remove JDK8 specific test Reviewed-by: kvn - test/compiler/8011901/Test8011901.java From bengt.rutisson at oracle.com Tue Jun 25 22:05:42 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 26 Jun 2013 07:05:42 +0200 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51C9E294.9040506@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> <51C9E294.9040506@oracle.com> Message-ID: <51CA76A6.9030208@oracle.com> Tao, This is great! Thanks for doing this! :) I haven't looked closely at the code yet, so this is not a review, but I agree with Christian that we don't need a flag for the "fuzziness". Also, it seems like it would be pretty straight forward to write a couple of tests for this feature. Maybe just two simple JTreg tests, one that tests that a misspelled command line option gets the right suggestion and one correctly spelled option that does not cause a suggestion. Thanks again for coming up with this! Bengt On 6/25/13 8:33 PM, Tao Mao wrote: > OK, I'll move the flag to be local. > > Thanks. > Tao > > On 6/25/13 11:13 AM, Vladimir Kozlov wrote: >> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? >> >> Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have >> too many already)? Can you use a local constant? >> >> Where is whole Christian's mail? >> >> I redirected this RFR to hotspot-dev since it affects everyone. >> >> thanks, >> Vladimir >> >> On 6/25/13 11:01 AM, Tao Mao wrote: >>> Hi Chris, >>> >>> So you suggest the flag be "notproduct" or "develop"? >>> >>> Thanks. >>> Tao >>> >>> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>>> I think we can do one step further to interpret the user's intent and >>>> suggest the correct VM options. Then i start to imagine that we have >>>> something like this From goetz.lindenmaier at sap.com Wed Jun 26 01:52:47 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 26 Jun 2013 08:52:47 +0000 Subject: RFR(XS): 8017531: 8010460 changes broke bytecodeInterpreter.cpp Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEE089@DEWDFEMB12A.global.corp.sap> Hi, This change repairs a small bug introduced by 8010460 in the cppInterpreter. In addition, it fixes two VERIFY_OOP()s that were called on Method*. http://cr.openjdk.java.net/~goetz/webrevs/8017531-fix_mh/ Please review this change. I think this should be pushed into the main branch, not the ppc64 staging repository. Best regards, Goetz. From dmitry.samersoff at oracle.com Wed Jun 26 02:49:05 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 26 Jun 2013 13:49:05 +0400 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CA76A6.9030208@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> <51C9E294.9040506@oracle.com> <51CA76A6.9030208@oracle.com> Message-ID: <51CAB911.9070006@oracle.com> Bengt, I don't have a link to webrev, but we *do need* a flag that turns this behavior on and it have to be off by default in production build. It's sysadmin nightmare when a program auto correct mistypings in startup scripts rather than abort immediately. -Dmitry On 2013-06-26 09:05, Bengt Rutisson wrote: > > Tao, > > This is great! Thanks for doing this! :) > > I haven't looked closely at the code yet, so this is not a review, but I > agree with Christian that we don't need a flag for the "fuzziness". > Also, it seems like it would be pretty straight forward to write a > couple of tests for this feature. Maybe just two simple JTreg tests, one > that tests that a misspelled command line option gets the right > suggestion and one correctly spelled option that does not cause a > suggestion. > > Thanks again for coming up with this! > Bengt > > > > On 6/25/13 8:33 PM, Tao Mao wrote: >> OK, I'll move the flag to be local. >> >> Thanks. >> Tao >> >> On 6/25/13 11:13 AM, Vladimir Kozlov wrote: >>> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? >>> >>> Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have >>> too many already)? Can you use a local constant? >>> >>> Where is whole Christian's mail? >>> >>> I redirected this RFR to hotspot-dev since it affects everyone. >>> >>> thanks, >>> Vladimir >>> >>> On 6/25/13 11:01 AM, Tao Mao wrote: >>>> Hi Chris, >>>> >>>> So you suggest the flag be "notproduct" or "develop"? >>>> >>>> Thanks. >>>> Tao >>>> >>>> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>>>> I think we can do one step further to interpret the user's intent and >>>>> suggest the correct VM options. Then i start to imagine that we have >>>>> something like this > -- 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 bengt.rutisson at oracle.com Wed Jun 26 05:29:25 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 26 Jun 2013 14:29:25 +0200 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CAB911.9070006@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> <51C9E294.9040506@oracle.com> <51CA76A6.9030208@oracle.com> <51CAB911.9070006@oracle.com> Message-ID: <51CADEA5.80102@oracle.com> Dmitry, I think you are miss understanding the change and the flag. The proposed change does not auto correct anything (despite the subject line). It just adds extra information to the already existing error messages when you make a spelling mistake on your command line. Bengt On 6/26/13 11:49 AM, Dmitry Samersoff wrote: > Bengt, > > I don't have a link to webrev, but we *do need* a flag that > turns this behavior on and it have to be off by default in production > build. > > It's sysadmin nightmare when a program auto correct mistypings in > startup scripts rather than abort immediately. > > -Dmitry > > > > On 2013-06-26 09:05, Bengt Rutisson wrote: >> Tao, >> >> This is great! Thanks for doing this! :) >> >> I haven't looked closely at the code yet, so this is not a review, but I >> agree with Christian that we don't need a flag for the "fuzziness". >> Also, it seems like it would be pretty straight forward to write a >> couple of tests for this feature. Maybe just two simple JTreg tests, one >> that tests that a misspelled command line option gets the right >> suggestion and one correctly spelled option that does not cause a >> suggestion. >> >> Thanks again for coming up with this! >> Bengt >> >> >> >> On 6/25/13 8:33 PM, Tao Mao wrote: >>> OK, I'll move the flag to be local. >>> >>> Thanks. >>> Tao >>> >>> On 6/25/13 11:13 AM, Vladimir Kozlov wrote: >>>> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? >>>> >>>> Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have >>>> too many already)? Can you use a local constant? >>>> >>>> Where is whole Christian's mail? >>>> >>>> I redirected this RFR to hotspot-dev since it affects everyone. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 6/25/13 11:01 AM, Tao Mao wrote: >>>>> Hi Chris, >>>>> >>>>> So you suggest the flag be "notproduct" or "develop"? >>>>> >>>>> Thanks. >>>>> Tao >>>>> >>>>> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>>>>> I think we can do one step further to interpret the user's intent and >>>>>> suggest the correct VM options. Then i start to imagine that we have >>>>>> something like this > From dmitry.samersoff at oracle.com Wed Jun 26 05:31:15 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 26 Jun 2013 16:31:15 +0400 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CADEA5.80102@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> <51C9E294.9040506@oracle.com> <51CA76A6.9030208@oracle.com> <51CAB911.9070006@oracle.com> <51CADEA5.80102@oracle.com> Message-ID: <51CADF13.4020305@oracle.com> Bengt, OK. In this case I'm OK not having this flag. Sorry for a noise. -Dmitry On 2013-06-26 16:29, Bengt Rutisson wrote: > > Dmitry, > > I think you are miss understanding the change and the flag. > > The proposed change does not auto correct anything (despite the subject > line). It just adds extra information to the already existing error > messages when you make a spelling mistake on your command line. > > Bengt > > On 6/26/13 11:49 AM, Dmitry Samersoff wrote: >> Bengt, >> >> I don't have a link to webrev, but we *do need* a flag that >> turns this behavior on and it have to be off by default in production >> build. >> >> It's sysadmin nightmare when a program auto correct mistypings in >> startup scripts rather than abort immediately. >> >> -Dmitry >> >> >> >> On 2013-06-26 09:05, Bengt Rutisson wrote: >>> Tao, >>> >>> This is great! Thanks for doing this! :) >>> >>> I haven't looked closely at the code yet, so this is not a review, but I >>> agree with Christian that we don't need a flag for the "fuzziness". >>> Also, it seems like it would be pretty straight forward to write a >>> couple of tests for this feature. Maybe just two simple JTreg tests, one >>> that tests that a misspelled command line option gets the right >>> suggestion and one correctly spelled option that does not cause a >>> suggestion. >>> >>> Thanks again for coming up with this! >>> Bengt >>> >>> >>> >>> On 6/25/13 8:33 PM, Tao Mao wrote: >>>> OK, I'll move the flag to be local. >>>> >>>> Thanks. >>>> Tao >>>> >>>> On 6/25/13 11:13 AM, Vladimir Kozlov wrote: >>>>> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? >>>>> >>>>> Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have >>>>> too many already)? Can you use a local constant? >>>>> >>>>> Where is whole Christian's mail? >>>>> >>>>> I redirected this RFR to hotspot-dev since it affects everyone. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> On 6/25/13 11:01 AM, Tao Mao wrote: >>>>>> Hi Chris, >>>>>> >>>>>> So you suggest the flag be "notproduct" or "develop"? >>>>>> >>>>>> Thanks. >>>>>> Tao >>>>>> >>>>>> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>>>>>> I think we can do one step further to interpret the user's intent >>>>>>> and >>>>>>> suggest the correct VM options. Then i start to imagine that we have >>>>>>> something like this >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Wed Jun 26 05:38:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Jun 2013 22:38:07 +1000 Subject: On 8017264: Java app crash on it's startup after Java updated to 7u25 from 7u21 In-Reply-To: <51CA42AB.5080706@oracle.com> References: <51CA42AB.5080706@oracle.com> Message-ID: <51CAE0AF.7060402@oracle.com> Max, Is a minidump available (not that I know how to work with them but they are more reliable than stack traces) ? I suspect the symbolic information in the stacktrace is reflecting closest available symbol rather than actual symbol. As you say the sequence of calls don't really make sense. David On 26/06/2013 11:23 AM, Weijun Wang wrote: > Hi, Hotspot guys > > We (SE security) received a bug report on a new crash for 7u25 and need > some help from you: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017264 > > Here the top frames look like: > > C [msvcr100.dll+0x10b3b] wcspbrk+0x12d > V [jvm.dll+0xa9b63] > C [w2k_lsa_auth.dll+0x167c] JNI_OnUnload+0x1c1 > j > sun.security.krb5.Credentials.acquireDefaultNativeCreds()Lsun/security/krb5/Credentials;+0 > > > acquireDefaultNativeCreds() is a native method and it's defined at > > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/3c08c9ebd1fb/src/windows/native/sun/security/krb5/NativeCreds.c > > > I'm not sure why JNI_OnUnload is called so immediately, and as you can > see it's simply > > 338 if ((*jvm)->GetEnv(jvm, (void **)&env, JNI_VERSION_1_2)) { > 339 return; /* Nothing else we can do */ > 340 } > 341 > 342 if (ticketClass != NULL) { > 343 (*env)->DeleteWeakGlobalRef(env,ticketClass); > 344 } > ... More DeleteWeakGlobalRefs > > How is it able to call wcspbrk and get crashed? > > BTW, the .c file has not been changed for 2 years. > > Also, according to the report, the customer (whose automatic reply has > "out of office with no internet access till 15 July") runs 7u25 b16 but > the public release on java.com is b17. Does it matter? > > Thanks > Max From weijun.wang at oracle.com Wed Jun 26 05:44:29 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Jun 2013 20:44:29 +0800 Subject: On 8017264: Java app crash on it's startup after Java updated to 7u25 from 7u21 In-Reply-To: <51CAE0AF.7060402@oracle.com> References: <51CA42AB.5080706@oracle.com> <51CAE0AF.7060402@oracle.com> Message-ID: <51CAE22D.5050306@oracle.com> Hi David I'm able to reproduce the problem on my computer and has pinpointed the exact Win32 API failing: The LSA login function returns a ticket with size 131074 bytes. Normally a ticket is smaller than several KB. There must be something wrong. It's a windows-i586 JRE running on a windows-x64 machine. I tried 7u21 and 8b94 and they all fails. So at least not a regression. Thanks Max On 6/26/13 8:38 PM, David Holmes wrote: > Max, > > Is a minidump available (not that I know how to work with them but they > are more reliable than stack traces) ? > > I suspect the symbolic information in the stacktrace is reflecting > closest available symbol rather than actual symbol. As you say the > sequence of calls don't really make sense. > > David > > On 26/06/2013 11:23 AM, Weijun Wang wrote: >> Hi, Hotspot guys >> >> We (SE security) received a bug report on a new crash for 7u25 and need >> some help from you: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017264 >> >> Here the top frames look like: >> >> C [msvcr100.dll+0x10b3b] wcspbrk+0x12d >> V [jvm.dll+0xa9b63] >> C [w2k_lsa_auth.dll+0x167c] JNI_OnUnload+0x1c1 >> j >> sun.security.krb5.Credentials.acquireDefaultNativeCreds()Lsun/security/krb5/Credentials;+0 >> >> >> >> acquireDefaultNativeCreds() is a native method and it's defined at >> >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/3c08c9ebd1fb/src/windows/native/sun/security/krb5/NativeCreds.c >> >> >> >> I'm not sure why JNI_OnUnload is called so immediately, and as you can >> see it's simply >> >> 338 if ((*jvm)->GetEnv(jvm, (void **)&env, JNI_VERSION_1_2)) { >> 339 return; /* Nothing else we can do */ >> 340 } >> 341 >> 342 if (ticketClass != NULL) { >> 343 (*env)->DeleteWeakGlobalRef(env,ticketClass); >> 344 } >> ... More DeleteWeakGlobalRefs >> >> How is it able to call wcspbrk and get crashed? >> >> BTW, the .c file has not been changed for 2 years. >> >> Also, according to the report, the customer (whose automatic reply has >> "out of office with no internet access till 15 July") runs 7u25 b16 but >> the public release on java.com is b17. Does it matter? >> >> Thanks >> Max From david.holmes at oracle.com Wed Jun 26 05:51:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Jun 2013 22:51:21 +1000 Subject: On 8017264: Java app crash on it's startup after Java updated to 7u25 from 7u21 In-Reply-To: <51CAE22D.5050306@oracle.com> References: <51CA42AB.5080706@oracle.com> <51CAE0AF.7060402@oracle.com> <51CAE22D.5050306@oracle.com> Message-ID: <51CAE3C9.50508@oracle.com> On 26/06/2013 10:44 PM, Weijun Wang wrote: > Hi David > > I'm able to reproduce the problem on my computer and has pinpointed the > exact Win32 API failing: The LSA login function returns a ticket with > size 131074 bytes. Normally a ticket is smaller than several KB. There > must be something wrong. Doesn't seem like a hotspot issue then. > It's a windows-i586 JRE running on a windows-x64 machine. I tried 7u21 > and 8b94 and they all fails. So at least not a regression. That's good to know. David > Thanks > Max > > On 6/26/13 8:38 PM, David Holmes wrote: >> Max, >> >> Is a minidump available (not that I know how to work with them but they >> are more reliable than stack traces) ? >> >> I suspect the symbolic information in the stacktrace is reflecting >> closest available symbol rather than actual symbol. As you say the >> sequence of calls don't really make sense. >> >> David >> >> On 26/06/2013 11:23 AM, Weijun Wang wrote: >>> Hi, Hotspot guys >>> >>> We (SE security) received a bug report on a new crash for 7u25 and need >>> some help from you: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017264 >>> >>> Here the top frames look like: >>> >>> C [msvcr100.dll+0x10b3b] wcspbrk+0x12d >>> V [jvm.dll+0xa9b63] >>> C [w2k_lsa_auth.dll+0x167c] JNI_OnUnload+0x1c1 >>> j >>> sun.security.krb5.Credentials.acquireDefaultNativeCreds()Lsun/security/krb5/Credentials;+0 >>> >>> >>> >>> >>> acquireDefaultNativeCreds() is a native method and it's defined at >>> >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/3c08c9ebd1fb/src/windows/native/sun/security/krb5/NativeCreds.c >>> >>> >>> >>> >>> I'm not sure why JNI_OnUnload is called so immediately, and as you can >>> see it's simply >>> >>> 338 if ((*jvm)->GetEnv(jvm, (void **)&env, >>> JNI_VERSION_1_2)) { >>> 339 return; /* Nothing else we can do */ >>> 340 } >>> 341 >>> 342 if (ticketClass != NULL) { >>> 343 (*env)->DeleteWeakGlobalRef(env,ticketClass); >>> 344 } >>> ... More DeleteWeakGlobalRefs >>> >>> How is it able to call wcspbrk and get crashed? >>> >>> BTW, the .c file has not been changed for 2 years. >>> >>> Also, according to the report, the customer (whose automatic reply has >>> "out of office with no internet access till 15 July") runs 7u25 b16 but >>> the public release on java.com is b17. Does it matter? >>> >>> Thanks >>> Max From coleen.phillimore at oracle.com Wed Jun 26 05:55:01 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Jun 2013 08:55:01 -0400 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CADF13.4020305@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> <51C9E294.9040506@oracle.com> <51CA76A6.9030208@oracle.com> <51CAB911.9070006@oracle.com> <51CADEA5.80102@oracle.com> <51CADF13.4020305@oracle.com> Message-ID: <51CAE4A5.6050906@oracle.com> I still don't think there's a webrev on the hotspot-dev mailing list. Can you (re)post one? Thanks, Coleen On 6/26/2013 8:31 AM, Dmitry Samersoff wrote: > Bengt, > > OK. In this case I'm OK not having this flag. > > Sorry for a noise. > > -Dmitry > > On 2013-06-26 16:29, Bengt Rutisson wrote: >> Dmitry, >> >> I think you are miss understanding the change and the flag. >> >> The proposed change does not auto correct anything (despite the subject >> line). It just adds extra information to the already existing error >> messages when you make a spelling mistake on your command line. >> >> Bengt >> >> On 6/26/13 11:49 AM, Dmitry Samersoff wrote: >>> Bengt, >>> >>> I don't have a link to webrev, but we *do need* a flag that >>> turns this behavior on and it have to be off by default in production >>> build. >>> >>> It's sysadmin nightmare when a program auto correct mistypings in >>> startup scripts rather than abort immediately. >>> >>> -Dmitry >>> >>> >>> >>> On 2013-06-26 09:05, Bengt Rutisson wrote: >>>> Tao, >>>> >>>> This is great! Thanks for doing this! :) >>>> >>>> I haven't looked closely at the code yet, so this is not a review, but I >>>> agree with Christian that we don't need a flag for the "fuzziness". >>>> Also, it seems like it would be pretty straight forward to write a >>>> couple of tests for this feature. Maybe just two simple JTreg tests, one >>>> that tests that a misspelled command line option gets the right >>>> suggestion and one correctly spelled option that does not cause a >>>> suggestion. >>>> >>>> Thanks again for coming up with this! >>>> Bengt >>>> >>>> >>>> >>>> On 6/25/13 8:33 PM, Tao Mao wrote: >>>>> OK, I'll move the flag to be local. >>>>> >>>>> Thanks. >>>>> Tao >>>>> >>>>> On 6/25/13 11:13 AM, Vladimir Kozlov wrote: >>>>>> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? >>>>>> >>>>>> Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have >>>>>> too many already)? Can you use a local constant? >>>>>> >>>>>> Where is whole Christian's mail? >>>>>> >>>>>> I redirected this RFR to hotspot-dev since it affects everyone. >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/25/13 11:01 AM, Tao Mao wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> So you suggest the flag be "notproduct" or "develop"? >>>>>>> >>>>>>> Thanks. >>>>>>> Tao >>>>>>> >>>>>>> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>>>>>>> I think we can do one step further to interpret the user's intent >>>>>>>> and >>>>>>>> suggest the correct VM options. Then i start to imagine that we have >>>>>>>> something like this > From david.holmes at oracle.com Wed Jun 26 05:56:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Jun 2013 22:56:14 +1000 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CADEA5.80102@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> <51C9E294.9040506@oracle.com> <51CA76A6.9030208@oracle.com> <51CAB911.9070006@oracle.com> <51CADEA5.80102@oracle.com> Message-ID: <51CAE4EE.8040002@oracle.com> On 26/06/2013 10:29 PM, Bengt Rutisson wrote: > > Dmitry, > > I think you are miss understanding the change and the flag. > > The proposed change does not auto correct anything (despite the subject > line). It just adds extra information to the already existing error > messages when you make a spelling mistake on your command line. If this is simply: Unrecognized VM option XXY perhaps you meant XXX then it seems not unreasonable. But a full webrev would be nice to see. David > Bengt > > On 6/26/13 11:49 AM, Dmitry Samersoff wrote: >> Bengt, >> >> I don't have a link to webrev, but we *do need* a flag that >> turns this behavior on and it have to be off by default in production >> build. >> >> It's sysadmin nightmare when a program auto correct mistypings in >> startup scripts rather than abort immediately. >> >> -Dmitry >> >> >> >> On 2013-06-26 09:05, Bengt Rutisson wrote: >>> Tao, >>> >>> This is great! Thanks for doing this! :) >>> >>> I haven't looked closely at the code yet, so this is not a review, but I >>> agree with Christian that we don't need a flag for the "fuzziness". >>> Also, it seems like it would be pretty straight forward to write a >>> couple of tests for this feature. Maybe just two simple JTreg tests, one >>> that tests that a misspelled command line option gets the right >>> suggestion and one correctly spelled option that does not cause a >>> suggestion. >>> >>> Thanks again for coming up with this! >>> Bengt >>> >>> >>> >>> On 6/25/13 8:33 PM, Tao Mao wrote: >>>> OK, I'll move the flag to be local. >>>> >>>> Thanks. >>>> Tao >>>> >>>> On 6/25/13 11:13 AM, Vladimir Kozlov wrote: >>>>> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? >>>>> >>>>> Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have >>>>> too many already)? Can you use a local constant? >>>>> >>>>> Where is whole Christian's mail? >>>>> >>>>> I redirected this RFR to hotspot-dev since it affects everyone. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> On 6/25/13 11:01 AM, Tao Mao wrote: >>>>>> Hi Chris, >>>>>> >>>>>> So you suggest the flag be "notproduct" or "develop"? >>>>>> >>>>>> Thanks. >>>>>> Tao >>>>>> >>>>>> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>>>>>> I think we can do one step further to interpret the user's intent >>>>>>> and >>>>>>> suggest the correct VM options. Then i start to imagine that we have >>>>>>> something like this >> > From bengt.rutisson at oracle.com Wed Jun 26 06:08:19 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 26 Jun 2013 15:08:19 +0200 Subject: Fwd: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51C9D712.1050105@oracle.com> References: <51C9D712.1050105@oracle.com> Message-ID: <51CAE7C3.6000205@oracle.com> -------- Original Message -------- Subject: Request for review: 8017611: Auto corrector for mistyped vm options Date: Tue, 25 Jun 2013 10:44:50 -0700 From: Tao Mao Organization: Oracle Corporation To: hotspot-gc-dev at openjdk.java.net I'm kinda tired of mistyping VM options and figuring it out "mentally"...let machines do it then. changeset: Currently, when we mistype VM options you will get the warning as following $java -XX:+UseParalelGC -version Unrecognized VM option 'UseParalelGC' I think we can do one step further to interpret the user's intent and suggest the correct VM options. Then i start to imagine that we have something like this $java -XX:+UseParalelGC -version Unrecognized VM option 'UseParalelGC' Did you mean 'UseParallelGC'? Please refer to the wikipedia http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient to get an idea of obtaining string similarity. This new feature is based on this theory. webrev: http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ Please try out this patch and see if it meets some need. Thanks. Tao From bengt.rutisson at oracle.com Wed Jun 26 06:09:25 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 26 Jun 2013 15:09:25 +0200 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CAE4A5.6050906@oracle.com> References: <51C9D712.1050105@oracle.com> <51C9DAFD.3000800@oracle.com> <51C9DDD4.4090303@oracle.com> <51C9E294.9040506@oracle.com> <51CA76A6.9030208@oracle.com> <51CAB911.9070006@oracle.com> <51CADEA5.80102@oracle.com> <51CADF13.4020305@oracle.com> <51CAE4A5.6050906@oracle.com> Message-ID: <51CAE805.7070905@oracle.com> On 6/26/13 2:55 PM, Coleen Phillimore wrote: > > I still don't think there's a webrev on the hotspot-dev mailing > list. Can you (re)post one? I didn't realize that the complete original mail (that was sent to hotspot-gc) was not forwarded before. I just forwarded Tao's original mail. Hope this clarifies things. Bengt > Thanks, > Coleen > > On 6/26/2013 8:31 AM, Dmitry Samersoff wrote: >> Bengt, >> >> OK. In this case I'm OK not having this flag. >> >> Sorry for a noise. >> >> -Dmitry >> >> On 2013-06-26 16:29, Bengt Rutisson wrote: >>> Dmitry, >>> >>> I think you are miss understanding the change and the flag. >>> >>> The proposed change does not auto correct anything (despite the subject >>> line). It just adds extra information to the already existing error >>> messages when you make a spelling mistake on your command line. >>> >>> Bengt >>> >>> On 6/26/13 11:49 AM, Dmitry Samersoff wrote: >>>> Bengt, >>>> >>>> I don't have a link to webrev, but we *do need* a flag that >>>> turns this behavior on and it have to be off by default in production >>>> build. >>>> >>>> It's sysadmin nightmare when a program auto correct mistypings in >>>> startup scripts rather than abort immediately. >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> On 2013-06-26 09:05, Bengt Rutisson wrote: >>>>> Tao, >>>>> >>>>> This is great! Thanks for doing this! :) >>>>> >>>>> I haven't looked closely at the code yet, so this is not a review, >>>>> but I >>>>> agree with Christian that we don't need a flag for the "fuzziness". >>>>> Also, it seems like it would be pretty straight forward to write a >>>>> couple of tests for this feature. Maybe just two simple JTreg >>>>> tests, one >>>>> that tests that a misspelled command line option gets the right >>>>> suggestion and one correctly spelled option that does not cause a >>>>> suggestion. >>>>> >>>>> Thanks again for coming up with this! >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 6/25/13 8:33 PM, Tao Mao wrote: >>>>>> OK, I'll move the flag to be local. >>>>>> >>>>>> Thanks. >>>>>> Tao >>>>>> >>>>>> On 6/25/13 11:13 AM, Vladimir Kozlov wrote: >>>>>>> Yes we need this! How many times I mistyped PrintMiscellaneous :( ? >>>>>>> >>>>>>> Why we need additional flag VMOptionsFuzzyMatchSimilarity (we have >>>>>>> too many already)? Can you use a local constant? >>>>>>> >>>>>>> Where is whole Christian's mail? >>>>>>> >>>>>>> I redirected this RFR to hotspot-dev since it affects everyone. >>>>>>> >>>>>>> thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/25/13 11:01 AM, Tao Mao wrote: >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> So you suggest the flag be "notproduct" or "develop"? >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Tao >>>>>>>> >>>>>>>> On 6/25/13 10:59 AM, Christian Thalinger wrote: >>>>>>>>> I think we can do one step further to interpret the user's intent >>>>>>>>> and >>>>>>>>> suggest the correct VM options. Then i start to imagine that >>>>>>>>> we have >>>>>>>>> something like this >> > From goetz.lindenmaier at sap.com Wed Jun 26 06:28:32 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 26 Jun 2013 13:28:32 +0000 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51C9A7D3.50807@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> <51C9A7D3.50807@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEE14C@DEWDFEMB12A.global.corp.sap> Hi, I added shared initialization code of the new field. I also moved the code from thread to JavaThread, as only there overflow checks happen. http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack-2/ Do you want to push this to some main repository (if you want to use this on other platforms) or should I push it into the ppc64 staging repo once tested and finally reviewed? Best regards, Goetz. From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Dienstag, 25. Juni 2013 16:23 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; David Holmes Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements On 06/25/2013 10:07 AM, Lindenmaier, Goetz wrote: Hi, that's something I don't get: x86 does // Use the maximum number of pages we might bang. const int max_pages = StackShadowPages > (StackRedPages+StackYellowPages) ? StackShadowPages : (StackRedPages+StackYellowPages) and sparc __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); in generate_stack_overflow_check(). I don't know why these are different, except that they are coded separately and probably last touched at different times. And we use the sum of all three. This is because we want to use the shadow space for exception handling, so we must overflow before we run into the shadow space. Yes, we don't want to check that we are not pushing stack frames into the shadow space here. All these different values could be set in the os_cpu file. But maybe they only differ because there is no shared coding yet? And they should be harmonized? They absolutely should be harmonized, which would be good if the calculation that it uses is shared and the assembly code is simplified. We can do that after your change. Bertrand, recomputing stack_base seems a good idea to me. But this would require that all platforms are adapted before _stack_base is removed. We could do that when we fix the other platforms to use stack_overflow_limit(). The extra field in Thread is worth it. There are a lot of fields in Thread that we can remove (our out-pointer because they're never used) instead. Coleen Best regards, Goetz. From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Dienstag, 25. Juni 2013 15:34 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; David Holmes Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements Yes, I think this would be useful for the other platforms to simplify the stack overflow limit checking in the interpreter assembly code. 100 // Initialize the memory stack limit. 101 address mem_stk_limit = thread->stack_base() - thread->stack_size() + 102 ((StackShadowPages + StackYellowPages + StackRedPages) * os::vm_page_size()); 103 104 thread->set_memory_stack_limit(mem_stk_limit); My other comment was to move 101-102 into the function set_stack_overflow_limit() since nothing on those lines depends on the platform and the values used to compute this are owned by class Thread anyway. thanks, Coleen On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: Hi Colleen, David, I'll rename the methods to stack_overflow_limit and update the webrev, I like that name better too. We set it in os::initialize_thread(): http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp and we use it here (line427): http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp In that files the method is called [set_]memory_stack_limit(). Actually, it's got nothing to do with the cppInterpreter. I first thought so, because we only used it with the cppInterpreter when I moved this from our VM to the port (a while ago now). But look at the code in void InterpreterGenerator::generate_stack_overflow_check(void) on x86 that computes the stack bound in rax ... that's not really simple, and requires two loads (stack_base, stack_size). The difference between cppInterpreter and template interpreter is that we always check against the stack_limit in the cppInterpreter, but the templateInterpreter first checks whether the stack is < 1 page, thus experiencing less overhead from the lengthy coding. Best regards, Goetz -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Dienstag, 25. Juni 2013 14:49 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements Which stack limit is this? Does it subtract off the red and yellow zones? Where do you set it? Yes, it would simplify the assembler code in the interpreter entries to use this. It might be better to rename it though if it's the usable stack (subtracting red and yellow zones) and maybe compute the value inside of Thread class (so you see it always subtracting the red and yellow zones). It's sort of ambiguous that this is happening. How about stack_overflow_limit()? Thanks, Coleen On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: Hi, We precompute the stack limit for overflow checks and save this limit in the thread. This simplifies the assembler coding checking the stack overflow. This change contains the necessary shared functionality. It can easily be ported to other platforms, too. http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ Please review this change. Best regards, Goetz. PS: I removed some parts of patch 0006 because I found a better platform-only solution. From dmitry.samersoff at oracle.com Wed Jun 26 06:48:29 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 26 Jun 2013 17:48:29 +0400 Subject: Fwd: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CAE7C3.6000205@oracle.com> References: <51C9D712.1050105@oracle.com> <51CAE7C3.6000205@oracle.com> Message-ID: <51CAF12D.4020607@oracle.com> Bengt, Thank you for clarifying things. Now it much more understandable. Few comments to webrev: 1. Typically Levenshtein distance[1] is used to implement futures like this one, but it might be an overkill here. 2. 351 if (!strncmp(bigram1, bigram2, 2)) { we can save a bit of cpu cycles writing it as *(short *)bigram1 == *(short *)bigram2 3. We probably don't need doubles here. [1] http://en.wikipedia.org/wiki/Levenshtein_distance -Dmitry On 2013-06-26 17:08, Bengt Rutisson wrote: > > > > -------- Original Message -------- > Subject: Request for review: 8017611: Auto corrector for mistyped vm > options > Date: Tue, 25 Jun 2013 10:44:50 -0700 > From: Tao Mao > Organization: Oracle Corporation > To: hotspot-gc-dev at openjdk.java.net > > > > I'm kinda tired of mistyping VM options and figuring it out > "mentally"...let machines do it then. > > changeset: > Currently, when we mistype VM options you will get the warning as following > > $java -XX:+UseParalelGC -version > Unrecognized VM option 'UseParalelGC' > > I think we can do one step further to interpret the user's intent and > suggest the correct VM options. Then i start to imagine that we have > something like this > > $java -XX:+UseParalelGC -version > Unrecognized VM option 'UseParalelGC' > Did you mean 'UseParallelGC'? > > Please refer to the wikipedia > http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient to > get an idea of obtaining string similarity. This new feature is based on > this theory. > > webrev: > http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ > > Please try out this patch and see if it meets some need. > > Thanks. > Tao > > > -- 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 goetz.lindenmaier at sap.com Wed Jun 26 07:30:11 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 26 Jun 2013 14:30:11 +0000 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> Hi, To use biased locking in our PPC64 VM,we fixed the biased locking implementation in the cppInterpreter. We also added BiasedLockingStatistic support. We need an additional ordering operation in revoke_bias() when writing the mark. The change enables biased locking for ppc64 per default. http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ Please review and test this change. Best regards, Goetz From vladimir.kozlov at oracle.com Wed Jun 26 08:16:51 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 08:16:51 -0700 Subject: RFR(XS): 8017531: 8010460 changes broke bytecodeInterpreter.cpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEE089@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEE089@DEWDFEMB12A.global.corp.sap> Message-ID: <51CB05E3.2050203@oracle.com> Thank you, Goetz I will push it into comp repo today. Vladimir On 6/26/13 1:52 AM, Lindenmaier, Goetz wrote: > Hi, > > This change repairs a small bug introduced by 8010460 in the > > cppInterpreter. In addition, it fixes two VERIFY_OOP()s that were called > > on Method*. > > http://cr.openjdk.java.net/~goetz/webrevs/8017531-fix_mh/ > > Please review this change. > > I think this should be pushed into the main branch, not the > > ppc64 staging repository. > > Best regards, > > Goetz. > From vladimir.kozlov at oracle.com Wed Jun 26 08:43:12 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 26 Jun 2013 15:43:12 +0000 Subject: hg: hsx/hsx24/hotspot: 8017510: Add a regression test for 8005956 Message-ID: <20130626154317.A391D48555@hg.openjdk.java.net> Changeset: 1122b46889b9 Author: adlertz Date: 2013-06-26 00:40 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1122b46889b9 8017510: Add a regression test for 8005956 Summary: Regression test for 8005956 Reviewed-by: kvn, twisti + test/compiler/8005956/PolynomialRoot.java From coleen.phillimore at oracle.com Wed Jun 26 12:11:31 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Jun 2013 15:11:31 -0400 Subject: RFR(XS): 8017531: 8010460 changes broke bytecodeInterpreter.cpp In-Reply-To: <51CB05E3.2050203@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEE089@DEWDFEMB12A.global.corp.sap> <51CB05E3.2050203@oracle.com> Message-ID: <51CB3CE3.7020108@oracle.com> I've reviewed this also, if you need another. Coleen On 6/26/2013 11:16 AM, Vladimir Kozlov wrote: > Thank you, Goetz > > I will push it into comp repo today. > > Vladimir > > On 6/26/13 1:52 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> This change repairs a small bug introduced by 8010460 in the >> >> cppInterpreter. In addition, it fixes two VERIFY_OOP()s that were >> called >> >> on Method*. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8017531-fix_mh/ >> >> Please review this change. >> >> I think this should be pushed into the main branch, not the >> >> ppc64 staging repository. >> >> Best regards, >> >> Goetz. >> From vladimir.kozlov at oracle.com Wed Jun 26 12:21:27 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 12:21:27 -0700 Subject: RFR(XS): 8017531: 8010460 changes broke bytecodeInterpreter.cpp In-Reply-To: <51CB3CE3.7020108@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEE089@DEWDFEMB12A.global.corp.sap> <51CB05E3.2050203@oracle.com> <51CB3CE3.7020108@oracle.com> Message-ID: <51CB3F37.3020109@oracle.com> Sorry, Coleen, the job is executed in JPRT queue already. Vladimir On 6/26/13 12:11 PM, Coleen Phillimore wrote: > > I've reviewed this also, if you need another. > Coleen > > On 6/26/2013 11:16 AM, Vladimir Kozlov wrote: >> Thank you, Goetz >> >> I will push it into comp repo today. >> >> Vladimir >> >> On 6/26/13 1:52 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This change repairs a small bug introduced by 8010460 in the >>> >>> cppInterpreter. In addition, it fixes two VERIFY_OOP()s that were >>> called >>> >>> on Method*. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8017531-fix_mh/ >>> >>> Please review this change. >>> >>> I think this should be pushed into the main branch, not the >>> >>> ppc64 staging repository. >>> >>> Best regards, >>> >>> Goetz. >>> > From markus.gronlund at oracle.com Wed Jun 26 12:49:01 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Wed, 26 Jun 2013 19:49:01 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130626194910.098074856E@hg.openjdk.java.net> Changeset: 8805ca77133d Author: egahlin Date: 2013-06-26 17:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8805ca77133d 8016331: Minor issues in event tracing metadata Reviewed-by: stefank, brutisso, mgronlun ! src/share/vm/trace/trace.xml Changeset: 43f92d82c553 Author: mgronlun Date: 2013-06-26 17:48 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/43f92d82c553 Merge From tao.mao at oracle.com Wed Jun 26 14:18:29 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 26 Jun 2013 14:18:29 -0700 Subject: Fwd: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CAF12D.4020607@oracle.com> References: <51C9D712.1050105@oracle.com> <51CAE7C3.6000205@oracle.com> <51CAF12D.4020607@oracle.com> Message-ID: <51CB5AA5.4010609@oracle.com> Thank you for comments, Dmitry. Please see inline. Tao On 6/26/13 6:48 AM, Dmitry Samersoff wrote: > Bengt, > > Thank you for clarifying things. Now it much more understandable. > > Few comments to webrev: > > 1. > Typically Levenshtein distance[1] is used to implement futures like this > one, but it might be an overkill here. Yes, you are right: it would be an overkill here. FYI, this link (http://rockymadden.com/stringmetric/) provides some typical string similarity metrics (and their implementations) in practice. More interestingly, the package also contains **phonetic** similarity (sorry, off point). > > 2. > 351 if (!strncmp(bigram1, bigram2, 2)) { > > we can save a bit of cpu cycles writing it as > *(short *)bigram1 == *(short *)bigram2 > > 3. > We probably don't need doubles here. Please see the webrev sent out shortly. > > > [1] http://en.wikipedia.org/wiki/Levenshtein_distance > > -Dmitry > > > > On 2013-06-26 17:08, Bengt Rutisson wrote: >> >> >> -------- Original Message -------- >> Subject: Request for review: 8017611: Auto corrector for mistyped vm >> options >> Date: Tue, 25 Jun 2013 10:44:50 -0700 >> From: Tao Mao >> Organization: Oracle Corporation >> To: hotspot-gc-dev at openjdk.java.net >> >> >> >> I'm kinda tired of mistyping VM options and figuring it out >> "mentally"...let machines do it then. >> >> changeset: >> Currently, when we mistype VM options you will get the warning as following >> >> $java -XX:+UseParalelGC -version >> Unrecognized VM option 'UseParalelGC' >> >> I think we can do one step further to interpret the user's intent and >> suggest the correct VM options. Then i start to imagine that we have >> something like this >> >> $java -XX:+UseParalelGC -version >> Unrecognized VM option 'UseParalelGC' >> Did you mean 'UseParallelGC'? >> >> Please refer to the wikipedia >> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient to >> get an idea of obtaining string similarity. This new feature is based on >> this theory. >> >> webrev: >> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >> >> Please try out this patch and see if it meets some need. >> >> Thanks. >> Tao >> >> >> > From tao.mao at oracle.com Wed Jun 26 14:19:31 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 26 Jun 2013 14:19:31 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51C9D712.1050105@oracle.com> References: <51C9D712.1050105@oracle.com> Message-ID: <51CB5AE3.7080205@oracle.com> new webrev: http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ diff from the last webrev: (1) put more restrictive type check when passing strings. (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. (3) simplify routine str_similar() (4) add jtreg test Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. Thank you all. Tao On 6/25/13 10:44 AM, Tao Mao wrote: > I'm kinda tired of mistyping VM options and figuring it out > "mentally"...let machines do it then. > > changeset: > Currently, when we mistype VM options you will get the warning as > following > > $java -XX:+UseParalelGC -version > Unrecognized VM option 'UseParalelGC' > > I think we can do one step further to interpret the user's intent and > suggest the correct VM options. Then i start to imagine that we have > something like this > > $java -XX:+UseParalelGC -version > Unrecognized VM option 'UseParalelGC' > Did you mean 'UseParallelGC'? > > Please refer to the wikipedia > http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient to > get an idea of obtaining string similarity. This new feature is based > on this theory. > > webrev: > http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ > > Please try out this patch and see if it meets some need. > > Thanks. > Tao From vladimir.kozlov at oracle.com Wed Jun 26 14:25:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 14:25:00 -0700 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEE14C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> <51C9A7D3.50807@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEE14C@DEWDFEMB12A.global.corp.sap> Message-ID: <51CB5C2C.1040607@oracle.com> I updated bug report to remove cppInterpreter from synopsis and description. Do we have agreement on these changes? Will runtime group do changes in our code to use new functionality? If not, we should push it into staging repo because I don't see other reasons to push it into main sources now. Thanks, Vladimir On 6/26/13 6:28 AM, Lindenmaier, Goetz wrote: > Hi, > > I added shared initialization code of the new field. > I also moved the code from thread to JavaThread, as only > there overflow checks happen. > http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack-2/ > > Do you want to push this to some main repository (if you want > to use this on other platforms) or should I push it into the > ppc64 staging repo once tested and finally reviewed? > > Best regards, > Goetz. > > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Dienstag, 25. Juni 2013 16:23 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; David Holmes > Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements > > > On 06/25/2013 10:07 AM, Lindenmaier, Goetz wrote: > Hi, > > that's something I don't get: x86 does > // Use the maximum number of pages we might bang. > const int max_pages = StackShadowPages > (StackRedPages+StackYellowPages) ? StackShadowPages : > (StackRedPages+StackYellowPages) > and sparc > __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); > in generate_stack_overflow_check(). > > I don't know why these are different, except that they are coded separately and probably last touched at different times. > > > > And we use the sum of all three. This is because we want to use the > shadow space for exception handling, so we must overflow before we > run into the shadow space. > > Yes, we don't want to check that we are not pushing stack frames into the shadow space here. > > > > All these different values could be set in the os_cpu file. > But maybe they only differ because there is no shared coding > yet? And they should be harmonized? > > They absolutely should be harmonized, which would be good if the calculation that it uses is shared and the assembly code is simplified. We can do that after your change. > > > > Bertrand, recomputing stack_base seems a good idea to me. > But this would require that all platforms are adapted before > _stack_base is removed. > > We could do that when we fix the other platforms to use stack_overflow_limit(). The extra field in Thread is worth it. There are a lot of fields in Thread that we can remove (our out-pointer because they're never used) instead. > > Coleen > > > > Best regards, > Goetz. > > > > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Dienstag, 25. Juni 2013 15:34 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; David Holmes > Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements > > > Yes, I think this would be useful for the other platforms to simplify the stack overflow limit checking in the interpreter assembly code. > > 100 // Initialize the memory stack limit. > > 101 address mem_stk_limit = thread->stack_base() - thread->stack_size() + > > 102 ((StackShadowPages + StackYellowPages + StackRedPages) * os::vm_page_size()); > > 103 > > 104 thread->set_memory_stack_limit(mem_stk_limit); > > > > > My other comment was to move 101-102 into the function set_stack_overflow_limit() since nothing on those lines depends on the platform and the values used to compute this are owned by class Thread anyway. > > thanks, > Coleen > On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: > > Hi Colleen, David, > > > > I'll rename the methods to stack_overflow_limit and update the webrev, > > I like that name better too. > > > > We set it in os::initialize_thread(): > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > > and we use it here (line427): > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp > > In that files the method is called [set_]memory_stack_limit(). > > > > Actually, it's got nothing to do with the cppInterpreter. I first thought so, > > because we only used it with the cppInterpreter when I moved this from > > our VM to the port (a while ago now). But look at the code in > > void InterpreterGenerator::generate_stack_overflow_check(void) on x86 that > > computes the stack bound in rax ... that's not really simple, and requires > > two loads (stack_base, stack_size). > > > > The difference between cppInterpreter and template interpreter is that > > we always check against the stack_limit in the cppInterpreter, but the > > templateInterpreter first checks whether the stack is < 1 page, thus > > experiencing less overhead from the lengthy coding. > > > > Best regards, > > Goetz > > > > > > -----Original Message----- > > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > > Sent: Dienstag, 25. Juni 2013 14:49 > > To: hotspot-dev at openjdk.java.net > > Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements > > > > > > Which stack limit is this? Does it subtract off the red and yellow > > zones? Where do you set it? Yes, it would simplify the assembler code > > in the interpreter entries to use this. > > > > It might be better to rename it though if it's the usable stack > > (subtracting red and yellow zones) and maybe compute the value inside of > > Thread class (so you see it always subtracting the red and yellow > > zones). It's sort of ambiguous that this is happening. How about > > stack_overflow_limit()? > > > > Thanks, > > Coleen > > > > On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > We precompute the stack limit for overflow checks and save this > > limit in the thread. This simplifies the assembler coding checking > > the stack overflow. This change contains the necessary shared > > functionality. It can easily be ported to other platforms, too. > > http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ > > > > Please review this change. > > > > Best regards, > > Goetz. > > > > PS: I removed some parts of patch 0006 because I found a better > > platform-only solution. > > > > From harold.seigel at oracle.com Wed Jun 26 14:45:54 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 26 Jun 2013 17:45:54 -0400 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB5AE3.7080205@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> Message-ID: <51CB6112.3050207@oracle.com> Hi Tao, This is a big help. In a case like this: % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version Unrecognized VM option 'ObjectAlignmentInBytes:16' would it ask you: Did you mean ObjectAlignmentInBytes*=* ? Thanks, Harold On 6/26/2013 5:19 PM, Tao Mao wrote: > new webrev: > http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ > > diff from the last webrev: > (1) put more restrictive type check when passing strings. > (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. > (3) simplify routine str_similar() > (4) add jtreg test > > Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. > Thank you all. > > Tao > > > On 6/25/13 10:44 AM, Tao Mao wrote: >> I'm kinda tired of mistyping VM options and figuring it out >> "mentally"...let machines do it then. >> >> changeset: >> Currently, when we mistype VM options you will get the warning as >> following >> >> $java -XX:+UseParalelGC -version >> Unrecognized VM option 'UseParalelGC' >> >> I think we can do one step further to interpret the user's intent and >> suggest the correct VM options. Then i start to imagine that we have >> something like this >> >> $java -XX:+UseParalelGC -version >> Unrecognized VM option 'UseParalelGC' >> Did you mean 'UseParallelGC'? >> >> Please refer to the wikipedia >> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >> to get an idea of obtaining string similarity. This new feature is >> based on this theory. >> >> webrev: >> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >> >> Please try out this patch and see if it meets some need. >> >> Thanks. >> Tao From vladimir.kozlov at oracle.com Wed Jun 26 14:48:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 14:48:00 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB5AE3.7080205@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> Message-ID: <51CB6190.1000306@oracle.com> Define fuzzy factor as float to avoid division and simplify condition: float VMOptionsFuzzyMatchSimilarity = 0.7; if (max_score < VMOptionsFuzzyMatchSimilarity) { Thanks, Vladimir On 6/26/13 2:19 PM, Tao Mao wrote: > new webrev: > http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ > > diff from the last webrev: > (1) put more restrictive type check when passing strings. > (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. > (3) simplify routine str_similar() > (4) add jtreg test > > Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. Thank > you all. > > Tao > > > On 6/25/13 10:44 AM, Tao Mao wrote: >> I'm kinda tired of mistyping VM options and figuring it out >> "mentally"...let machines do it then. >> >> changeset: >> Currently, when we mistype VM options you will get the warning as >> following >> >> $java -XX:+UseParalelGC -version >> Unrecognized VM option 'UseParalelGC' >> >> I think we can do one step further to interpret the user's intent and >> suggest the correct VM options. Then i start to imagine that we have >> something like this >> >> $java -XX:+UseParalelGC -version >> Unrecognized VM option 'UseParalelGC' >> Did you mean 'UseParallelGC'? >> >> Please refer to the wikipedia >> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient to >> get an idea of obtaining string similarity. This new feature is based >> on this theory. >> >> webrev: >> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >> >> Please try out this patch and see if it meets some need. >> >> Thanks. >> Tao From coleen.phillimore at oracle.com Wed Jun 26 14:54:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Jun 2013 17:54:45 -0400 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51CB5C2C.1040607@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> <51C9A7D3.50807@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEE14C@DEWDFEMB12A.global.corp.sap> <51CB5C2C.1040607@oracle.com> Message-ID: <51CB6325.9050105@oracle.com> On 6/26/2013 5:25 PM, Vladimir Kozlov wrote: > I updated bug report to remove cppInterpreter from synopsis and > description. > > Do we have agreement on these changes? > > Will runtime group do changes in our code to use new functionality? > If not, we should push it into staging repo because I don't see other > reasons to push it into main sources now. You can put it in the staging repo. I don't think we'll get to this soon. Coleen > > Thanks, > Vladimir > > On 6/26/13 6:28 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I added shared initialization code of the new field. >> I also moved the code from thread to JavaThread, as only >> there overflow checks happen. >> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack-2/ >> >> Do you want to push this to some main repository (if you want >> to use this on other platforms) or should I push it into the >> ppc64 staging repo once tested and finally reviewed? >> >> Best regards, >> Goetz. >> >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Dienstag, 25. Juni 2013 16:23 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; David Holmes >> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >> handling improvements >> >> >> On 06/25/2013 10:07 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> that's something I don't get: x86 does >> // Use the maximum number of pages we might bang. >> const int max_pages = StackShadowPages > >> (StackRedPages+StackYellowPages) ? StackShadowPages : >> (StackRedPages+StackYellowPages) >> and sparc >> __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); >> in generate_stack_overflow_check(). >> >> I don't know why these are different, except that they are coded >> separately and probably last touched at different times. >> >> >> >> And we use the sum of all three. This is because we want to use the >> shadow space for exception handling, so we must overflow before we >> run into the shadow space. >> >> Yes, we don't want to check that we are not pushing stack frames into >> the shadow space here. >> >> >> >> All these different values could be set in the os_cpu file. >> But maybe they only differ because there is no shared coding >> yet? And they should be harmonized? >> >> They absolutely should be harmonized, which would be good if the >> calculation that it uses is shared and the assembly code is >> simplified. We can do that after your change. >> >> >> >> Bertrand, recomputing stack_base seems a good idea to me. >> But this would require that all platforms are adapted before >> _stack_base is removed. >> >> We could do that when we fix the other platforms to use >> stack_overflow_limit(). The extra field in Thread is worth it. >> There are a lot of fields in Thread that we can remove (our >> out-pointer because they're never used) instead. >> >> Coleen >> >> >> >> Best regards, >> Goetz. >> >> >> >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Dienstag, 25. Juni 2013 15:34 >> To: Lindenmaier, Goetz >> Cc: >> hotspot-dev at openjdk.java.net; >> David Holmes >> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >> handling improvements >> >> >> Yes, I think this would be useful for the other platforms to simplify >> the stack overflow limit checking in the interpreter assembly code. >> >> 100 // Initialize the memory stack limit. >> >> 101 address mem_stk_limit = thread->stack_base() - >> thread->stack_size() + >> >> 102 ((StackShadowPages + StackYellowPages + StackRedPages) >> * os::vm_page_size()); >> >> 103 >> >> 104 thread->set_memory_stack_limit(mem_stk_limit); >> >> >> >> >> My other comment was to move 101-102 into the function >> set_stack_overflow_limit() since nothing on those lines depends on >> the platform and the values used to compute this are owned by class >> Thread anyway. >> >> thanks, >> Coleen >> On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: >> >> Hi Colleen, David, >> >> >> >> I'll rename the methods to stack_overflow_limit and update the webrev, >> >> I like that name better too. >> >> >> >> We set it in os::initialize_thread(): >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp >> >> >> and we use it here (line427): >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp >> >> >> In that files the method is called [set_]memory_stack_limit(). >> >> >> >> Actually, it's got nothing to do with the cppInterpreter. I first >> thought so, >> >> because we only used it with the cppInterpreter when I moved this from >> >> our VM to the port (a while ago now). But look at the code in >> >> void InterpreterGenerator::generate_stack_overflow_check(void) on x86 >> that >> >> computes the stack bound in rax ... that's not really simple, and >> requires >> >> two loads (stack_base, stack_size). >> >> >> >> The difference between cppInterpreter and template interpreter is that >> >> we always check against the stack_limit in the cppInterpreter, but the >> >> templateInterpreter first checks whether the stack is < 1 page, thus >> >> experiencing less overhead from the lengthy coding. >> >> >> >> Best regards, >> >> Goetz >> >> >> >> >> >> -----Original Message----- >> >> From: >> hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen >> Phillimore >> >> Sent: Dienstag, 25. Juni 2013 14:49 >> >> To: hotspot-dev at openjdk.java.net >> >> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >> handling improvements >> >> >> >> >> >> Which stack limit is this? Does it subtract off the red and yellow >> >> zones? Where do you set it? Yes, it would simplify the assembler code >> >> in the interpreter entries to use this. >> >> >> >> It might be better to rename it though if it's the usable stack >> >> (subtracting red and yellow zones) and maybe compute the value inside of >> >> Thread class (so you see it always subtracting the red and yellow >> >> zones). It's sort of ambiguous that this is happening. How about >> >> stack_overflow_limit()? >> >> >> >> Thanks, >> >> Coleen >> >> >> >> On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> >> >> We precompute the stack limit for overflow checks and save this >> >> limit in the thread. This simplifies the assembler coding checking >> >> the stack overflow. This change contains the necessary shared >> >> functionality. It can easily be ported to other platforms, too. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ >> >> >> >> >> Please review this change. >> >> >> >> Best regards, >> >> Goetz. >> >> >> >> PS: I removed some parts of patch 0006 because I found a better >> >> platform-only solution. >> >> >> >> From coleen.phillimore at oracle.com Wed Jun 26 14:55:31 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Jun 2013 17:55:31 -0400 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51CB5C2C.1040607@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> <51C9A7D3.50807@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEE14C@DEWDFEMB12A.global.corp.sap> <51CB5C2C.1040607@oracle.com> Message-ID: <51CB6353.8050203@oracle.com> On 6/26/2013 5:25 PM, Vladimir Kozlov wrote: > I updated bug report to remove cppInterpreter from synopsis and > description. > > Do we have agreement on these changes? Also, I think these changes look good. coleen > > Will runtime group do changes in our code to use new functionality? > If not, we should push it into staging repo because I don't see other > reasons to push it into main sources now. > > Thanks, > Vladimir > > On 6/26/13 6:28 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I added shared initialization code of the new field. >> I also moved the code from thread to JavaThread, as only >> there overflow checks happen. >> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack-2/ >> >> Do you want to push this to some main repository (if you want >> to use this on other platforms) or should I push it into the >> ppc64 staging repo once tested and finally reviewed? >> >> Best regards, >> Goetz. >> >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Dienstag, 25. Juni 2013 16:23 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; David Holmes >> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >> handling improvements >> >> >> On 06/25/2013 10:07 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> that's something I don't get: x86 does >> // Use the maximum number of pages we might bang. >> const int max_pages = StackShadowPages > >> (StackRedPages+StackYellowPages) ? StackShadowPages : >> (StackRedPages+StackYellowPages) >> and sparc >> __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); >> in generate_stack_overflow_check(). >> >> I don't know why these are different, except that they are coded >> separately and probably last touched at different times. >> >> >> >> And we use the sum of all three. This is because we want to use the >> shadow space for exception handling, so we must overflow before we >> run into the shadow space. >> >> Yes, we don't want to check that we are not pushing stack frames into >> the shadow space here. >> >> >> >> All these different values could be set in the os_cpu file. >> But maybe they only differ because there is no shared coding >> yet? And they should be harmonized? >> >> They absolutely should be harmonized, which would be good if the >> calculation that it uses is shared and the assembly code is >> simplified. We can do that after your change. >> >> >> >> Bertrand, recomputing stack_base seems a good idea to me. >> But this would require that all platforms are adapted before >> _stack_base is removed. >> >> We could do that when we fix the other platforms to use >> stack_overflow_limit(). The extra field in Thread is worth it. >> There are a lot of fields in Thread that we can remove (our >> out-pointer because they're never used) instead. >> >> Coleen >> >> >> >> Best regards, >> Goetz. >> >> >> >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Dienstag, 25. Juni 2013 15:34 >> To: Lindenmaier, Goetz >> Cc: >> hotspot-dev at openjdk.java.net; >> David Holmes >> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >> handling improvements >> >> >> Yes, I think this would be useful for the other platforms to simplify >> the stack overflow limit checking in the interpreter assembly code. >> >> 100 // Initialize the memory stack limit. >> >> 101 address mem_stk_limit = thread->stack_base() - >> thread->stack_size() + >> >> 102 ((StackShadowPages + StackYellowPages + StackRedPages) >> * os::vm_page_size()); >> >> 103 >> >> 104 thread->set_memory_stack_limit(mem_stk_limit); >> >> >> >> >> My other comment was to move 101-102 into the function >> set_stack_overflow_limit() since nothing on those lines depends on >> the platform and the values used to compute this are owned by class >> Thread anyway. >> >> thanks, >> Coleen >> On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: >> >> Hi Colleen, David, >> >> >> >> I'll rename the methods to stack_overflow_limit and update the webrev, >> >> I like that name better too. >> >> >> >> We set it in os::initialize_thread(): >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp >> >> >> and we use it here (line427): >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp >> >> >> In that files the method is called [set_]memory_stack_limit(). >> >> >> >> Actually, it's got nothing to do with the cppInterpreter. I first >> thought so, >> >> because we only used it with the cppInterpreter when I moved this from >> >> our VM to the port (a while ago now). But look at the code in >> >> void InterpreterGenerator::generate_stack_overflow_check(void) on x86 >> that >> >> computes the stack bound in rax ... that's not really simple, and >> requires >> >> two loads (stack_base, stack_size). >> >> >> >> The difference between cppInterpreter and template interpreter is that >> >> we always check against the stack_limit in the cppInterpreter, but the >> >> templateInterpreter first checks whether the stack is < 1 page, thus >> >> experiencing less overhead from the lengthy coding. >> >> >> >> Best regards, >> >> Goetz >> >> >> >> >> >> -----Original Message----- >> >> From: >> hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen >> Phillimore >> >> Sent: Dienstag, 25. Juni 2013 14:49 >> >> To: hotspot-dev at openjdk.java.net >> >> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >> handling improvements >> >> >> >> >> >> Which stack limit is this? Does it subtract off the red and yellow >> >> zones? Where do you set it? Yes, it would simplify the assembler code >> >> in the interpreter entries to use this. >> >> >> >> It might be better to rename it though if it's the usable stack >> >> (subtracting red and yellow zones) and maybe compute the value inside of >> >> Thread class (so you see it always subtracting the red and yellow >> >> zones). It's sort of ambiguous that this is happening. How about >> >> stack_overflow_limit()? >> >> >> >> Thanks, >> >> Coleen >> >> >> >> On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> >> >> We precompute the stack limit for overflow checks and save this >> >> limit in the thread. This simplifies the assembler coding checking >> >> the stack overflow. This change contains the necessary shared >> >> functionality. It can easily be ported to other platforms, too. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ >> >> >> >> >> Please review this change. >> >> >> >> Best regards, >> >> Goetz. >> >> >> >> PS: I removed some parts of patch 0006 because I found a better >> >> platform-only solution. >> >> >> >> From vladimir.kozlov at oracle.com Wed Jun 26 15:07:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 15:07:48 -0700 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51CB6353.8050203@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> <51C9A7D3.50807@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEE14C@DEWDFEMB12A.global.corp.sap> <51CB5C2C.1040607@oracle.com> <51CB6353.8050203@oracle.com> Message-ID: <51CB6634.10607@oracle.com> I am fine with changes, I have only code style comments. Please, add parenthesis: + if (is_Java_thread()) { + ((JavaThread*) this)->set_stack_overflow_limit(); + } Add indention/spaces and split line in set_stack_overflow_limit() for more clear view: + address stack_overflow_limit() { return _stack_overflow_limit; } + void set_stack_overflow_limit() { + _stack_overflow_limit = _stack_base - _stack_size + + ((StackShadowPages + + StackYellowPages + + StackRedPages) * os::vm_page_size()); + } Thanks, Vladimir On 6/26/13 2:55 PM, Coleen Phillimore wrote: > On 6/26/2013 5:25 PM, Vladimir Kozlov wrote: >> I updated bug report to remove cppInterpreter from synopsis and >> description. >> >> Do we have agreement on these changes? > > Also, I think these changes look good. > > coleen >> >> Will runtime group do changes in our code to use new functionality? >> If not, we should push it into staging repo because I don't see other >> reasons to push it into main sources now. >> >> Thanks, >> Vladimir >> >> On 6/26/13 6:28 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I added shared initialization code of the new field. >>> I also moved the code from thread to JavaThread, as only >>> there overflow checks happen. >>> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack-2/ >>> >>> Do you want to push this to some main repository (if you want >>> to use this on other platforms) or should I push it into the >>> ppc64 staging repo once tested and finally reviewed? >>> >>> Best regards, >>> Goetz. >>> >>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>> Sent: Dienstag, 25. Juni 2013 16:23 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-dev at openjdk.java.net; David Holmes >>> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >>> handling improvements >>> >>> >>> On 06/25/2013 10:07 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> that's something I don't get: x86 does >>> // Use the maximum number of pages we might bang. >>> const int max_pages = StackShadowPages > >>> (StackRedPages+StackYellowPages) ? StackShadowPages : >>> (StackRedPages+StackYellowPages) >>> and sparc >>> __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); >>> in generate_stack_overflow_check(). >>> >>> I don't know why these are different, except that they are coded >>> separately and probably last touched at different times. >>> >>> >>> >>> And we use the sum of all three. This is because we want to use the >>> shadow space for exception handling, so we must overflow before we >>> run into the shadow space. >>> >>> Yes, we don't want to check that we are not pushing stack frames into >>> the shadow space here. >>> >>> >>> >>> All these different values could be set in the os_cpu file. >>> But maybe they only differ because there is no shared coding >>> yet? And they should be harmonized? >>> >>> They absolutely should be harmonized, which would be good if the >>> calculation that it uses is shared and the assembly code is >>> simplified. We can do that after your change. >>> >>> >>> >>> Bertrand, recomputing stack_base seems a good idea to me. >>> But this would require that all platforms are adapted before >>> _stack_base is removed. >>> >>> We could do that when we fix the other platforms to use >>> stack_overflow_limit(). The extra field in Thread is worth it. >>> There are a lot of fields in Thread that we can remove (our >>> out-pointer because they're never used) instead. >>> >>> Coleen >>> >>> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>> Sent: Dienstag, 25. Juni 2013 15:34 >>> To: Lindenmaier, Goetz >>> Cc: >>> hotspot-dev at openjdk.java.net; >>> David Holmes >>> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >>> handling improvements >>> >>> >>> Yes, I think this would be useful for the other platforms to simplify >>> the stack overflow limit checking in the interpreter assembly code. >>> >>> 100 // Initialize the memory stack limit. >>> >>> 101 address mem_stk_limit = thread->stack_base() - >>> thread->stack_size() + >>> >>> 102 ((StackShadowPages + StackYellowPages + StackRedPages) >>> * os::vm_page_size()); >>> >>> 103 >>> >>> 104 thread->set_memory_stack_limit(mem_stk_limit); >>> >>> >>> >>> >>> My other comment was to move 101-102 into the function >>> set_stack_overflow_limit() since nothing on those lines depends on >>> the platform and the values used to compute this are owned by class >>> Thread anyway. >>> >>> thanks, >>> Coleen >>> On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: >>> >>> Hi Colleen, David, >>> >>> >>> >>> I'll rename the methods to stack_overflow_limit and update the webrev, >>> >>> I like that name better too. >>> >>> >>> >>> We set it in os::initialize_thread(): >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp >>> >>> >>> and we use it here (line427): >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp >>> >>> >>> In that files the method is called [set_]memory_stack_limit(). >>> >>> >>> >>> Actually, it's got nothing to do with the cppInterpreter. I first >>> thought so, >>> >>> because we only used it with the cppInterpreter when I moved this from >>> >>> our VM to the port (a while ago now). But look at the code in >>> >>> void InterpreterGenerator::generate_stack_overflow_check(void) on x86 >>> that >>> >>> computes the stack bound in rax ... that's not really simple, and >>> requires >>> >>> two loads (stack_base, stack_size). >>> >>> >>> >>> The difference between cppInterpreter and template interpreter is that >>> >>> we always check against the stack_limit in the cppInterpreter, but the >>> >>> templateInterpreter first checks whether the stack is < 1 page, thus >>> >>> experiencing less overhead from the lengthy coding. >>> >>> >>> >>> Best regards, >>> >>> Goetz >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: >>> hotspot-dev-bounces at openjdk.java.net >>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen >>> Phillimore >>> >>> Sent: Dienstag, 25. Juni 2013 14:49 >>> >>> To: hotspot-dev at openjdk.java.net >>> >>> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >>> handling improvements >>> >>> >>> >>> >>> >>> Which stack limit is this? Does it subtract off the red and yellow >>> >>> zones? Where do you set it? Yes, it would simplify the assembler code >>> >>> in the interpreter entries to use this. >>> >>> >>> >>> It might be better to rename it though if it's the usable stack >>> >>> (subtracting red and yellow zones) and maybe compute the value inside of >>> >>> Thread class (so you see it always subtracting the red and yellow >>> >>> zones). It's sort of ambiguous that this is happening. How about >>> >>> stack_overflow_limit()? >>> >>> >>> >>> Thanks, >>> >>> Coleen >>> >>> >>> >>> On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> >>> >>> We precompute the stack limit for overflow checks and save this >>> >>> limit in the thread. This simplifies the assembler coding checking >>> >>> the stack overflow. This change contains the necessary shared >>> >>> functionality. It can easily be ported to other platforms, too. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ >>> >>> >>> >>> >>> Please review this change. >>> >>> >>> >>> Best regards, >>> >>> Goetz. >>> >>> >>> >>> PS: I removed some parts of patch 0006 because I found a better >>> >>> platform-only solution. >>> >>> >>> >>> > From tao.mao at oracle.com Wed Jun 26 15:09:52 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 26 Jun 2013 15:09:52 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB6112.3050207@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> Message-ID: <51CB66B0.4030004@oracle.com> Hi Harold, This CR only deals with correcting VM option *names*. If this case needs to be resolved, it would be better to create another CR. See how many outcomes you'll get when you try out "~!@#$%^&*()_+" to replace "=" here. Thanks. Tao On 6/26/13 2:45 PM, harold seigel wrote: > Hi Tao, > > This is a big help. > > In a case like this: > > % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version > Unrecognized VM option 'ObjectAlignmentInBytes:16' > > > would it ask you: Did you mean ObjectAlignmentInBytes*=* ? > > Thanks, Harold > > On 6/26/2013 5:19 PM, Tao Mao wrote: >> new webrev: >> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >> >> diff from the last webrev: >> (1) put more restrictive type check when passing strings. >> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >> (3) simplify routine str_similar() >> (4) add jtreg test >> >> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >> Thank you all. >> >> Tao >> >> >> On 6/25/13 10:44 AM, Tao Mao wrote: >>> I'm kinda tired of mistyping VM options and figuring it out >>> "mentally"...let machines do it then. >>> >>> changeset: >>> Currently, when we mistype VM options you will get the warning as >>> following >>> >>> $java -XX:+UseParalelGC -version >>> Unrecognized VM option 'UseParalelGC' >>> >>> I think we can do one step further to interpret the user's intent >>> and suggest the correct VM options. Then i start to imagine that we >>> have something like this >>> >>> $java -XX:+UseParalelGC -version >>> Unrecognized VM option 'UseParalelGC' >>> Did you mean 'UseParallelGC'? >>> >>> Please refer to the wikipedia >>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>> to get an idea of obtaining string similarity. This new feature is >>> based on this theory. >>> >>> webrev: >>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>> >>> Please try out this patch and see if it meets some need. >>> >>> Thanks. >>> Tao > From vladimir.kozlov at oracle.com Wed Jun 26 15:27:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 15:27:52 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB66B0.4030004@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> Message-ID: <51CB6AE8.2010502@oracle.com> Tao, I would like to see it also and additional changes could be very simple: + jio_fprintf(defaultStream::error_stream(), + "Did you mean '%s%s'?\n", fuzzy_matched->name, (fuzzy_matched->is_bool() ? "" : "=")); so it would always print '=' for assignable flags. May be also '=X' instead of simple '=': Did you mean 'ObjectAlignmentInBytes=X'? Thanks, Vladimir On 6/26/13 3:09 PM, Tao Mao wrote: > Hi Harold, > > This CR only deals with correcting VM option *names*. > > If this case needs to be resolved, it would be better to create another > CR. See how many outcomes you'll get when you try out "~!@#$%^&*()_+" to > replace "=" here. > > Thanks. > Tao > > On 6/26/13 2:45 PM, harold seigel wrote: >> Hi Tao, >> >> This is a big help. >> >> In a case like this: >> >> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >> Unrecognized VM option 'ObjectAlignmentInBytes:16' >> >> >> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >> >> Thanks, Harold >> >> On 6/26/2013 5:19 PM, Tao Mao wrote: >>> new webrev: >>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>> >>> diff from the last webrev: >>> (1) put more restrictive type check when passing strings. >>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>> (3) simplify routine str_similar() >>> (4) add jtreg test >>> >>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>> Thank you all. >>> >>> Tao >>> >>> >>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>> I'm kinda tired of mistyping VM options and figuring it out >>>> "mentally"...let machines do it then. >>>> >>>> changeset: >>>> Currently, when we mistype VM options you will get the warning as >>>> following >>>> >>>> $java -XX:+UseParalelGC -version >>>> Unrecognized VM option 'UseParalelGC' >>>> >>>> I think we can do one step further to interpret the user's intent >>>> and suggest the correct VM options. Then i start to imagine that we >>>> have something like this >>>> >>>> $java -XX:+UseParalelGC -version >>>> Unrecognized VM option 'UseParalelGC' >>>> Did you mean 'UseParallelGC'? >>>> >>>> Please refer to the wikipedia >>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>> to get an idea of obtaining string similarity. This new feature is >>>> based on this theory. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>> >>>> Please try out this patch and see if it meets some need. >>>> >>>> Thanks. >>>> Tao >> From vladimir.kozlov at oracle.com Wed Jun 26 16:34:50 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 16:34:50 -0700 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> Message-ID: <51CB7A9A.9010307@oracle.com> Hi Goetz, On 6/26/13 7:30 AM, Lindenmaier, Goetz wrote: > Hi, > > To use biased locking in our PPC64 VM,we fixed the biased locking implementation > in the cppInterpreter. We also added BiasedLockingStatistic support. Oracle does not use cppInterpreter and no building and testing are done. So we trust you to do testing of these changes. I glanced on these changes and they look fine to me. One suggestion I heard from David H. is to move cppInterpreter related files (all 6 of them) from interpreter/ directory to separate directory. So we can see when changes does not affect our shared code. > We need an additional ordering operation in revoke_bias() when writing > the mark. Why you need ordering only for locked objects in this code? And why here at all? This code is executed at safepoint. thanks, Vladimir > The change enables biased locking for ppc64 per default. > http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ > > Please review and test this change. > > Best regards, > Goetz > From tao.mao at oracle.com Wed Jun 26 16:36:44 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 26 Jun 2013 16:36:44 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB6AE8.2010502@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> <51CB6AE8.2010502@oracle.com> Message-ID: <51CB7B0C.4050203@oracle.com> new webrev: http://cr.openjdk.java.net/~tamao/8017611/webrev.02/ Suggestions are taken from Harold and Vladimir. Thanks. Tao On 6/26/13 3:27 PM, Vladimir Kozlov wrote: > Tao, > > I would like to see it also and additional changes could be very simple: > > + jio_fprintf(defaultStream::error_stream(), > + "Did you mean '%s%s'?\n", fuzzy_matched->name, > (fuzzy_matched->is_bool() ? "" : "=")); > > so it would always print '=' for assignable flags. May be also '=X' > instead of simple '=': > > Did you mean 'ObjectAlignmentInBytes=X'? > > Thanks, > Vladimir > > On 6/26/13 3:09 PM, Tao Mao wrote: >> Hi Harold, >> >> This CR only deals with correcting VM option *names*. >> >> If this case needs to be resolved, it would be better to create another >> CR. See how many outcomes you'll get when you try out "~!@#$%^&*()_+" to >> replace "=" here. >> >> Thanks. >> Tao >> >> On 6/26/13 2:45 PM, harold seigel wrote: >>> Hi Tao, >>> >>> This is a big help. >>> >>> In a case like this: >>> >>> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >>> Unrecognized VM option 'ObjectAlignmentInBytes:16' >>> >>> >>> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >>> >>> Thanks, Harold >>> >>> On 6/26/2013 5:19 PM, Tao Mao wrote: >>>> new webrev: >>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>>> >>>> diff from the last webrev: >>>> (1) put more restrictive type check when passing strings. >>>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>>> (3) simplify routine str_similar() >>>> (4) add jtreg test >>>> >>>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>>> Thank you all. >>>> >>>> Tao >>>> >>>> >>>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>>> I'm kinda tired of mistyping VM options and figuring it out >>>>> "mentally"...let machines do it then. >>>>> >>>>> changeset: >>>>> Currently, when we mistype VM options you will get the warning as >>>>> following >>>>> >>>>> $java -XX:+UseParalelGC -version >>>>> Unrecognized VM option 'UseParalelGC' >>>>> >>>>> I think we can do one step further to interpret the user's intent >>>>> and suggest the correct VM options. Then i start to imagine that we >>>>> have something like this >>>>> >>>>> $java -XX:+UseParalelGC -version >>>>> Unrecognized VM option 'UseParalelGC' >>>>> Did you mean 'UseParallelGC'? >>>>> >>>>> Please refer to the wikipedia >>>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>>> to get an idea of obtaining string similarity. This new feature is >>>>> based on this theory. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>>> >>>>> Please try out this patch and see if it meets some need. >>>>> >>>>> Thanks. >>>>> Tao >>> From vladimir.kozlov at oracle.com Wed Jun 26 16:40:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2013 16:40:59 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB7B0C.4050203@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> <51CB6AE8.2010502@oracle.com> <51CB7B0C.4050203@oracle.com> Message-ID: <51CB7C0B.60504@oracle.com> Looks good. Thanks, Vladimir On 6/26/13 4:36 PM, Tao Mao wrote: > new webrev: > http://cr.openjdk.java.net/~tamao/8017611/webrev.02/ > > Suggestions are taken from Harold and Vladimir. > > Thanks. > Tao > > On 6/26/13 3:27 PM, Vladimir Kozlov wrote: >> Tao, >> >> I would like to see it also and additional changes could be very simple: >> >> + jio_fprintf(defaultStream::error_stream(), >> + "Did you mean '%s%s'?\n", fuzzy_matched->name, >> (fuzzy_matched->is_bool() ? "" : "=")); >> >> so it would always print '=' for assignable flags. May be also '=X' >> instead of simple '=': >> >> Did you mean 'ObjectAlignmentInBytes=X'? >> >> Thanks, >> Vladimir >> >> On 6/26/13 3:09 PM, Tao Mao wrote: >>> Hi Harold, >>> >>> This CR only deals with correcting VM option *names*. >>> >>> If this case needs to be resolved, it would be better to create another >>> CR. See how many outcomes you'll get when you try out "~!@#$%^&*()_+" to >>> replace "=" here. >>> >>> Thanks. >>> Tao >>> >>> On 6/26/13 2:45 PM, harold seigel wrote: >>>> Hi Tao, >>>> >>>> This is a big help. >>>> >>>> In a case like this: >>>> >>>> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >>>> Unrecognized VM option 'ObjectAlignmentInBytes:16' >>>> >>>> >>>> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >>>> >>>> Thanks, Harold >>>> >>>> On 6/26/2013 5:19 PM, Tao Mao wrote: >>>>> new webrev: >>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>>>> >>>>> diff from the last webrev: >>>>> (1) put more restrictive type check when passing strings. >>>>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>>>> (3) simplify routine str_similar() >>>>> (4) add jtreg test >>>>> >>>>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>>>> Thank you all. >>>>> >>>>> Tao >>>>> >>>>> >>>>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>>>> I'm kinda tired of mistyping VM options and figuring it out >>>>>> "mentally"...let machines do it then. >>>>>> >>>>>> changeset: >>>>>> Currently, when we mistype VM options you will get the warning as >>>>>> following >>>>>> >>>>>> $java -XX:+UseParalelGC -version >>>>>> Unrecognized VM option 'UseParalelGC' >>>>>> >>>>>> I think we can do one step further to interpret the user's intent >>>>>> and suggest the correct VM options. Then i start to imagine that we >>>>>> have something like this >>>>>> >>>>>> $java -XX:+UseParalelGC -version >>>>>> Unrecognized VM option 'UseParalelGC' >>>>>> Did you mean 'UseParallelGC'? >>>>>> >>>>>> Please refer to the wikipedia >>>>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>>>> to get an idea of obtaining string similarity. This new feature is >>>>>> based on this theory. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>>>> >>>>>> Please try out this patch and see if it meets some need. >>>>>> >>>>>> Thanks. >>>>>> Tao >>>> From vladimir.kozlov at oracle.com Wed Jun 26 15:57:47 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 26 Jun 2013 22:57:47 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130626225754.2F9E44857B@hg.openjdk.java.net> Changeset: c1130faa6248 Author: adlertz Date: 2013-06-24 07:28 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c1130faa6248 8001345: VM crashes with assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove unnecessary LoadN / DecodeN nodes at MemBarAcquire nodes. Reviewed-by: kvn, roland ! src/share/vm/opto/memnode.cpp Changeset: f460d2390c02 Author: kvn Date: 2013-06-26 12:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f460d2390c02 Merge From bengt.rutisson at oracle.com Wed Jun 26 20:09:04 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 27 Jun 2013 03:09:04 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130627030913.D91D248593@hg.openjdk.java.net> Changeset: dcb233d6bfad Author: brutisso Date: 2013-06-26 13:09 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dcb233d6bfad 8013791: G1: G1CollectorPolicy::initialize_flags() may set min_alignment > max_alignment Summary: Make sure max alignemnt is at least as large as min alignment Reviewed-by: johnc, jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/g1/TestRegionAlignment.java Changeset: 785a9733f507 Author: brutisso Date: 2013-06-26 04:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/785a9733f507 Merge - test/compiler/8011901/Test8011901.java Changeset: a6a52b788186 Author: brutisso Date: 2013-06-26 16:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a6a52b788186 Merge From nils.loodin at oracle.com Thu Jun 27 00:00:51 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Thu, 27 Jun 2013 07:00:51 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130627070115.24BA8485A4@hg.openjdk.java.net> Changeset: 91acb82a8b7a Author: dholmes Date: 2013-06-19 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/91acb82a8b7a 8014326: [OSX] All libjvm symbols are exported Summary: Add support for a MacOS X compatible form of the libjvm mapfile. Reviewed-by: dcubed, rdurbin, coleenp ! make/bsd/makefiles/build_vm_def.sh ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product Changeset: b9f4c4ec0f50 Author: iklam Date: 2013-06-19 20:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b9f4c4ec0f50 8008964: NPG: Memory regression: Thread::_metadata_handles uses 1 KB per thread. Summary: Reduce default size of Thread::_metadata_handles from 300 to 30 Reviewed-by: coleenp, sspitsyn ! src/share/vm/runtime/thread.cpp Changeset: b3cd8b58b798 Author: mgronlun Date: 2013-06-20 11:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b3cd8b58b798 8016735: Remove superfluous EnableInvokeDynamic warning from UnlockDiagnosticVMOptions check Reviewed-by: sla, dholmes ! src/share/vm/runtime/globals.cpp Changeset: 9ba41a4a71ff Author: coleenp Date: 2013-06-21 10:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9ba41a4a71ff 8004124: Handle and/or warn about SI_KERNEL Summary: Detect this crash in the signal handler and give a fatal error message instead of making us chase down bugs that don't reproduce Reviewed-by: kvn, mgerdin, dholmes ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: bed34a7a3b9b Author: coleenp Date: 2013-06-21 10:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bed34a7a3b9b 8017177: more explicit code location information in hs_err crash log Summary: Add code pc location for compiled code Reviewed-by: kvn, coleenp Contributed-by: doug.simon at oracle.com ! src/share/vm/runtime/frame.cpp Changeset: bb6c7f2f10fd Author: dcubed Date: 2013-06-21 08:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bb6c7f2f10fd Merge Changeset: b7bc7c94b4b5 Author: dcubed Date: 2013-06-21 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b7bc7c94b4b5 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: d9eed26d638a Author: iklam Date: 2013-06-23 22:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d9eed26d638a 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes Summary: Added Atomic::inc(short*) to support this change. Reviewed-by: coleenp, dcubed, dholmes, minqi ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: e0c9a1d29eb4 Author: coleenp Date: 2013-06-24 18:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0c9a1d29eb4 8016325: JVM hangs verifying system dictionary Summary: Minimize redundant verifications of Klasses. Reviewed-by: hseigel, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/shark/sharkBuilder.cpp Changeset: 01e10b366055 Author: sla Date: 2013-06-25 14:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/01e10b366055 8017561: Build errors caused by missing .PHONY Reviewed-by: stefank, brutisso ! make/excludeSrc.make From goetz.lindenmaier at sap.com Thu Jun 27 00:44:40 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 27 Jun 2013 07:44:40 +0000 Subject: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements In-Reply-To: <51CB6634.10607@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEDE3B@DEWDFEMB12A.global.corp.sap> <51C991D2.8050307@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDE8E@DEWDFEMB12A.global.corp.sap> <51C99C54.1010909@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEDEBF@DEWDFEMB12A.global.corp.sap> <51C9A7D3.50807@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFEE14C@DEWDFEMB12A.global.corp.sap> <51CB5C2C.1040607@oracle.com> <51CB6353.8050203@oracle.com> <51CB6634.10607@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFEE31B@DEWDFEMB12A.global.corp.sap> Hi, Coleen, Vladimir, David thanks for the reviews. I updated the code style and added reviewers in the webrev. http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack-2/ Vladimir, will you run it through JPRT and push it to the repo? I think it was not yet tested by you. Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 27. Juni 2013 00:08 To: coleen.phillimore at oracle.com Cc: Lindenmaier, Goetz; ppc-aix-port-dev at openjdk.java.net; David Holmes; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack handling improvements I am fine with changes, I have only code style comments. Please, add parenthesis: + if (is_Java_thread()) { + ((JavaThread*) this)->set_stack_overflow_limit(); + } Add indention/spaces and split line in set_stack_overflow_limit() for more clear view: + address stack_overflow_limit() { return _stack_overflow_limit; } + void set_stack_overflow_limit() { + _stack_overflow_limit = _stack_base - _stack_size + + ((StackShadowPages + + StackYellowPages + + StackRedPages) * os::vm_page_size()); + } Thanks, Vladimir On 6/26/13 2:55 PM, Coleen Phillimore wrote: > On 6/26/2013 5:25 PM, Vladimir Kozlov wrote: >> I updated bug report to remove cppInterpreter from synopsis and >> description. >> >> Do we have agreement on these changes? > > Also, I think these changes look good. > > coleen >> >> Will runtime group do changes in our code to use new functionality? >> If not, we should push it into staging repo because I don't see other >> reasons to push it into main sources now. >> >> Thanks, >> Vladimir >> >> On 6/26/13 6:28 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I added shared initialization code of the new field. >>> I also moved the code from thread to JavaThread, as only >>> there overflow checks happen. >>> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack-2/ >>> >>> Do you want to push this to some main repository (if you want >>> to use this on other platforms) or should I push it into the >>> ppc64 staging repo once tested and finally reviewed? >>> >>> Best regards, >>> Goetz. >>> >>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>> Sent: Dienstag, 25. Juni 2013 16:23 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-dev at openjdk.java.net; David Holmes >>> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >>> handling improvements >>> >>> >>> On 06/25/2013 10:07 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> that's something I don't get: x86 does >>> // Use the maximum number of pages we might bang. >>> const int max_pages = StackShadowPages > >>> (StackRedPages+StackYellowPages) ? StackShadowPages : >>> (StackRedPages+StackYellowPages) >>> and sparc >>> __ set( (StackRedPages+StackYellowPages) * page_size, Rscratch2 ); >>> in generate_stack_overflow_check(). >>> >>> I don't know why these are different, except that they are coded >>> separately and probably last touched at different times. >>> >>> >>> >>> And we use the sum of all three. This is because we want to use the >>> shadow space for exception handling, so we must overflow before we >>> run into the shadow space. >>> >>> Yes, we don't want to check that we are not pushing stack frames into >>> the shadow space here. >>> >>> >>> >>> All these different values could be set in the os_cpu file. >>> But maybe they only differ because there is no shared coding >>> yet? And they should be harmonized? >>> >>> They absolutely should be harmonized, which would be good if the >>> calculation that it uses is shared and the assembly code is >>> simplified. We can do that after your change. >>> >>> >>> >>> Bertrand, recomputing stack_base seems a good idea to me. >>> But this would require that all platforms are adapted before >>> _stack_base is removed. >>> >>> We could do that when we fix the other platforms to use >>> stack_overflow_limit(). The extra field in Thread is worth it. >>> There are a lot of fields in Thread that we can remove (our >>> out-pointer because they're never used) instead. >>> >>> Coleen >>> >>> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>> Sent: Dienstag, 25. Juni 2013 15:34 >>> To: Lindenmaier, Goetz >>> Cc: >>> hotspot-dev at openjdk.java.net; >>> David Holmes >>> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >>> handling improvements >>> >>> >>> Yes, I think this would be useful for the other platforms to simplify >>> the stack overflow limit checking in the interpreter assembly code. >>> >>> 100 // Initialize the memory stack limit. >>> >>> 101 address mem_stk_limit = thread->stack_base() - >>> thread->stack_size() + >>> >>> 102 ((StackShadowPages + StackYellowPages + StackRedPages) >>> * os::vm_page_size()); >>> >>> 103 >>> >>> 104 thread->set_memory_stack_limit(mem_stk_limit); >>> >>> >>> >>> >>> My other comment was to move 101-102 into the function >>> set_stack_overflow_limit() since nothing on those lines depends on >>> the platform and the values used to compute this are owned by class >>> Thread anyway. >>> >>> thanks, >>> Coleen >>> On 06/25/2013 09:27 AM, Lindenmaier, Goetz wrote: >>> >>> Hi Colleen, David, >>> >>> >>> >>> I'll rename the methods to stack_overflow_limit and update the webrev, >>> >>> I like that name better too. >>> >>> >>> >>> We set it in os::initialize_thread(): >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp >>> >>> >>> and we use it here (line427): >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/2a6fd169b0b7/src/cpu/ppc/vm/cppInterpreter_ppc.cpp >>> >>> >>> In that files the method is called [set_]memory_stack_limit(). >>> >>> >>> >>> Actually, it's got nothing to do with the cppInterpreter. I first >>> thought so, >>> >>> because we only used it with the cppInterpreter when I moved this from >>> >>> our VM to the port (a while ago now). But look at the code in >>> >>> void InterpreterGenerator::generate_stack_overflow_check(void) on x86 >>> that >>> >>> computes the stack bound in rax ... that's not really simple, and >>> requires >>> >>> two loads (stack_base, stack_size). >>> >>> >>> >>> The difference between cppInterpreter and template interpreter is that >>> >>> we always check against the stack_limit in the cppInterpreter, but the >>> >>> templateInterpreter first checks whether the stack is < 1 page, thus >>> >>> experiencing less overhead from the lengthy coding. >>> >>> >>> >>> Best regards, >>> >>> Goetz >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: >>> hotspot-dev-bounces at openjdk.java.net >>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen >>> Phillimore >>> >>> Sent: Dienstag, 25. Juni 2013 14:49 >>> >>> To: hotspot-dev at openjdk.java.net >>> >>> Subject: Re: RFR(S): 8017313: PPC64 (part 6): cppInterpreter: stack >>> handling improvements >>> >>> >>> >>> >>> >>> Which stack limit is this? Does it subtract off the red and yellow >>> >>> zones? Where do you set it? Yes, it would simplify the assembler code >>> >>> in the interpreter entries to use this. >>> >>> >>> >>> It might be better to rename it though if it's the usable stack >>> >>> (subtracting red and yellow zones) and maybe compute the value inside of >>> >>> Thread class (so you see it always subtracting the red and yellow >>> >>> zones). It's sort of ambiguous that this is happening. How about >>> >>> stack_overflow_limit()? >>> >>> >>> >>> Thanks, >>> >>> Coleen >>> >>> >>> >>> On 06/25/2013 08:44 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> >>> >>> We precompute the stack limit for overflow checks and save this >>> >>> limit in the thread. This simplifies the assembler coding checking >>> >>> the stack overflow. This change contains the necessary shared >>> >>> functionality. It can easily be ported to other platforms, too. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8017313-stack/ >>> >>> >>> >>> >>> Please review this change. >>> >>> >>> >>> Best regards, >>> >>> Goetz. >>> >>> >>> >>> PS: I removed some parts of patch 0006 because I found a better >>> >>> platform-only solution. >>> >>> >>> >>> > From zhengyu.gu at oracle.com Thu Jun 27 01:05:07 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 27 Jun 2013 08:05:07 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130627080514.DD056485A9@hg.openjdk.java.net> Changeset: 91f2a56579c2 Author: zgu Date: 2013-06-25 17:22 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/91f2a56579c2 8017478: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Fixed possible NULL pointer that caused SIGSEGV Reviewed-by: coleenp, acorn, ctornqvi ! src/share/vm/services/memReporter.cpp Changeset: b1e9bbeb81f3 Author: zgu Date: 2013-06-26 20:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b1e9bbeb81f3 Merge From david.holmes at oracle.com Thu Jun 27 05:18:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Jun 2013 22:18:55 +1000 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking In-Reply-To: <51CB7A9A.9010307@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> <51CB7A9A.9010307@oracle.com> Message-ID: <51CC2DAF.4050102@oracle.com> Vladimir, On 27/06/2013 9:34 AM, Vladimir Kozlov wrote: > Hi Goetz, > > On 6/26/13 7:30 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> To use biased locking in our PPC64 VM,we fixed the biased locking >> implementation >> in the cppInterpreter. We also added BiasedLockingStatistic support. > > Oracle does not use cppInterpreter and no building and testing are done. > So we trust you to do testing of these changes. > I glanced on these changes and they look fine to me. > > One suggestion I heard from David H. is to move cppInterpreter related > files (all 6 of them) from interpreter/ directory to separate directory. > So we can see when changes does not affect our shared code. It is a general source of confusion to new hotspot engineers that there are actually two interpreters in one directory and that one is not used by the historical primary ports. It also isn't obvious that bytecodeInterpreter.cpp pertains to the cppInterpreter. >> We need an additional ordering operation in revoke_bias() when writing >> the mark. > > Why you need ordering only for locked objects in this code? And why here > at all? This code is executed at safepoint. There is one occurrence that is not executed at a safepoint - see BiasedLocking::Condition BiasedLocking::revoke_and_rebias. Though it seems to be operating only on current thread in that case. The use of release_set_mark seems consistent with other uses in synchronizer.cpp. David ----- > thanks, > Vladimir > >> The change enables biased locking for ppc64 per default. >> http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ >> >> Please review and test this change. >> >> Best regards, >> Goetz >> From dmitry.samersoff at oracle.com Thu Jun 27 05:40:00 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 27 Jun 2013 16:40:00 +0400 Subject: Fwd: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB5AA5.4010609@oracle.com> References: <51C9D712.1050105@oracle.com> <51CAE7C3.6000205@oracle.com> <51CAF12D.4020607@oracle.com> <51CB5AA5.4010609@oracle.com> Message-ID: <51CC32A0.4010409@oracle.com> Tao, > FYI, this link (http://rockymadden.com/stringmetric/) provides some Interesting. Thanks! -Dmitry On 2013-06-27 01:18, Tao Mao wrote: > Thank you for comments, Dmitry. Please see inline. > > Tao > > On 6/26/13 6:48 AM, Dmitry Samersoff wrote: >> Bengt, >> >> Thank you for clarifying things. Now it much more understandable. >> >> Few comments to webrev: >> >> 1. >> Typically Levenshtein distance[1] is used to implement futures like this >> one, but it might be an overkill here. > Yes, you are right: it would be an overkill here. > > FYI, this link (http://rockymadden.com/stringmetric/) provides some > typical string similarity metrics (and their implementations) in > practice. More interestingly, the package also contains **phonetic** > similarity (sorry, off point). >> >> 2. >> 351 if (!strncmp(bigram1, bigram2, 2)) { >> >> we can save a bit of cpu cycles writing it as >> *(short *)bigram1 == *(short *)bigram2 >> >> 3. >> We probably don't need doubles here. > Please see the webrev sent out shortly. >> >> >> [1] http://en.wikipedia.org/wiki/Levenshtein_distance >> >> -Dmitry >> >> >> >> On 2013-06-26 17:08, Bengt Rutisson wrote: >>> >>> >>> -------- Original Message -------- >>> Subject: Request for review: 8017611: Auto corrector for mistyped vm >>> options >>> Date: Tue, 25 Jun 2013 10:44:50 -0700 >>> From: Tao Mao >>> Organization: Oracle Corporation >>> To: hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>> I'm kinda tired of mistyping VM options and figuring it out >>> "mentally"...let machines do it then. >>> >>> changeset: >>> Currently, when we mistype VM options you will get the warning as >>> following >>> >>> $java -XX:+UseParalelGC -version >>> Unrecognized VM option 'UseParalelGC' >>> >>> I think we can do one step further to interpret the user's intent and >>> suggest the correct VM options. Then i start to imagine that we have >>> something like this >>> >>> $java -XX:+UseParalelGC -version >>> Unrecognized VM option 'UseParalelGC' >>> Did you mean 'UseParallelGC'? >>> >>> Please refer to the wikipedia >>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient to >>> get an idea of obtaining string similarity. This new feature is based on >>> this theory. >>> >>> webrev: >>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>> >>> Please try out this patch and see if it meets some need. >>> >>> Thanks. >>> Tao >>> >>> >>> >> -- 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 Jun 27 05:47:23 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 27 Jun 2013 16:47:23 +0400 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB7B0C.4050203@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> <51CB6AE8.2010502@oracle.com> <51CB7B0C.4050203@oracle.com> Message-ID: <51CC345B.6010205@oracle.com> Looks good for me. PS: Something bad happens with webrev - sdiffs is not generated correctly (other diffs are fine). On 2013-06-27 03:36, Tao Mao wrote: > new webrev: > http://cr.openjdk.java.net/~tamao/8017611/webrev.02/ > > Suggestions are taken from Harold and Vladimir. > > Thanks. > Tao > > On 6/26/13 3:27 PM, Vladimir Kozlov wrote: >> Tao, >> >> I would like to see it also and additional changes could be very simple: >> >> + jio_fprintf(defaultStream::error_stream(), >> + "Did you mean '%s%s'?\n", fuzzy_matched->name, >> (fuzzy_matched->is_bool() ? "" : "=")); >> >> so it would always print '=' for assignable flags. May be also '=X' >> instead of simple '=': >> >> Did you mean 'ObjectAlignmentInBytes=X'? >> >> Thanks, >> Vladimir >> >> On 6/26/13 3:09 PM, Tao Mao wrote: >>> Hi Harold, >>> >>> This CR only deals with correcting VM option *names*. >>> >>> If this case needs to be resolved, it would be better to create another >>> CR. See how many outcomes you'll get when you try out "~!@#$%^&*()_+" to >>> replace "=" here. >>> >>> Thanks. >>> Tao >>> >>> On 6/26/13 2:45 PM, harold seigel wrote: >>>> Hi Tao, >>>> >>>> This is a big help. >>>> >>>> In a case like this: >>>> >>>> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >>>> Unrecognized VM option 'ObjectAlignmentInBytes:16' >>>> >>>> >>>> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >>>> >>>> Thanks, Harold >>>> >>>> On 6/26/2013 5:19 PM, Tao Mao wrote: >>>>> new webrev: >>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>>>> >>>>> diff from the last webrev: >>>>> (1) put more restrictive type check when passing strings. >>>>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>>>> (3) simplify routine str_similar() >>>>> (4) add jtreg test >>>>> >>>>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>>>> Thank you all. >>>>> >>>>> Tao >>>>> >>>>> >>>>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>>>> I'm kinda tired of mistyping VM options and figuring it out >>>>>> "mentally"...let machines do it then. >>>>>> >>>>>> changeset: >>>>>> Currently, when we mistype VM options you will get the warning as >>>>>> following >>>>>> >>>>>> $java -XX:+UseParalelGC -version >>>>>> Unrecognized VM option 'UseParalelGC' >>>>>> >>>>>> I think we can do one step further to interpret the user's intent >>>>>> and suggest the correct VM options. Then i start to imagine that we >>>>>> have something like this >>>>>> >>>>>> $java -XX:+UseParalelGC -version >>>>>> Unrecognized VM option 'UseParalelGC' >>>>>> Did you mean 'UseParallelGC'? >>>>>> >>>>>> Please refer to the wikipedia >>>>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>>>> to get an idea of obtaining string similarity. This new feature is >>>>>> based on this theory. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>>>> >>>>>> Please try out this patch and see if it meets some need. >>>>>> >>>>>> Thanks. >>>>>> Tao >>>> -- 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 harold.seigel at oracle.com Thu Jun 27 06:19:37 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 27 Jun 2013 09:19:37 -0400 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CC345B.6010205@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> <51CB6AE8.2010502@oracle.com> <51CB7B0C.4050203@oracle.com> <51CC345B.6010205@oracle.com> Message-ID: <51CC3BE9.3050301@oracle.com> It looks good to me. Thanks, Harold On 6/27/2013 8:47 AM, Dmitry Samersoff wrote: > Looks good for me. > > PS: Something bad happens with webrev - sdiffs is not generated > correctly (other diffs are fine). > > > On 2013-06-27 03:36, Tao Mao wrote: >> new webrev: >> http://cr.openjdk.java.net/~tamao/8017611/webrev.02/ >> >> Suggestions are taken from Harold and Vladimir. >> >> Thanks. >> Tao >> >> On 6/26/13 3:27 PM, Vladimir Kozlov wrote: >>> Tao, >>> >>> I would like to see it also and additional changes could be very simple: >>> >>> + jio_fprintf(defaultStream::error_stream(), >>> + "Did you mean '%s%s'?\n", fuzzy_matched->name, >>> (fuzzy_matched->is_bool() ? "" : "=")); >>> >>> so it would always print '=' for assignable flags. May be also '=X' >>> instead of simple '=': >>> >>> Did you mean 'ObjectAlignmentInBytes=X'? >>> >>> Thanks, >>> Vladimir >>> >>> On 6/26/13 3:09 PM, Tao Mao wrote: >>>> Hi Harold, >>>> >>>> This CR only deals with correcting VM option *names*. >>>> >>>> If this case needs to be resolved, it would be better to create another >>>> CR. See how many outcomes you'll get when you try out "~!@#$%^&*()_+" to >>>> replace "=" here. >>>> >>>> Thanks. >>>> Tao >>>> >>>> On 6/26/13 2:45 PM, harold seigel wrote: >>>>> Hi Tao, >>>>> >>>>> This is a big help. >>>>> >>>>> In a case like this: >>>>> >>>>> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >>>>> Unrecognized VM option 'ObjectAlignmentInBytes:16' >>>>> >>>>> >>>>> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 6/26/2013 5:19 PM, Tao Mao wrote: >>>>>> new webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>>>>> >>>>>> diff from the last webrev: >>>>>> (1) put more restrictive type check when passing strings. >>>>>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>>>>> (3) simplify routine str_similar() >>>>>> (4) add jtreg test >>>>>> >>>>>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>>>>> Thank you all. >>>>>> >>>>>> Tao >>>>>> >>>>>> >>>>>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>>>>> I'm kinda tired of mistyping VM options and figuring it out >>>>>>> "mentally"...let machines do it then. >>>>>>> >>>>>>> changeset: >>>>>>> Currently, when we mistype VM options you will get the warning as >>>>>>> following >>>>>>> >>>>>>> $java -XX:+UseParalelGC -version >>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>> >>>>>>> I think we can do one step further to interpret the user's intent >>>>>>> and suggest the correct VM options. Then i start to imagine that we >>>>>>> have something like this >>>>>>> >>>>>>> $java -XX:+UseParalelGC -version >>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>> Did you mean 'UseParallelGC'? >>>>>>> >>>>>>> Please refer to the wikipedia >>>>>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>>>>> to get an idea of obtaining string similarity. This new feature is >>>>>>> based on this theory. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>>>>> >>>>>>> Please try out this patch and see if it meets some need. >>>>>>> >>>>>>> Thanks. >>>>>>> Tao > From erik.helin at oracle.com Thu Jun 27 06:35:14 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Thu, 27 Jun 2013 13:35:14 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130627133527.0ED3D485BD@hg.openjdk.java.net> Changeset: feae15578b2f Author: tamao Date: 2013-06-07 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/feae15578b2f 7122222: GC log is limited to 2G for 32-bit Summary: Enable large file support for generated 32-bit ostream.o on Linux and Solaris (as only the two need this) by setting -D_FILE_OFFSET_BITS=64 in compilation Reviewed-by: tbell, mgerdin, dcubed Contributed-by: tamao ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/os/solaris/vm/os_solaris.inline.hpp Changeset: df7e1c0e3dc1 Author: jmasa Date: 2013-06-25 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df7e1c0e3dc1 8014546: MetaspaceAux print_metaspace_change() should print "used" after GC not capacity Reviewed-by: johnc, tschatzl ! src/share/vm/memory/metaspace.cpp Changeset: f99cd6e20ab1 Author: jmasa Date: 2013-06-25 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f99cd6e20ab1 8014851: UseAdaptiveGCBoundary is broken Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp + test/gc/parallelScavenge/AdaptiveGCBoundary.java Changeset: 71963b3f802a Author: ehelin Date: 2013-06-26 16:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/71963b3f802a 8013590: NPG: Add a memory pool MXBean for Metaspace Reviewed-by: jmasa, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/metaspace/TestMetaspaceMemoryPool.java Changeset: f8972b867ded Author: ehelin Date: 2013-06-27 10:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f8972b867ded Merge From tao.mao at oracle.com Thu Jun 27 09:39:52 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 27 Jun 2013 09:39:52 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CB7C0B.60504@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> <51CB6AE8.2010502@oracle.com> <51CB7B0C.4050203@oracle.com> <51CB7C0B.60504@oracle.com> Message-ID: <51CC6AD8.4080100@oracle.com> Thank you for review. Tao On 6/26/13 4:40 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/26/13 4:36 PM, Tao Mao wrote: >> new webrev: >> http://cr.openjdk.java.net/~tamao/8017611/webrev.02/ >> >> Suggestions are taken from Harold and Vladimir. >> >> Thanks. >> Tao >> >> On 6/26/13 3:27 PM, Vladimir Kozlov wrote: >>> Tao, >>> >>> I would like to see it also and additional changes could be very >>> simple: >>> >>> + jio_fprintf(defaultStream::error_stream(), >>> + "Did you mean '%s%s'?\n", fuzzy_matched->name, >>> (fuzzy_matched->is_bool() ? "" : "=")); >>> >>> so it would always print '=' for assignable flags. May be also '=X' >>> instead of simple '=': >>> >>> Did you mean 'ObjectAlignmentInBytes=X'? >>> >>> Thanks, >>> Vladimir >>> >>> On 6/26/13 3:09 PM, Tao Mao wrote: >>>> Hi Harold, >>>> >>>> This CR only deals with correcting VM option *names*. >>>> >>>> If this case needs to be resolved, it would be better to create >>>> another >>>> CR. See how many outcomes you'll get when you try out >>>> "~!@#$%^&*()_+" to >>>> replace "=" here. >>>> >>>> Thanks. >>>> Tao >>>> >>>> On 6/26/13 2:45 PM, harold seigel wrote: >>>>> Hi Tao, >>>>> >>>>> This is a big help. >>>>> >>>>> In a case like this: >>>>> >>>>> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >>>>> Unrecognized VM option 'ObjectAlignmentInBytes:16' >>>>> >>>>> >>>>> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 6/26/2013 5:19 PM, Tao Mao wrote: >>>>>> new webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>>>>> >>>>>> diff from the last webrev: >>>>>> (1) put more restrictive type check when passing strings. >>>>>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>>>>> (3) simplify routine str_similar() >>>>>> (4) add jtreg test >>>>>> >>>>>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>>>>> Thank you all. >>>>>> >>>>>> Tao >>>>>> >>>>>> >>>>>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>>>>> I'm kinda tired of mistyping VM options and figuring it out >>>>>>> "mentally"...let machines do it then. >>>>>>> >>>>>>> changeset: >>>>>>> Currently, when we mistype VM options you will get the warning as >>>>>>> following >>>>>>> >>>>>>> $java -XX:+UseParalelGC -version >>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>> >>>>>>> I think we can do one step further to interpret the user's intent >>>>>>> and suggest the correct VM options. Then i start to imagine that we >>>>>>> have something like this >>>>>>> >>>>>>> $java -XX:+UseParalelGC -version >>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>> Did you mean 'UseParallelGC'? >>>>>>> >>>>>>> Please refer to the wikipedia >>>>>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>>>>> to get an idea of obtaining string similarity. This new feature is >>>>>>> based on this theory. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>>>>> >>>>>>> Please try out this patch and see if it meets some need. >>>>>>> >>>>>>> Thanks. >>>>>>> Tao >>>>> From tao.mao at oracle.com Thu Jun 27 09:40:05 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 27 Jun 2013 09:40:05 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CC3BE9.3050301@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> <51CB6AE8.2010502@oracle.com> <51CB7B0C.4050203@oracle.com> <51CC345B.6010205@oracle.com> <51CC3BE9.3050301@oracle.com> Message-ID: <51CC6AE5.5050607@oracle.com> Thanks for review. Tao On 6/27/13 6:19 AM, harold seigel wrote: > It looks good to me. > > Thanks, Harold > > On 6/27/2013 8:47 AM, Dmitry Samersoff wrote: >> Looks good for me. >> >> PS: Something bad happens with webrev - sdiffs is not generated >> correctly (other diffs are fine). >> >> >> On 2013-06-27 03:36, Tao Mao wrote: >>> new webrev: >>> http://cr.openjdk.java.net/~tamao/8017611/webrev.02/ >>> >>> Suggestions are taken from Harold and Vladimir. >>> >>> Thanks. >>> Tao >>> >>> On 6/26/13 3:27 PM, Vladimir Kozlov wrote: >>>> Tao, >>>> >>>> I would like to see it also and additional changes could be very >>>> simple: >>>> >>>> + jio_fprintf(defaultStream::error_stream(), >>>> + "Did you mean '%s%s'?\n", fuzzy_matched->name, >>>> (fuzzy_matched->is_bool() ? "" : "=")); >>>> >>>> so it would always print '=' for assignable flags. May be also '=X' >>>> instead of simple '=': >>>> >>>> Did you mean 'ObjectAlignmentInBytes=X'? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/26/13 3:09 PM, Tao Mao wrote: >>>>> Hi Harold, >>>>> >>>>> This CR only deals with correcting VM option *names*. >>>>> >>>>> If this case needs to be resolved, it would be better to create >>>>> another >>>>> CR. See how many outcomes you'll get when you try out >>>>> "~!@#$%^&*()_+" to >>>>> replace "=" here. >>>>> >>>>> Thanks. >>>>> Tao >>>>> >>>>> On 6/26/13 2:45 PM, harold seigel wrote: >>>>>> Hi Tao, >>>>>> >>>>>> This is a big help. >>>>>> >>>>>> In a case like this: >>>>>> >>>>>> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >>>>>> Unrecognized VM option 'ObjectAlignmentInBytes:16' >>>>>> >>>>>> >>>>>> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 6/26/2013 5:19 PM, Tao Mao wrote: >>>>>>> new webrev: >>>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>>>>>> >>>>>>> diff from the last webrev: >>>>>>> (1) put more restrictive type check when passing strings. >>>>>>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>>>>>> (3) simplify routine str_similar() >>>>>>> (4) add jtreg test >>>>>>> >>>>>>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>>>>>> Thank you all. >>>>>>> >>>>>>> Tao >>>>>>> >>>>>>> >>>>>>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>>>>>> I'm kinda tired of mistyping VM options and figuring it out >>>>>>>> "mentally"...let machines do it then. >>>>>>>> >>>>>>>> changeset: >>>>>>>> Currently, when we mistype VM options you will get the warning as >>>>>>>> following >>>>>>>> >>>>>>>> $java -XX:+UseParalelGC -version >>>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>>> >>>>>>>> I think we can do one step further to interpret the user's intent >>>>>>>> and suggest the correct VM options. Then i start to imagine >>>>>>>> that we >>>>>>>> have something like this >>>>>>>> >>>>>>>> $java -XX:+UseParalelGC -version >>>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>>> Did you mean 'UseParallelGC'? >>>>>>>> >>>>>>>> Please refer to the wikipedia >>>>>>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>>>>>> >>>>>>>> to get an idea of obtaining string similarity. This new feature is >>>>>>>> based on this theory. >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>>>>>> >>>>>>>> Please try out this patch and see if it meets some need. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Tao >> > From tao.mao at oracle.com Thu Jun 27 09:41:41 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 27 Jun 2013 09:41:41 -0700 Subject: Request for review: 8017611: Auto corrector for mistyped vm options In-Reply-To: <51CC345B.6010205@oracle.com> References: <51C9D712.1050105@oracle.com> <51CB5AE3.7080205@oracle.com> <51CB6112.3050207@oracle.com> <51CB66B0.4030004@oracle.com> <51CB6AE8.2010502@oracle.com> <51CB7B0C.4050203@oracle.com> <51CC345B.6010205@oracle.com> Message-ID: <51CC6B45.4080508@oracle.com> The sdiff problem is that "line 266" has a very long macro. Scroll right and you will see everything :) Thank you for review. Tao On 6/27/13 5:47 AM, Dmitry Samersoff wrote: > Looks good for me. > > PS: Something bad happens with webrev - sdiffs is not generated > correctly (other diffs are fine). > > > On 2013-06-27 03:36, Tao Mao wrote: >> new webrev: >> http://cr.openjdk.java.net/~tamao/8017611/webrev.02/ >> >> Suggestions are taken from Harold and Vladimir. >> >> Thanks. >> Tao >> >> On 6/26/13 3:27 PM, Vladimir Kozlov wrote: >>> Tao, >>> >>> I would like to see it also and additional changes could be very simple: >>> >>> + jio_fprintf(defaultStream::error_stream(), >>> + "Did you mean '%s%s'?\n", fuzzy_matched->name, >>> (fuzzy_matched->is_bool() ? "" : "=")); >>> >>> so it would always print '=' for assignable flags. May be also '=X' >>> instead of simple '=': >>> >>> Did you mean 'ObjectAlignmentInBytes=X'? >>> >>> Thanks, >>> Vladimir >>> >>> On 6/26/13 3:09 PM, Tao Mao wrote: >>>> Hi Harold, >>>> >>>> This CR only deals with correcting VM option *names*. >>>> >>>> If this case needs to be resolved, it would be better to create another >>>> CR. See how many outcomes you'll get when you try out "~!@#$%^&*()_+" to >>>> replace "=" here. >>>> >>>> Thanks. >>>> Tao >>>> >>>> On 6/26/13 2:45 PM, harold seigel wrote: >>>>> Hi Tao, >>>>> >>>>> This is a big help. >>>>> >>>>> In a case like this: >>>>> >>>>> % $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes:16 -version >>>>> Unrecognized VM option 'ObjectAlignmentInBytes:16' >>>>> >>>>> >>>>> would it ask you: Did you mean ObjectAlignmentInBytes*=* ? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 6/26/2013 5:19 PM, Tao Mao wrote: >>>>>> new webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.01/ >>>>>> >>>>>> diff from the last webrev: >>>>>> (1) put more restrictive type check when passing strings. >>>>>> (2) move VMOptionsFuzzyMatchSimilarity to be a local constant. >>>>>> (3) simplify routine str_similar() >>>>>> (4) add jtreg test >>>>>> >>>>>> Suggestions are taken from Dmitry, Bengt, Vladimir and Christian. >>>>>> Thank you all. >>>>>> >>>>>> Tao >>>>>> >>>>>> >>>>>> On 6/25/13 10:44 AM, Tao Mao wrote: >>>>>>> I'm kinda tired of mistyping VM options and figuring it out >>>>>>> "mentally"...let machines do it then. >>>>>>> >>>>>>> changeset: >>>>>>> Currently, when we mistype VM options you will get the warning as >>>>>>> following >>>>>>> >>>>>>> $java -XX:+UseParalelGC -version >>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>> >>>>>>> I think we can do one step further to interpret the user's intent >>>>>>> and suggest the correct VM options. Then i start to imagine that we >>>>>>> have something like this >>>>>>> >>>>>>> $java -XX:+UseParalelGC -version >>>>>>> Unrecognized VM option 'UseParalelGC' >>>>>>> Did you mean 'UseParallelGC'? >>>>>>> >>>>>>> Please refer to the wikipedia >>>>>>> http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient >>>>>>> to get an idea of obtaining string similarity. This new feature is >>>>>>> based on this theory. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~tamao/8017611/webrev.00/ >>>>>>> >>>>>>> Please try out this patch and see if it meets some need. >>>>>>> >>>>>>> Thanks. >>>>>>> Tao > From vladimir.kozlov at oracle.com Thu Jun 27 14:27:40 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 27 Jun 2013 21:27:40 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130627212757.AAC2F485E6@hg.openjdk.java.net> Changeset: 7875ea94bea5 Author: goetz Date: 2013-06-24 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7875ea94bea5 8017308: Remove unused breakpoint relocation type Summary: remove unused breakpoint relocation type Reviewed-by: kvn ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: cc63bcb47cce Author: twisti Date: 2013-06-24 17:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cc63bcb47cce 8017538: Clang support broke slowdebug build for i586 Reviewed-by: kvn ! make/linux/makefiles/gcc.make Changeset: a023da4ffc15 Author: twisti Date: 2013-06-24 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a023da4ffc15 Merge Changeset: 3aa636f2a743 Author: adlertz Date: 2013-06-25 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3aa636f2a743 8017243: 8001345 is incomplete Summary: Replaces unused decodeN at MemBarAcquire with its corresponding loadN if loadN is used at more than one place. Reviewed-by: kvn, twisti ! src/share/vm/opto/memnode.cpp Changeset: 9347cae673f0 Author: adlertz Date: 2013-06-26 00:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9347cae673f0 8017510: Add a regression test for 8005956 Summary: Regression test for 8005956 Reviewed-by: kvn, twisti + test/compiler/8005956/PolynomialRoot.java Changeset: 6a0ead6dc6db Author: goetz Date: 2013-06-24 16:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6a0ead6dc6db 8017531: 8010460 changes broke bytecodeInterpreter.cpp Summary: Replace _indy by _jsr292 and also fix VERIFY_OOP macros. Reviewed-by: kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: be0600ec1102 Author: kvn Date: 2013-06-27 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be0600ec1102 Merge From vladimir.kozlov at oracle.com Thu Jun 27 15:06:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Jun 2013 15:06:42 -0700 Subject: RFR(M): 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking In-Reply-To: <51CC2DAF.4050102@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFEE181@DEWDFEMB12A.global.corp.sap> <51CB7A9A.9010307@oracle.com> <51CC2DAF.4050102@oracle.com> Message-ID: <51CCB772.4010908@oracle.com> David, Do you insist on moving cppInterpreter files into separate directory? If yes, we need to do that in our main sources to avoid merges nightmare. And I will do the move. Thanks, Vladimir On 6/27/13 5:18 AM, David Holmes wrote: > Vladimir, > > On 27/06/2013 9:34 AM, Vladimir Kozlov wrote: >> Hi Goetz, >> >> On 6/26/13 7:30 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> To use biased locking in our PPC64 VM,we fixed the biased locking >>> implementation >>> in the cppInterpreter. We also added BiasedLockingStatistic support. >> >> Oracle does not use cppInterpreter and no building and testing are done. >> So we trust you to do testing of these changes. >> I glanced on these changes and they look fine to me. >> >> One suggestion I heard from David H. is to move cppInterpreter related >> files (all 6 of them) from interpreter/ directory to separate directory. >> So we can see when changes does not affect our shared code. > > It is a general source of confusion to new hotspot engineers that there > are actually two interpreters in one directory and that one is not used > by the historical primary ports. It also isn't obvious that > bytecodeInterpreter.cpp pertains to the cppInterpreter. > >>> We need an additional ordering operation in revoke_bias() when writing >>> the mark. >> >> Why you need ordering only for locked objects in this code? And why here >> at all? This code is executed at safepoint. > > There is one occurrence that is not executed at a safepoint - see > BiasedLocking::Condition BiasedLocking::revoke_and_rebias. Though it > seems to be operating only on current thread in that case. > > The use of release_set_mark seems consistent with other uses in > synchronizer.cpp. > > David > ----- > >> thanks, >> Vladimir >> >>> The change enables biased locking for ppc64 per default. >>> http://cr.openjdk.java.net/~goetz/webrevs/8017317-lock/ >>> >>> Please review and test this change. >>> >>> Best regards, >>> Goetz >>> From vladimir.kozlov at oracle.com Thu Jun 27 16:59:39 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 27 Jun 2013 23:59:39 +0000 Subject: hg: hsx/hsx24/hotspot: 8015441: runThese crashed with assert(opcode == Op_ConP || opcode == Op_ThreadLocal || opcode == Op_CastX2P ..) failed: sanity Message-ID: <20130627235946.4D019485EE@hg.openjdk.java.net> Changeset: ad5bb04f36f5 Author: kvn Date: 2013-05-31 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ad5bb04f36f5 8015441: runThese crashed with assert(opcode == Op_ConP || opcode == Op_ThreadLocal || opcode == Op_CastX2P ..) failed: sanity Summary: Relax the assert to accept any raw ptr types. Reviewed-by: roland ! src/share/vm/opto/escape.cpp From coleen.phillimore at oracle.com Thu Jun 27 18:14:41 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 27 Jun 2013 21:14:41 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51C8B428.3090507@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> <51C89367.3080708@oracle.com> <51C8B428.3090507@oracle.com> Message-ID: <51CCE381.9010503@oracle.com> Hi, I have made a few changes to this changeset. I reverted the special case for application class loader until we have more tuning information to decide how large this metaspace should be. I also fixed the check in should_expand so that if you specify MaxMetaspaceSize, it compares the MaxMetaspaceSize to (reserved for data space + used for class space). So the test in the bug report runs with the smaller sizes for MaxMetaspaceSize and also for smaller ClassMetaspaceSize without hitting OOM for either sort of space. Hope the comment there is clear. http://cr.openjdk.java.net/~coleenp/8015391_2/ Reran nsk quick testlist and some jtreg tests. Please (re)review. Thanks, Coleen On 6/24/2013 5:03 PM, Coleen Phillimore wrote: > > On 06/24/2013 02:43 PM, Jon Masamitsu wrote: >> >> On 6/24/13 11:23 AM, Coleen Phillimore wrote: >>> >>> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >>>> >>>> >>>>> 2673 size_t specialized_count = 0, small_count = 0, medium_count >>>>> = 0, large_count = 0; >>>>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, >>>>> cls_medium_count = 0, cls_large_count = 0; >>>> >>>> Not introduced by your change but >>>> >>>> humongous_count instead of large_count >>>> and >>>> cls_humongous_count instead of cls_large_count >>>> >>>> would be more consistent. >>> >>> Yes, it is. I changed it. >>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >>>> >>>> >>>> I'd suggest adding Metaspace::AppClassMetaspaceType >>>>> 385 } else if >>>>> (SystemDictionary::is_app_class_loader(class_loader())) { >>>>> 386 if (TraceClassLoaderData && Verbose && class_loader() >>>>> != NULL) { >>>>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class loader"); >>>>> 388 } >>>>> 389 set_metaspace(new Metaspace(_metaspace_lock, >>>>> Metaspace::BootMetaspaceType)); >>>> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >>>> obvious to me >>>> that we should always be reserving the same amount of space for >>>> the AppClassLoader >>>> as the BootClassLoader. The same default is OK with me. >>> >>> Hmm. Ok. I don't like adding new flags, so can I add an >>> AppMetaspaceType and give it the same initial size as >>> BootMetaspaceSize until proven that it doesn't need to be the same >>> size. >> >> With the BootClassLoader the space for the initial Metaspace is >> committed >> when the first system class is loaded. The same would be true for any >> Java application (all have some type of AppLoader, right)? We know >> we're >> going to use the space committed for the BootClassLoader Metaspace. Are >> we going to get yelled at for committing 4m and not using it. >>> >>> I suppose adding an AppMetaspaceInitialSize flag will give me more >>> to talk about at the Permgen Elimination JavaOne talk though (but >>> I'd still rather not). >> >> When you have 100000000000000000 flags, who's going to >> notice the 100000000000000001-st :-) > > Okay, you convinced me to revert this part of the change. It wasn't > necessary to make this stress test finish and there hasn't been very > much tuning for "normal" application classes, just a suspicion of mine. > > Committing an extra 4m might be bad for embedded platforms. > > Thanks, > Coleen > >> >> Jon >>> >>> Coleen >>> >>>> >>>> Rest looks good. >>>> >>>> Jon >>>> >>>> >>>> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>>>> Summary: Allocate medium chunks for class metaspace when class >>>>> loader has lots of classes >>>>> >>>>> I originally made class metaspace keep small chunks and not start >>>>> allocating from medium chunks, because I thought with only Klass >>>>> objects, small chunks is enough. This test has a large set of >>>>> class loaders who have a lot of classes, so allocated thousands of >>>>> small chunks each. Class loaders with that many classes should >>>>> start allocating from medium chunks, for class metaspace. >>>>> >>>>> I also increased the ClassMediumChunk size to 4k and measured a >>>>> lot less fragmentation waste than 1K or 2K for this test. Lastly, >>>>> the AppClassLoader instance should have as large of an initial >>>>> metaspace as the bootclass loader. >>>>> >>>>> Tested with vm.quick.testlist and the failing test. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>> >> > From john.coomes at oracle.com Thu Jun 27 20:33:16 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jun 2013 03:33:16 +0000 Subject: hg: hsx/hotspot-main/corba: 14 new changesets Message-ID: <20130628033327.7122548608@hg.openjdk.java.net> Changeset: 5845df371e25 Author: alanb Date: 2013-06-10 17:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/5845df371e25 8016218: Warnings building corba repo due to missing hashCode methods Reviewed-by: chegar, coffeys, dfuchs ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java ! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java Changeset: 0fac0a9d9545 Author: lana Date: 2013-06-16 22:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0fac0a9d9545 Merge Changeset: 39d15bbb5741 Author: coffeys Date: 2013-04-08 23:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/39d15bbb5741 8001032: Restrict object access Summary: Restrict object access; fix reviewed also by Alexander Fomin Reviewed-by: alanb, ahgross ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! src/share/classes/com/sun/corba/se/impl/activation/ServerManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/RequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBDataParserImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java - src/share/classes/com/sun/corba/se/impl/orbutil/ORBClassLoader.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java ! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/LocateReplyMessage_1_2.java ! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/MessageBase.java ! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/ReplyMessage_1_0.java ! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/ReplyMessage_1_1.java ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java ! src/share/classes/com/sun/corba/se/spi/orb/OperationFactory.java ! src/share/classes/sun/corba/JavaCorbaAccess.java Changeset: 978818df41b9 Author: chegar Date: 2013-04-24 10:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/978818df41b9 Merge Changeset: 68d407e4d204 Author: chegar Date: 2013-04-28 08:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/68d407e4d204 Merge Changeset: 80161c61aa68 Author: coffeys Date: 2013-04-30 11:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/80161c61aa68 8000642: Better handling of objects for transportation Reviewed-by: alanb, mchung, skoivu ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/corba/TypeCodeImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/IDLJavaSerializationOutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeOutputStream.java ! src/share/classes/com/sun/corba/se/impl/interceptors/CDREncapsCodec.java ! src/share/classes/com/sun/corba/se/impl/interceptors/RequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java ! src/share/classes/com/sun/corba/se/impl/ior/IORImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/TaggedComponentFactoryFinderImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileTemplateImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBSingleton.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/CorbaContactInfoBase.java ! src/share/classes/com/sun/corba/se/impl/transport/SharedCDRContactInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelAcceptorImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/share/classes/com/sun/corba/se/spi/ior/TaggedComponentBase.java ! src/share/classes/com/sun/corba/se/spi/servicecontext/ServiceContext.java ! src/share/classes/org/omg/CORBA_2_3/portable/OutputStream.java + src/share/classes/sun/corba/OutputStreamFactory.java Changeset: 4fe1edbec7bc Author: chegar Date: 2013-05-08 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/4fe1edbec7bc Merge Changeset: e9c924d3475c Author: chegar Date: 2013-05-16 11:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e9c924d3475c Merge Changeset: 216cb38dce0a Author: chegar Date: 2013-05-23 12:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/216cb38dce0a Merge Changeset: 25e68d232c20 Author: chegar Date: 2013-05-31 10:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/25e68d232c20 Merge Changeset: c1f80e733eb0 Author: chegar Date: 2013-06-17 11:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/c1f80e733eb0 Merge ! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java Changeset: d406edd4f6fd Author: mfang Date: 2013-06-18 20:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d406edd4f6fd 8015657: jdk8 l10n resource file translation update 3 Reviewed-by: yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp Changeset: 3357c2776431 Author: lana Date: 2013-06-24 14:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/3357c2776431 Merge Changeset: 469995a8e974 Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/469995a8e974 Added tag jdk8-b96 for changeset 3357c2776431 ! .hgtags From john.coomes at oracle.com Thu Jun 27 20:33:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jun 2013 03:33:10 +0000 Subject: hg: hsx/hotspot-main: 7 new changesets Message-ID: <20130628033310.C232348607@hg.openjdk.java.net> Changeset: f8770fe60d53 Author: mduigou Date: 2013-06-17 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f8770fe60d53 8016572: Pass CONCURRENCY=$(JOBS) to test/Makefile Reviewed-by: alanb, erikj ! common/makefiles/Main.gmk Changeset: b9587f41fd55 Author: smarks Date: 2013-06-18 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b9587f41fd55 8016780: README-builds.html misses crucial requirement on bootstrap JDK Reviewed-by: dholmes, chegar ! README-builds.html Changeset: d72e765a9fbe Author: lana Date: 2013-06-19 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d72e765a9fbe Merge Changeset: f1010ef2f451 Author: lana Date: 2013-06-24 14:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f1010ef2f451 Merge Changeset: ebcd79fc658d Author: erikj Date: 2013-06-25 09:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ebcd79fc658d 8012564: The SOURCE value in release file of JDK 8 doesn't contain valid changesets for some OS since b74 Reviewed-by: alanb, tbell ! common/makefiles/Main.gmk Changeset: c156084add48 Author: katleman Date: 2013-06-25 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c156084add48 Merge ! common/makefiles/Main.gmk Changeset: 4c363b94ea2a Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4c363b94ea2a Added tag jdk8-b96 for changeset c156084add48 ! .hgtags From john.coomes at oracle.com Thu Jun 27 20:33:36 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jun 2013 03:33:36 +0000 Subject: hg: hsx/hotspot-main/jaxp: 20 new changesets Message-ID: <20130628033426.F27D148609@hg.openjdk.java.net> Changeset: 7d14fea1e893 Author: dmeetry Date: 2013-06-06 20:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/7d14fea1e893 8009579: Xpathexception does not honor initcause() Reviewed-by: alanb, dholmes, joehw Contributed-by: aleksej.efimov at oracle.com ! src/javax/xml/xpath/XPathException.java Changeset: e93beba07830 Author: dfuchs Date: 2013-06-06 20:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e93beba07830 8013434: Xalan and Xerces internal ObjectFactory need rework Summary: With this changeset, DTMManager and XSLTCDTMManager will always use their own default implementation. Reviewed-by: joehw, alanb - src/com/sun/org/apache/xalan/META-INF/services/javax.xml.transform.TransformerFactory - src/com/sun/org/apache/xalan/META-INF/services/javax.xml.xpath.XPathFactory - src/com/sun/org/apache/xalan/META-INF/services/org.apache.xml.dtm.DTMManager ! src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java ! src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Transform.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/XSLTCDTMManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java ! src/com/sun/org/apache/xml/internal/dtm/DTMManager.java ! src/com/sun/org/apache/xpath/internal/XPathContext.java Changeset: c2957e596bee Author: joehw Date: 2013-06-06 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/c2957e596bee 8015016: Improve JAXP 1.5 error message Reviewed-by: lancea ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties Changeset: 5c84d4a878f1 Author: joehw Date: 2013-06-10 14:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/5c84d4a878f1 8016153: Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. Reviewed-by: lancea, dfuchs ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 659828443145 Author: coffeys Date: 2013-06-14 15:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/659828443145 8015978: Incorrect transformation of XPath expression "string(-0)" Reviewed-by: darcy, joehw Contributed-by: aleksej.efimov at oracle.com ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java Changeset: 2707f600a096 Author: robm Date: 2013-06-15 09:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2707f600a096 8016701: JAXP Build failure Reviewed-by: darcy, wetmore, alanb, chegar ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java Changeset: 0142ef23f1b4 Author: lana Date: 2013-06-16 22:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0142ef23f1b4 Merge Changeset: 09d55894844d Author: joehw Date: 2013-06-17 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/09d55894844d 8016133: Regression: diff. behavior with user-defined SAXParser Reviewed-by: chegar, dfuchs ! src/org/xml/sax/helpers/XMLReaderFactory.java Changeset: f14f72174f00 Author: chegar Date: 2013-04-24 10:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f14f72174f00 Merge Changeset: b225607e056b Author: chegar Date: 2013-04-28 08:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b225607e056b Merge Changeset: 5b7a22859380 Author: chegar Date: 2013-05-08 10:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/5b7a22859380 Merge Changeset: 96223058c269 Author: chegar Date: 2013-05-16 11:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/96223058c269 Merge Changeset: ed115f7cc6d0 Author: chegar Date: 2013-05-23 12:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ed115f7cc6d0 Merge Changeset: 231034c73ed5 Author: chegar Date: 2013-05-31 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/231034c73ed5 Merge Changeset: f8f257062d53 Author: chegar Date: 2013-06-10 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f8f257062d53 Merge - src/com/sun/org/apache/xalan/META-INF/services/javax.xml.transform.TransformerFactory - src/com/sun/org/apache/xalan/META-INF/services/javax.xml.xpath.XPathFactory - src/com/sun/org/apache/xalan/META-INF/services/org.apache.xml.dtm.DTMManager - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java Changeset: ec38586b8bf3 Author: chegar Date: 2013-06-17 11:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ec38586b8bf3 Merge Changeset: 1c5e3ae28f81 Author: chegar Date: 2013-06-18 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/1c5e3ae28f81 Merge Changeset: 21d9cbbb7bf3 Author: mfang Date: 2013-06-18 22:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/21d9cbbb7bf3 8016824: jdk8 l10n resource file translation update 3 - jaxp Reviewed-by: joehw ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_de.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_es.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_it.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ko.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_sv.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_TW.properties Changeset: 6121efd29923 Author: lana Date: 2013-06-24 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/6121efd29923 Merge Changeset: 403f882ecc94 Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/403f882ecc94 Added tag jdk8-b96 for changeset 6121efd29923 ! .hgtags From john.coomes at oracle.com Thu Jun 27 20:34:33 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jun 2013 03:34:33 +0000 Subject: hg: hsx/hotspot-main/jaxws: 4 new changesets Message-ID: <20130628033445.C37A04860A@hg.openjdk.java.net> Changeset: 8f2986ff0235 Author: mkos Date: 2013-06-12 14:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/8f2986ff0235 8013021: Rebase 8005432 & 8003542 against the latest jdk8/jaxws 8003542: Improve processing of MTOM attachments 8005432: Update access to JAX-WS Reviewed-by: mullan ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingModeFeature.java ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java ! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BaseDistributedPropertySet.java ! src/share/jaxws_classes/com/oracle/webservices/internal/impl/encoding/StreamDecoderImpl.java ! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/package-info.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/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/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/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/CommonResourceBundle.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/Decoder.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/BASE64EncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/BooleanEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/BuiltInEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/FloatEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/HexadecimalEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentParser.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/resources/ResourceBundle.properties ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/sax/AttributesHolder.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentParser.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentParser.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/stax/events/StartElementEvent.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/stax/factory/StAXOutputFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/tools/SAXEventSerializer.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/tools/TransformInputOutput.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DataHead.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MemoryData.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/TempFiles.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/DatabindingConfig.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SAAJFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Fiber.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubeCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SEIPortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/DispatchImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SyncMethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingFactoryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/DispatchMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/JAXBWrapperAccessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/javax/xml/soap/FactoryFinder.java ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java ! src/share/jaxws_classes/javax/xml/soap/SAAJMetaFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConnectionFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFactory.java Changeset: c4191a46e3eb Author: lana Date: 2013-06-16 22:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c4191a46e3eb Merge Changeset: 690d34b326bc Author: lana Date: 2013-06-24 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/690d34b326bc Merge Changeset: dcde7f049111 Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/dcde7f049111 Added tag jdk8-b96 for changeset 690d34b326bc ! .hgtags From john.coomes at oracle.com Thu Jun 27 20:39:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jun 2013 03:39:21 +0000 Subject: hg: hsx/hotspot-main/jdk: 188 new changesets Message-ID: <20130628042250.327A44860B@hg.openjdk.java.net> Changeset: 616a73e97b38 Author: bae Date: 2013-06-06 13:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/616a73e97b38 8013430: REGRESSION: closed/java/awt/color/ICC_Profile/LoadProfileTest/LoadProfileTest.java fails with java.io.StreamCorruptedException: invalid type code: EE since 8b87 Reviewed-by: prr, vadim ! src/share/classes/java/awt/color/ICC_Profile.java + src/share/classes/sun/java2d/cmm/ProfileDataVerifier.java Changeset: 917dd642f934 Author: bae Date: 2013-06-07 14:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/917dd642f934 6830714: cmm test failures with OpenJDK Reviewed-by: prr ! test/sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvTest.java Changeset: 1431488fb0f9 Author: jgodinez Date: 2013-06-07 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1431488fb0f9 8013810: PrintServiceLookup.lookupPrintServices() does not return consistent result Reviewed-by: prr, jgodinez Contributed-by: patrick at reini.net ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java + test/javax/print/PrintServiceLookup/GetPrintServices.java Changeset: f67db3d2f406 Author: prr Date: 2013-06-13 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f67db3d2f406 8016485: Windows native print dialog does not reflect default printer settings Reviewed-by: jgodinez, jchen ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/print/Win32PrintService.java ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp Changeset: 82927bc76ea5 Author: lana Date: 2013-06-14 11:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/82927bc76ea5 Merge - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java Changeset: c636942a28ef Author: prr Date: 2013-06-17 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c636942a28ef 8015334: Memory leak when kerning is used on Windows. Reviewed-by: srl, bae ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KernTable.h ! src/share/native/sun/font/layout/LayoutEngine.cpp + test/java/awt/font/TextLayout/KerningLeak.java Changeset: e3d5df92f4ff Author: lana Date: 2013-06-19 17:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e3d5df92f4ff Merge Changeset: deb8752684e3 Author: kshefov Date: 2013-06-06 17:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/deb8752684e3 8015976: OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions Reviewed-by: serb, anthony ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java ! test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java Changeset: cfd3f8bfb96c Author: kshefov Date: 2013-06-06 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cfd3f8bfb96c 7109977: [macosx] MixingInHwPanel.java test fails on Mac trying to click in the reserved corner Reviewed-by: serb, anthony ! test/java/awt/Mixing/MixingInHwPanel.java Changeset: cb7f711e1752 Author: dmarkov Date: 2013-06-06 17:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb7f711e1752 8015853: java.lang.ArrayIndexOutOfBoundsException when running SwingSet2 demo Reviewed-by: alexp, serb ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/View/8015853/bug8015853.java + test/javax/swing/text/View/8015853/bug8015853.txt Changeset: 2d5bb70458b6 Author: kshefov Date: 2013-06-10 16:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2d5bb70458b6 7105030: [TEST_BUG] [macosx] The tests never finishes Reviewed-by: alexsch, serb + test/javax/swing/JMenu/4692443/bug4692443.java Changeset: d14523c12f20 Author: kshefov Date: 2013-06-11 14:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d14523c12f20 8012569: TEST_BUG: java/awt/GraphicsDevice/CheckDisplayModes.java fails Reviewed-by: anthony, serb ! test/java/awt/GraphicsDevice/CheckDisplayModes.java Changeset: 9ab7973d5907 Author: kshefov Date: 2013-06-11 14:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9ab7973d5907 7184908: TEST_BUG: [macosx] closed/com/sun/java/swing/plaf/gtk/4928019/bug4928019.java fails Reviewed-by: alexsch, serb + test/com/sun/java/swing/plaf/gtk/4928019/bug4928019.java Changeset: 59dc1385127f Author: malenkov Date: 2013-06-11 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/59dc1385127f 8015336: BasicComboBoxEditor throws NullPointerException Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java + test/javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java Changeset: 7bba0147ab3d Author: alexsch Date: 2013-06-11 16:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bba0147ab3d 8009984: [parfait] Buffer overrun at jdk/src/macosx/native/com/apple/laf/AquaFileView.m Reviewed-by: serb, art ! src/macosx/native/com/apple/laf/AquaFileView.m Changeset: 33fc8a062f90 Author: ant Date: 2013-06-12 16:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/33fc8a062f90 8015454: java/awt/Focus/TypeAhead/TestFocusFreeze.java hangs with jdk8 since b56 Reviewed-by: anthony ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java Changeset: a7d943998bd3 Author: pchelko Date: 2013-06-13 11:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7d943998bd3 8013468: [macosx] Cursor does not update properly when in fullscreen mode on Mac Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java Changeset: 6e5824a42c49 Author: alitvinov Date: 2013-06-13 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6e5824a42c49 6847588: AWT test fails Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java Changeset: d57fa4e45100 Author: ant Date: 2013-06-14 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d57fa4e45100 8014821: Regression: Focus issues with Oracle WebCenter Capture applet Reviewed-by: leonidr ! src/windows/native/sun/windows/awt_Frame.cpp Changeset: 3a157a38f9b3 Author: lana Date: 2013-06-14 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3a157a38f9b3 Merge - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java Changeset: a0202d94844a Author: malenkov Date: 2013-06-17 18:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a0202d94844a 8013571: TreeModelEvent doesn't accept "null" for root as Javadoc specifies. Reviewed-by: alexsch ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JTree/8013571/Test8013571.java Changeset: 6a3a2cb3ca6a Author: malenkov Date: 2013-06-19 14:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a3a2cb3ca6a 8013442: No file filter selected in file type combo box when using JFileChooser Reviewed-by: alexsch ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/8013442/Test8013442.java Changeset: e8000751a585 Author: pchelko Date: 2013-06-19 17:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8000751a585 8005661: [parfait] Possible buffer overrun in jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c 8005695: [parfait] Format string argument mismatch in jdk/src/solaris/native/sun/xawt/XToolkit.c 8005752: [parfait] False positive function call mismatch at jdk/src/solaris/native/sun/xawt/XWindow.c Reviewed-by: art, serb ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/xawt/XToolkit.c Changeset: a117785457f6 Author: lana Date: 2013-06-19 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a117785457f6 Merge Changeset: 571e5f452640 Author: dholmes Date: 2013-06-06 05:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/571e5f452640 8015470: Remove redundant calls of toString() on String objects Reviewed-by: dholmes, alanb Contributed-by: Otavio Goncalves ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/tools/java/MemberDefinition.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java Changeset: c4480e0d9f53 Author: coffeys Date: 2013-06-06 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c4480e0d9f53 8000450: Restrict access to com/sun/corba/se/impl package Reviewed-by: alanb, chegar, lancea ! 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: 37aa82c52317 Author: emc Date: 2013-06-06 09:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37aa82c52317 8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK Summary: setProtectionDomain0 and JVM_SetProtectionDomain are unused since at least 1.5. This is the JDK side of a changeset to remove it. Reviewed-by: alanb ! src/share/classes/java/lang/Class.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/Class.c Changeset: e6d2c605930c Author: dmeetry Date: 2013-06-06 20:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6d2c605930c 8009579: Xpathexception does not honor initcause() Reviewed-by: alanb, dholmes, joehw Contributed-by: aleksej.efimov at oracle.com + test/javax/xml/jaxp/XPath/8009579/XPathExceptionInitCause.java Changeset: 69d566198fe4 Author: henryjen Date: 2013-06-05 15:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69d566198fe4 8015522: CharSequence.codePoints can be faster Reviewed-by: martin, psandoz, alanb Contributed-by: henry.jen at oracle.com ! src/share/classes/java/lang/CharSequence.java Changeset: 26922bad9c08 Author: mduigou Date: 2013-06-06 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/26922bad9c08 Merge Changeset: 986793409b2b Author: bpb Date: 2013-06-05 21:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/986793409b2b 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Summary: Performance improvements for double/float -> String and decimal/hex String -> double/float conversions. Reviewed-by: martin, iris Contributed-by: Sergey Kuksenko , Brian Burkhalter , Dmitry Nadezhin , Olivier Lagneau ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/util/Formatter.java - src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java + test/sun/misc/FloatingDecimal/OldFDBigIntForTest.java + test/sun/misc/FloatingDecimal/OldFloatingDecimalForTest.java + test/sun/misc/FloatingDecimal/TestFDBigInteger.java + test/sun/misc/FloatingDecimal/TestFloatingDecimal.java Changeset: d28f802ce914 Author: robm Date: 2013-06-06 22:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d28f802ce914 8016063: getFinalAttributes should use FindClose Reviewed-by: alanb ! src/windows/native/java/io/WinNTFileSystem_md.c Changeset: f5f54e493a64 Author: bpb Date: 2013-06-06 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f5f54e493a64 8016117: New sun.misc.FDBigInteger class as part of 7032154 Reviewed-by: martin, iris Contributed-by: Sergey Kuksenko , Brian Burkhalter , Dmitry Nadezhin , Olivier Lagneau + src/share/classes/sun/misc/FDBigInteger.java Changeset: 6975eea0b458 Author: okutsu Date: 2013-06-07 17:07 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6975eea0b458 7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7177315.java Changeset: a286ed046116 Author: okutsu Date: 2013-06-07 17:37 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a286ed046116 7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8 Reviewed-by: peytoia ! test/java/text/Format/DateFormat/WeekDateTest.java Changeset: 8b65dfe8f509 Author: khazra Date: 2013-06-07 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b65dfe8f509 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER Summary: Return false for null arguments in ACCEPT_ORIGINAL_SERVER#shouldAccept() Reviewed-by: chegar ! src/share/classes/java/net/CookiePolicy.java ! test/java/net/CookieHandler/CookieManagerTest.java Changeset: e2333bd8514a Author: lancea Date: 2013-06-07 14:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e2333bd8514a 8016101: Fix typo in SerialRef and missing @param in SerialStruct Reviewed-by: darcy ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: aed2ad905da6 Author: sherman Date: 2013-06-07 13:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aed2ad905da6 8015728: (zipfs) demo/zipfs/basic.sh failing Summary: to return the correct loc entry size from wirteLOC(); Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: f18337edd201 Author: coleenp Date: 2013-06-07 22:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f18337edd201 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted Summary: The code for this test is fixed now and integrated to TL repo and it passes now. Reviewed-by: alanb ! test/java/lang/instrument/MakeJAR4.sh ! test/java/lang/instrument/RetransformBigClass.sh Changeset: c351a48c091d Author: ksrini Date: 2013-06-08 09:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c351a48c091d 8016209: TEST_BUG: non-compliant jmc in the bin directory hangs testing Reviewed-by: alanb, darcy, chegar ! test/tools/launcher/VersionCheck.java Changeset: 3990fcab2cd9 Author: psandoz Date: 2013-06-10 11:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3990fcab2cd9 8015492: Remove DoubleStream.range methods Reviewed-by: alanb ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java Changeset: 7322e8ad7c01 Author: psandoz Date: 2013-06-10 12:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7322e8ad7c01 8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream Reviewed-by: alanb ! 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 ! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java Changeset: 9c462579b624 Author: psandoz Date: 2013-06-10 12:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c462579b624 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator Reviewed-by: chegar ! src/share/classes/java/util/Spliterators.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/SpinedBuffer.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java ! test/java/util/stream/bootlib/java/util/stream/TestData.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java Changeset: d790064850a7 Author: alanb Date: 2013-06-10 12:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d790064850a7 8016217: More javadoc warnings Reviewed-by: lancea, chegar, psandoz ! src/share/classes/java/io/BufferedInputStream.java ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/PipedInputStream.java ! src/share/classes/java/io/PipedReader.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/io/StringReader.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Comparable.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/management/MemoryUsage.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/CookiePolicy.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/cert/CertPathValidatorException.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/X509Extension.java ! src/share/classes/java/security/spec/EllipticCurve.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/text/CharacterIterator.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/TimerTask.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/regex/MatchResult.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/stream/package-info.java ! src/share/classes/java/util/zip/DeflaterInputStream.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPInputStream.java ! src/share/classes/java/util/zip/GZIPOutputStream.java ! src/share/classes/java/util/zip/InflaterInputStream.java ! src/share/classes/java/util/zip/InflaterOutputStream.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/javax/crypto/spec/IvParameterSpec.java ! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java ! src/share/classes/javax/crypto/spec/SecretKeySpec.java ! src/share/classes/javax/naming/BinaryRefAddr.java ! src/share/classes/javax/naming/directory/Attribute.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/PagedResultsControl.java ! src/share/classes/javax/naming/ldap/SortControl.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLSessionContext.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslServer.java ! src/share/classes/javax/smartcardio/ResponseAPDU.java ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java Changeset: 4a66dd1d7eea Author: dxu Date: 2013-06-10 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4a66dd1d7eea 8013827: File.createTempFile hangs with temp file starting with 'com1.4' 8011950: java.io.File.createTempFile enters infinite loop when passed invalid data Reviewed-by: alanb ! src/share/classes/java/io/File.java ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/CreateNewFile.java ! test/java/io/File/NulFile.java + test/java/io/File/createTempFile/SpecialTempFile.java Changeset: 8d627f324c38 Author: psandoz Date: 2013-06-11 12:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d627f324c38 8015895: Int/LongStream.range/rangeClosed 8012986: Right-bias range spliterators for large ranges Reviewed-by: mduigou ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java ! test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java Changeset: 669be1677ab7 Author: alanb Date: 2013-06-11 11:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/669be1677ab7 7059085: Retire Thread.stop(Throwable) so that it throws UOE Reviewed-by: dholmes, chegar, forax, darcy, mduigou ! src/share/classes/java/lang/Thread.java + test/java/lang/Thread/StopThrowable.java Changeset: 1f33fd081860 Author: alanb Date: 2013-06-11 11:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1f33fd081860 8016311: Update j.u.c. tests to avoid using Thread.stop(Throwable) Reviewed-by: alanb Contributed-by: martinrb at google.com ! test/java/util/concurrent/Executors/PrivilegedCallables.java ! test/java/util/concurrent/FutureTask/Throw.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java Changeset: f1a1f65d2861 Author: alanb Date: 2013-06-11 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f1a1f65d2861 Merge Changeset: cadb0ef6e931 Author: naoto Date: 2013-06-11 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cadb0ef6e931 8015960: java/util/Locale/LocaleProviders.java failing again on Windows Reviewed-by: alanb ! test/java/util/Locale/LocaleProviders.java Changeset: 7f697d028937 Author: mduigou Date: 2013-06-11 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7f697d028937 8016213: Convert j2se NetBeans project to use top-level make targets Reviewed-by: chegar ! make/netbeans/common/shared.xml ! make/netbeans/j2se/build.xml Changeset: f56b5c243f7c Author: alanb Date: 2013-06-12 08:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f56b5c243f7c 8016370: javadoc warnings, unexpected

    mostly Reviewed-by: martin, jjg ! makefiles/scripts/genExceptions.sh ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteOrder.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/Channel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/Pipe.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/channels/Selector.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectionKey.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/java/nio/charset/CodingErrorAction.java ! src/share/classes/java/nio/charset/UnmappableCharacterException.java ! src/share/classes/java/nio/charset/spi/CharsetProvider.java Changeset: 6df79b7bae6f Author: alanb Date: 2013-06-12 09:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6df79b7bae6f 8016369: java/lang/instrument/RetransformBigClass.sh failing again Reviewed-by: sla, sergei ! test/java/lang/instrument/MakeJAR4.sh Changeset: c9f5a2fd7d3d Author: bchristi Date: 2013-06-12 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9f5a2fd7d3d 8010325: Remove hash32() method and hash32 int field from java.lang.String Reviewed-by: alanb, mduigou ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/WeakHashMap.java - src/share/classes/sun/misc/Hashing.java - test/sun/misc/Hashing.java Changeset: ce8fbca80bbc Author: henryjen Date: 2013-06-12 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ce8fbca80bbc 8016448: java/util/BitSet/BitSetStreamTest.java no longer compiles, missed by 8015895 Reviewed-by: mduigou ! test/java/util/BitSet/BitSetStreamTest.java Changeset: 021fdd093cd9 Author: weijun Date: 2013-06-13 09:59 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/021fdd093cd9 8014310: JAAS/Krb5LoginModule using des encytypes failure with NPE after JDK-8012679 Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/OneKDC.java + test/sun/security/krb5/auto/OnlyDesLogin.java Changeset: e9c5ad10fa4b Author: weijun Date: 2013-06-13 10:00 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e9c5ad10fa4b 8015274: TEST_BUG: Step2: After selecting 'View Warning Log', it is empty instead of FileNotFound. 8015276: TEST_BUG: The 'ptool.test' can't be saved in the 'tmp' folder. 8016158: Instruction is not clear on how to use keytool to create JKS store in case Reviewed-by: mullan ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.html ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.html ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.html ! test/sun/security/tools/policytool/i18n.sh Changeset: 3c7bab68cd2f Author: yhuang Date: 2013-06-12 23:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c7bab68cd2f 7040556: SimpleDateFormat.format Portuguese Month should not be capitalized Reviewed-by: okutsu ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a50394c44464 Author: psandoz Date: 2013-06-13 11:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a50394c44464 8016251: Balanced spliterator for SpinedBuffer Reviewed-by: mduigou Contributed-by: Brian Goetz , Peter Levart , Paul Sandoz ! 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/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java ! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java Changeset: f3609297a868 Author: igerasim Date: 2013-06-13 15:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3609297a868 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently Reviewed-by: chegar, dholmes ! test/java/lang/ThreadGroup/Suspend.java Changeset: ff83bd43e36a Author: khazra Date: 2013-06-13 11:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff83bd43e36a 8015421: NegativeArraySizeException occurs in ChunkedOutputStream() with Integer.MAX_VALUE Summary: Ensure integer overflow does not occur Reviewed-by: chegar ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java Changeset: 42f9ad39bf42 Author: khazra Date: 2013-06-13 17:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42f9ad39bf42 7169142: CookieHandler does not work with localhost Summary: Add .local to derived effective hostnames without dot Reviewed-by: chegar ! src/share/classes/java/net/CookieManager.java + test/java/net/CookieHandler/LocalHostCookie.java Changeset: f695f447f6b7 Author: jzavgren Date: 2013-06-14 09:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f695f447f6b7 8014307: Memory leak ... security/jgss/wrapper/GSSLibStub.c Summary: I modified the native procedure: Java_sun_security_jgss_wrapper_GSSLibStub_initContext() so that allocated memory is freed when errors occur. Reviewed-by: chegar, valeriep ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c Changeset: 45a3584bfacf Author: coffeys Date: 2013-06-14 15:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/45a3584bfacf 8015978: Incorrect transformation of XPath expression "string(-0)" Reviewed-by: darcy, joehw Contributed-by: aleksej.efimov at oracle.com + test/javax/xml/jaxp/XPath/8015978/XPathNegativeZero.java + test/javax/xml/jaxp/XPath/8015978/dummy.xml + test/javax/xml/jaxp/XPath/8015978/negativezero.xsl Changeset: bad604b15314 Author: lana Date: 2013-06-16 22:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bad604b15314 Merge - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties Changeset: adf70cb48ce0 Author: chegar Date: 2013-06-17 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/adf70cb48ce0 8016747: Replace deprecated PlatformLogger isLoggable(int) with isLoggable(Level) Reviewed-by: darcy ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AttributeValue.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/WaitDispatchSupport.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/util/Currency.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ScrollPaneWheelScroller.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XInputMethod.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWINProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: b0cfde1e70e9 Author: shade Date: 2013-06-17 16:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b0cfde1e70e9 8016236: Class.getGenericInterfaces performance improvement Summary: cache more reflective data and lookup results. Reviewed-by: alanb, plevart, psandoz, dl Contributed-by: Doug Lea
    , Aleksey Shipilev ! src/share/classes/java/lang/Class.java ! src/share/classes/sun/reflect/generics/repository/ClassRepository.java ! src/share/native/java/lang/Class.c Changeset: 2b63fda275a3 Author: twisti Date: 2013-06-17 16:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2b63fda275a3 7177472: JSR292: MethodType interning penalizes scalability Reviewed-by: twisti Contributed-by: Aleksey Shipilev ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 116050227ee9 Author: youdwei Date: 2013-06-17 17:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/116050227ee9 8014620: Signature.getAlgorithm return null in special case Reviewed-by: wetmore ! src/share/classes/java/security/Signature.java + test/java/security/Signature/SignatureGetAlgorithm.java Changeset: 989049977d04 Author: rfield Date: 2013-06-17 20:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/989049977d04 8015402: Lambda metafactory should not attempt to determine bridge methods Summary: paired with 8013789: Compiler should emit bridges in interfaces Reviewed-by: twisti ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java Changeset: 956b00d7d4ea Author: uta Date: 2013-06-18 17:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/956b00d7d4ea 8016046: (process) Strict validation of input should be security manager case only [win]. Reviewed-by: alanb, ahgross ! src/windows/classes/java/lang/ProcessImpl.java ! test/java/lang/Runtime/exec/ExecCommand.java Changeset: 3c36782f5129 Author: bae Date: 2013-02-27 12:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c36782f5129 8001034: Memory management improvements Reviewed-by: mschoene, prr, jgodinez ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.h ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c Changeset: b4a306969af5 Author: alanb Date: 2013-02-27 11:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4a306969af5 8004288: (fs) Files.probeContentType problems Reviewed-by: ahgross, sherman ! src/share/classes/java/nio/file/Files.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java Changeset: ecf85457671a Author: dmocek Date: 2013-03-04 14:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ecf85457671a 8000638: Improve deserialization Reviewed-by: smarks, hawtin, mchung ! src/share/classes/java/io/ObjectStreamClass.java Changeset: 1bd2a0bb583e Author: jbachorik Date: 2013-03-07 14:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1bd2a0bb583e 8008603: Improve provision of JMX providers Reviewed-by: alanb, dfuchs, jfdenise, skoivu ! src/share/classes/javax/management/remote/JMXConnectorFactory.java Changeset: 711d544b2319 Author: jbachorik Date: 2013-03-12 09:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/711d544b2319 8009038: Improve JMX notification support Summary: Disallowing access to mutable shared arrays Reviewed-by: dfuchs, mchung, skoivu ! src/share/classes/javax/management/StandardEmitterMBean.java Changeset: 363547f54176 Author: jbachorik Date: 2013-03-12 11:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/363547f54176 8009034: Improve resulting notifications in JMX Summary: Disallowing access to mutable shared arrays Reviewed-by: dfuchs, mchung, skoivu ! src/share/classes/javax/management/remote/NotificationResult.java Changeset: 9114ea4791ec Author: jbachorik Date: 2013-03-14 14:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9114ea4791ec 8008585: Better JMX data handling Reviewed-by: alanb, dfuchs, jfdenise, skoivu, sjiang ! src/share/classes/javax/management/remote/JMXConnectorFactory.java Changeset: 200ae4b8f192 Author: jbachorik Date: 2013-03-14 14:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/200ae4b8f192 8008607: Better input checking in JMX Reviewed-by: dfuchs, mchung, skoivu, sjiang ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java Changeset: a65111ce1ed7 Author: khazra Date: 2013-03-14 13:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a65111ce1ed7 7170730: Improve Windows network stack support. Summary: Enable exclusive binding of ports on Windows Reviewed-by: alanb, chegar, ahgross ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.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/solaris/native/sun/nio/ch/Net.c ! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/classes/java/net/DualStackPlainSocketImpl.java ! src/windows/classes/java/net/PlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/nio/ch/Net.c Changeset: 30f15138e298 Author: dmocek Date: 2013-03-13 17:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/30f15138e298 8001033: Refactor network address handling in virtual machine identifiers Reviewed-by: smarks, hawtin, mchung ! src/share/classes/java/rmi/dgc/VMID.java Changeset: 9f99c9ab588b Author: jgodinez Date: 2013-03-15 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9f99c9ab588b 8007927: Improve cmsAllocProfileSequenceDescription Reviewed-by: bae, mschoene, prr Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c Changeset: bf7120252a95 Author: jbachorik Date: 2013-03-18 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf7120252a95 8009996: tests javax/management/mxbean/MiscTest.java and javax/management/mxbean/StandardMBeanOverrideTest.java fail Reviewed-by: dfuchs, dholmes ! src/share/classes/javax/management/StandardEmitterMBean.java Changeset: 59ced5cf8344 Author: dfuchs Date: 2013-03-18 11:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/59ced5cf8344 8001043: Clarify definition restrictions Reviewed-by: alanb, skoivu, smarks ! src/share/classes/sun/rmi/server/LoaderHandler.java Changeset: 810688020f65 Author: sla Date: 2013-03-19 13:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/810688020f65 8003703: Update RMI connection dialog box Reviewed-by: skoivu, ahgross, mchung, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties Changeset: 8b4c3e09b29a Author: jgodinez Date: 2013-03-19 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b4c3e09b29a 8009013: Better handling of T2K glyphs Reviewed-by: bae, mschoene, prr Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/font/freetypeScaler.c Changeset: dd60654d4a8b Author: darcy Date: 2013-03-19 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd60654d4a8b 8001309: Better handling of annotation interfaces Reviewed-by: ahgross, smarks, alanb ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java Changeset: b412e6128726 Author: jgodinez Date: 2013-03-20 10:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b412e6128726 8007929: Improve CurvesAlloc Reviewed-by: bae, mschoene, prr Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c Changeset: cfea7f72cbcd Author: khazra Date: 2013-03-20 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cfea7f72cbcd 8010213: Some api/javax_net/SocketFactory tests fail in 7u25 nightly build Summary: Eliminate fall-through while setting socket options on Windows Reviewed-by: alanb, chegar ! src/windows/classes/java/net/DualStackPlainSocketImpl.java Changeset: 711187756b9e Author: leonidr Date: 2013-03-21 02:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/711187756b9e 8004584: Augment applet contextualization Summary: Do not create the main AppContext for applets Reviewed-by: art, ahgross ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 9d6d7886a74c Author: jbachorik Date: 2013-03-21 09:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d6d7886a74c 8008623: Better handling of MBeanServers Reviewed-by: dfuchs, dholmes, skoivu ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java Changeset: 9bcf9c9cb73d Author: vinnie Date: 2013-03-21 12:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9bcf9c9cb73d 8009067: Improve storing keys in KeyStore Reviewed-by: mullan, skoivu ! src/share/classes/java/security/KeyStore.java Changeset: 434e0155180c Author: jfdenise Date: 2013-03-26 09:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/434e0155180c 8009004: Better implementation of RMI connections Summary: Better class handling. Reviewed-by: alanb, dfuchs, skoivu, jbachorik Contributed-by: jean-francois.denise at oracle.com ! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: 72fac19dad5c Author: sjiang Date: 2013-03-26 08:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72fac19dad5c 8008615: Improve robustness of JMX internal APIs Reviewed-by: dfuchs, skoivu, dholmes ! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java ! src/share/classes/javax/management/MBeanServerFactory.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java Changeset: 27d79fbadda1 Author: jfdenise Date: 2013-03-27 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27d79fbadda1 8008128: Better API coherence for JMX Summary: Permission for getting classloader Reviewed-by: alanb, dfuchs, skoivu Contributed-by: jean-francois.denise at oracle.com ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java Changeset: 311f16954ada Author: jbachorik Date: 2013-03-27 13:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/311f16954ada 8010209: Better provision of factories Reviewed-by: dcubed, ahgross ! src/share/classes/sun/tracing/ProviderSkeleton.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java Changeset: 185cbf454f51 Author: jgodinez Date: 2013-03-27 11:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/185cbf454f51 8009654: Improve stability of cmsnamed Reviewed-by: bae, mschoene, prr Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c Changeset: c193b7431ea6 Author: jgodinez Date: 2013-03-27 15:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c193b7431ea6 8007925: Improve cmsStageAllocLabV2ToV4curves 8007926: Improve cmsPipelineDup Reviewed-by: bae, mschoene, prr Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/cmm/lcms/cmslut.c Changeset: 9137e1efe9fd Author: lancea Date: 2013-03-28 06:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9137e1efe9fd 8009554: Improve SerialJavaObject.getFields Reviewed-by: alanb, skoivu, mchung ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java Changeset: 7067e2e493e5 Author: khazra Date: 2013-03-28 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7067e2e493e5 8001318: Socket.getLocalAddress not consistent with InetAddress.getLocalHost Reviewed-by: alanb, chegar, hawtin ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/rmi/transport/proxy/WrappedSocket.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Changeset: d0ba983c0e70 Author: jbachorik Date: 2013-03-28 09:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d0ba983c0e70 8008982: Adjust JMX for underlying interface changes Reviewed-by: mchung, dholmes, dfuchs, skoivu ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java Changeset: 2db5b7f6aa66 Author: jgodinez Date: 2013-03-29 10:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2db5b7f6aa66 8001038: Resourcefully handle resources Reviewed-by: prr, bae Contributed-by: jia-hong.chen at oracle.com ! src/share/classes/java/awt/Font.java ! src/share/classes/sun/font/CreatedFontTracker.java Changeset: d6f0cbba0b8a Author: serb Date: 2013-03-29 22:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d6f0cbba0b8a 8006328: Improve robustness of sound classes 8009057: Improve MIDI event handling Reviewed-by: amenkov, art, skoivu ! src/share/classes/com/sun/media/sound/AbstractDataLine.java ! src/share/classes/com/sun/media/sound/AbstractLine.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/AbstractMidiDeviceProvider.java ! src/share/classes/com/sun/media/sound/AbstractMixer.java ! src/share/classes/com/sun/media/sound/AiffFileFormat.java ! src/share/classes/com/sun/media/sound/AiffFileReader.java ! src/share/classes/com/sun/media/sound/AiffFileWriter.java ! src/share/classes/com/sun/media/sound/AlawCodec.java ! src/share/classes/com/sun/media/sound/AuFileFormat.java ! src/share/classes/com/sun/media/sound/AuFileReader.java ! src/share/classes/com/sun/media/sound/AuFileWriter.java ! src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java ! src/share/classes/com/sun/media/sound/AudioFloatConverter.java ! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java ! src/share/classes/com/sun/media/sound/AudioFloatInputStream.java ! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java ! src/share/classes/com/sun/media/sound/DLSInfo.java ! src/share/classes/com/sun/media/sound/DLSInstrument.java ! src/share/classes/com/sun/media/sound/DLSModulator.java ! src/share/classes/com/sun/media/sound/DLSRegion.java ! src/share/classes/com/sun/media/sound/DLSSample.java ! src/share/classes/com/sun/media/sound/DLSSampleLoop.java ! src/share/classes/com/sun/media/sound/DLSSampleOptions.java ! src/share/classes/com/sun/media/sound/DLSSoundbank.java ! src/share/classes/com/sun/media/sound/DLSSoundbankReader.java ! src/share/classes/com/sun/media/sound/DataPusher.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/share/classes/com/sun/media/sound/DirectAudioDeviceProvider.java ! src/share/classes/com/sun/media/sound/EmergencySoundbank.java ! src/share/classes/com/sun/media/sound/EventDispatcher.java ! src/share/classes/com/sun/media/sound/FFT.java ! src/share/classes/com/sun/media/sound/FastShortMessage.java ! src/share/classes/com/sun/media/sound/JARSoundbankReader.java ! src/share/classes/com/sun/media/sound/JDK13Services.java ! src/share/classes/com/sun/media/sound/JSSecurityManager.java ! src/share/classes/com/sun/media/sound/JavaSoundAudioClip.java ! src/share/classes/com/sun/media/sound/MidiDeviceReceiverEnvelope.java ! src/share/classes/com/sun/media/sound/MidiDeviceTransmitterEnvelope.java ! src/share/classes/com/sun/media/sound/MidiInDevice.java ! src/share/classes/com/sun/media/sound/MidiInDeviceProvider.java ! src/share/classes/com/sun/media/sound/MidiOutDevice.java ! src/share/classes/com/sun/media/sound/MidiOutDeviceProvider.java ! src/share/classes/com/sun/media/sound/MidiUtils.java ! src/share/classes/com/sun/media/sound/ModelByteBuffer.java ! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java ! src/share/classes/com/sun/media/sound/ModelConnectionBlock.java ! src/share/classes/com/sun/media/sound/ModelDestination.java ! src/share/classes/com/sun/media/sound/ModelIdentifier.java ! src/share/classes/com/sun/media/sound/ModelInstrument.java ! src/share/classes/com/sun/media/sound/ModelInstrumentComparator.java ! src/share/classes/com/sun/media/sound/ModelMappedInstrument.java ! src/share/classes/com/sun/media/sound/ModelPatch.java ! src/share/classes/com/sun/media/sound/ModelPerformer.java ! src/share/classes/com/sun/media/sound/ModelSource.java ! src/share/classes/com/sun/media/sound/ModelStandardDirector.java ! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java ! src/share/classes/com/sun/media/sound/ModelStandardTransform.java ! src/share/classes/com/sun/media/sound/PCMtoPCMCodec.java ! src/share/classes/com/sun/media/sound/Platform.java ! src/share/classes/com/sun/media/sound/PortMixer.java ! src/share/classes/com/sun/media/sound/PortMixerProvider.java ! src/share/classes/com/sun/media/sound/Printer.java ! src/share/classes/com/sun/media/sound/RIFFInvalidDataException.java ! src/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java ! src/share/classes/com/sun/media/sound/RIFFReader.java ! src/share/classes/com/sun/media/sound/RIFFWriter.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/share/classes/com/sun/media/sound/RealTimeSequencerProvider.java ! src/share/classes/com/sun/media/sound/SF2GlobalRegion.java ! src/share/classes/com/sun/media/sound/SF2Instrument.java ! src/share/classes/com/sun/media/sound/SF2InstrumentRegion.java ! src/share/classes/com/sun/media/sound/SF2Layer.java ! src/share/classes/com/sun/media/sound/SF2LayerRegion.java ! src/share/classes/com/sun/media/sound/SF2Modulator.java ! src/share/classes/com/sun/media/sound/SF2Sample.java ! src/share/classes/com/sun/media/sound/SF2Soundbank.java ! src/share/classes/com/sun/media/sound/SF2SoundbankReader.java ! src/share/classes/com/sun/media/sound/SoftAbstractResampler.java ! src/share/classes/com/sun/media/sound/SoftAudioBuffer.java ! src/share/classes/com/sun/media/sound/SoftAudioPusher.java ! src/share/classes/com/sun/media/sound/SoftChannel.java ! src/share/classes/com/sun/media/sound/SoftChannelProxy.java ! src/share/classes/com/sun/media/sound/SoftChorus.java ! src/share/classes/com/sun/media/sound/SoftCubicResampler.java ! src/share/classes/com/sun/media/sound/SoftEnvelopeGenerator.java ! src/share/classes/com/sun/media/sound/SoftFilter.java ! src/share/classes/com/sun/media/sound/SoftInstrument.java ! src/share/classes/com/sun/media/sound/SoftJitterCorrector.java ! src/share/classes/com/sun/media/sound/SoftLanczosResampler.java ! src/share/classes/com/sun/media/sound/SoftLimiter.java ! src/share/classes/com/sun/media/sound/SoftLinearResampler.java ! src/share/classes/com/sun/media/sound/SoftLinearResampler2.java ! src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java ! src/share/classes/com/sun/media/sound/SoftMainMixer.java ! src/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java ! src/share/classes/com/sun/media/sound/SoftMixingClip.java ! src/share/classes/com/sun/media/sound/SoftMixingDataLine.java ! src/share/classes/com/sun/media/sound/SoftMixingMainMixer.java ! src/share/classes/com/sun/media/sound/SoftMixingMixer.java ! src/share/classes/com/sun/media/sound/SoftMixingMixerProvider.java ! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java ! src/share/classes/com/sun/media/sound/SoftPerformer.java ! src/share/classes/com/sun/media/sound/SoftPointResampler.java ! src/share/classes/com/sun/media/sound/SoftProvider.java ! src/share/classes/com/sun/media/sound/SoftReceiver.java ! src/share/classes/com/sun/media/sound/SoftReverb.java ! src/share/classes/com/sun/media/sound/SoftShortMessage.java ! src/share/classes/com/sun/media/sound/SoftSincResampler.java ! src/share/classes/com/sun/media/sound/SoftSynthesizer.java ! src/share/classes/com/sun/media/sound/SoftTuning.java ! src/share/classes/com/sun/media/sound/SoftVoice.java ! src/share/classes/com/sun/media/sound/StandardMidiFileReader.java ! src/share/classes/com/sun/media/sound/StandardMidiFileWriter.java ! src/share/classes/com/sun/media/sound/SunCodec.java ! src/share/classes/com/sun/media/sound/SunFileReader.java ! src/share/classes/com/sun/media/sound/SunFileWriter.java ! src/share/classes/com/sun/media/sound/Toolkit.java ! src/share/classes/com/sun/media/sound/UlawCodec.java ! src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java ! src/share/classes/com/sun/media/sound/WaveFileFormat.java ! src/share/classes/com/sun/media/sound/WaveFileReader.java ! src/share/classes/com/sun/media/sound/WaveFileWriter.java ! src/share/classes/com/sun/media/sound/WaveFloatFileReader.java ! src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java ! src/share/classes/javax/sound/midi/MetaMessage.java ! src/share/classes/javax/sound/sampled/Mixer.java ! src/share/classes/sun/audio/AudioData.java ! src/share/classes/sun/audio/AudioDataStream.java ! src/share/classes/sun/audio/AudioDevice.java ! src/share/classes/sun/audio/AudioPlayer.java ! src/share/classes/sun/audio/AudioStream.java ! src/share/classes/sun/audio/AudioStreamSequence.java ! src/share/classes/sun/audio/AudioTranslatorStream.java ! src/share/classes/sun/audio/ContinuousAudioDataStream.java ! src/share/classes/sun/audio/InvalidAudioFormatException.java Changeset: 2eac60e99307 Author: dsamersoff Date: 2013-03-31 22:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2eac60e99307 8007471: Improve MBean notifications Summary: Improve MBean notifications Reviewed-by: dfuchs, mchung, alanb, skoivu ! src/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java Changeset: 107f21efda78 Author: dsamersoff Date: 2013-03-31 22:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/107f21efda78 8008120: Improve JMX class checking Summary: Improve JMX class checking Reviewed-by: mchung, dfuchs, alanb, skoivu ! src/share/classes/javax/management/relation/RelationNotification.java Changeset: 0bddd4e8bfb6 Author: dsamersoff Date: 2013-03-31 23:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0bddd4e8bfb6 8008124: Better compliance testing Summary: Better compliance testing Reviewed-by: dfuchs, jfdenise, skoivu, alanb ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: 0d36b1e3e509 Author: prr Date: 2013-04-01 09:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0d36b1e3e509 8005007: Better glyph processing Reviewed-by: srl, mschoene, bae ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: 4224b02452f5 Author: sjiang Date: 2013-04-02 10:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4224b02452f5 8007467: Better JMX type conversion Reviewed-by: dfuchs, mchung, skoivu ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanIntrospector.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java Changeset: 5ae5c4120014 Author: egahlin Date: 2013-03-21 13:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5ae5c4120014 8008611: Better handling of annotations in JMX Reviewed-by: skoivu, dholmes, jfdenise ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: 802f5e480c8a Author: mullan Date: 2013-04-05 10:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/802f5e480c8a 8001330: Improve on checking order Reviewed-by: acorn, hawtin ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/ProtectionDomain.java Changeset: e5969bf37f26 Author: chegar Date: 2013-04-08 06:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e5969bf37f26 8008593: Better URLClassLoader resource management Reviewed-by: alanb, sherman, hawtin ! make/java/zip/mapfile-vers ! make/java/zip/reorder-i586 ! make/java/zip/reorder-sparc ! make/java/zip/reorder-sparcv9 ! makefiles/mapfiles/libzip/mapfile-vers ! makefiles/mapfiles/libzip/reorder-sparc ! makefiles/mapfiles/libzip/reorder-sparcv9 ! makefiles/mapfiles/libzip/reorder-x86 ! src/share/classes/java/util/zip/ZipFile.java + src/share/classes/sun/misc/JavaUtilZipFileAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h Changeset: 6f75b365af19 Author: vinnie Date: 2013-04-08 21:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f75b365af19 8009235: Improve handling of TSA data Reviewed-by: ahgross, mullan ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/timestamp/TimestampToken.java Changeset: 5496abfc666a Author: prr Date: 2013-04-08 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5496abfc666a 8011248: Better Component Rasters Reviewed-by: bae, vadim, mschoene ! src/share/classes/sun/awt/image/IntegerComponentRaster.java Changeset: 761e0002dcfe Author: prr Date: 2013-04-08 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/761e0002dcfe 8011253: Better Short Component Rasters Reviewed-by: bae, vadim, mschoene ! src/share/classes/sun/awt/image/ShortBandedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java Changeset: 1adc1051f2d3 Author: prr Date: 2013-04-08 13:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1adc1051f2d3 8011257: Better Byte Component Rasters Reviewed-by: bae, vadim, mschoene ! src/share/classes/sun/awt/image/ByteBandedRaster.java ! src/share/classes/sun/awt/image/ByteComponentRaster.java Changeset: eafd52d53f09 Author: bae Date: 2013-04-10 15:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eafd52d53f09 8011243: Improve ImagingLib Reviewed-by: prr, vadim ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c Changeset: fa42f0831e66 Author: bae Date: 2013-04-12 14:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fa42f0831e66 8011992: java/awt/image/mlib/MlibOpsTest.java failed since jdk7u25b05 Reviewed-by: vadim ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! test/java/awt/image/mlib/MlibOpsTest.java Changeset: bfe04328d394 Author: bae Date: 2013-04-15 14:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bfe04328d394 8012112: java/awt/image/mlib/MlibOpsTest.java fails on sparc solaris Reviewed-by: prr, vadim ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! test/java/awt/image/mlib/MlibOpsTest.java Changeset: 7d90e3e0a8ec Author: leonidr Date: 2013-04-16 21:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d90e3e0a8ec 8011695: [tck-red] Application can not be run, the Security Warning dialog is gray. Summary: EventQueue shouldn't use AppContext.getAppContext() to obtain its AppContext. Reviewed-by: art ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: cf14f699f36c Author: anthony Date: 2013-04-18 13:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf14f699f36c 8009071: Improve shape handling Reviewed-by: art, mschoene ! src/macosx/native/sun/awt/CRobot.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m + src/share/native/common/sizecalc.h ! src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/share/native/sun/java2d/pipe/Region.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/native/sun/font/lcdglyph.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/windows/CmdIDList.cpp ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/alloc.h ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Cursor.cpp ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp Changeset: 4934254492af Author: sundar Date: 2013-04-19 11:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4934254492af 8006611: Improve scripting Reviewed-by: mchung ! src/share/classes/javax/script/ScriptEngineManager.java Changeset: a73ecb5085eb Author: jfranck Date: 2013-04-19 14:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a73ecb5085eb 8007812: (reflect) Class.getEnclosingMethod problematic for some classes Summary: Better checking in getEnclosing(Method|Constructor|Class) Reviewed-by: darcy, ahgross, mchung ! src/share/classes/java/lang/Class.java + test/lib/testlibrary/ClassFileInstaller.java Changeset: 15370008c68d Author: chegar Date: 2013-04-22 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/15370008c68d 8012692: SerialJavaObject.java should be CallerSensitive aware Reviewed-by: mchung ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java Changeset: ff3ac3680ffa Author: mchung Date: 2013-04-22 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff3ac3680ffa 8012689: CallerSensitive annotation should not have CONSTRUCTOR Target Reviewed-by: chegar ! src/share/classes/sun/reflect/CallerSensitive.java Changeset: 783ed53bce0b Author: smarks Date: 2013-04-22 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/783ed53bce0b 8008132: Better serialization support Reviewed-by: alanb, hawtin ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/ObjectStreamField.java Changeset: bb0ec4661eb8 Author: chegar Date: 2013-04-22 11:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb0ec4661eb8 8012917: ObjectStreamClass and ObjectStreamField should be CallerSensitive aware Reviewed-by: mchung ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/ObjectStreamField.java Changeset: 10558009e439 Author: anthony Date: 2013-04-09 12:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/10558009e439 8011154: java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java failed since 7u25b03 on windows Reviewed-by: art, yan ! src/windows/native/sun/windows/awt_Component.cpp Changeset: 0f0ff6e9da05 Author: mullan Date: 2013-04-22 11:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0f0ff6e9da05 6741606: Integrate Apache Santuario Reviewed-by: vinnie, hawtin ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/I18n.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverFragment.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java ! src/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! 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/javax/xml/crypto/dsig/GenerationTests.java ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java ! test/javax/xml/crypto/dsig/ValidationTests.java Changeset: 72f55e763113 Author: leonidr Date: 2013-03-27 16:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72f55e763113 8003559: Update display of applet windows Summary: Implemented applet security warning for OS X port Reviewed-by: art, anthony, serb, skoivu ! make/sun/awt/Makefile + make/sun/awt/ToBin.java ! make/sun/lwawt/FILES_export_macosx.gmk ! make/sun/xawt/Makefile - make/sun/xawt/ToBin.java ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcIcons.gmk ! makefiles/Tools.gmk + makefiles/sun/awt/ToBin.java - makefiles/sun/awt/X11/ToBin.java ! src/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + src/macosx/classes/sun/lwawt/PlatformEventNotifier.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java + src/macosx/classes/sun/lwawt/SecurityWarningWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java + src/macosx/classes/sun/lwawt/macosx/CWarningWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CWrapper.m + src/share/classes/sun/awt/IconInfo.java + src/share/classes/sun/awt/resources/security-icon-bw16.png + src/share/classes/sun/awt/resources/security-icon-bw24.png + src/share/classes/sun/awt/resources/security-icon-bw32.png + src/share/classes/sun/awt/resources/security-icon-bw48.png + src/share/classes/sun/awt/resources/security-icon-interim16.png + src/share/classes/sun/awt/resources/security-icon-interim24.png + src/share/classes/sun/awt/resources/security-icon-interim32.png + src/share/classes/sun/awt/resources/security-icon-interim48.png + src/share/classes/sun/awt/resources/security-icon-yellow16.png + src/share/classes/sun/awt/resources/security-icon-yellow24.png + src/share/classes/sun/awt/resources/security-icon-yellow32.png + src/share/classes/sun/awt/resources/security-icon-yellow48.png ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java - src/solaris/classes/sun/awt/X11/XIconInfo.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindowAttributesData.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png Changeset: 31980806a21a Author: chegar Date: 2013-04-19 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/31980806a21a Merge - make/sun/xawt/ToBin.java ! makefiles/Tools.gmk - makefiles/sun/awt/X11/ToBin.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java - src/solaris/classes/sun/awt/X11/XIconInfo.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png Changeset: 7615af456906 Author: chegar Date: 2013-04-22 11:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7615af456906 Merge Changeset: d0dbbdbb217f Author: mchung Date: 2013-04-17 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d0dbbdbb217f 8011557: Improve reflection utility classes Reviewed-by: ahgross, alanb ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 25b69fbfe80f Author: chegar Date: 2013-04-23 11:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25b69fbfe80f Merge ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/sun/security/timestamp/TimestampToken.java Changeset: 3197c702c8d1 Author: bae Date: 2013-04-24 21:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3197c702c8d1 8012438: Better image validation Reviewed-by: prr ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/share/classes/java/awt/image/Raster.java ! src/share/classes/sun/awt/image/ByteBandedRaster.java ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/BytePackedRaster.java ! src/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/share/classes/sun/awt/image/ShortBandedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 256ebcf1317b Author: chegar Date: 2013-04-28 09:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/256ebcf1317b Merge ! src/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/sun/awt/SunToolkit.java - src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: c3a08adee3ea Author: chegar Date: 2013-05-01 12:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3a08adee3ea Merge Changeset: f1c0e2da008c Author: chegar Date: 2013-05-08 11:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f1c0e2da008c Merge ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/nio/file/Files.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: b8102c2f6632 Author: chegar Date: 2013-05-16 11:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8102c2f6632 Merge Changeset: 60a2184a71f2 Author: chegar Date: 2013-05-23 12:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60a2184a71f2 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile ! src/macosx/classes/sun/lwawt/LWToolkit.java - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/sun/net/httpserver/ServerImpl.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: aa559d55fc4a Author: chegar Date: 2013-05-31 10:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aa559d55fc4a Merge Changeset: 405cd7338069 Author: chegar Date: 2013-06-10 10:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/405cd7338069 Merge ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/util/zip/ZipFile.java - src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! 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 ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.h ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java Changeset: cd0140e5bee5 Author: prr Date: 2013-04-25 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd0140e5bee5 8012421: Better positioning of PairPositioning Reviewed-by: srl, mschoene, vadim ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h Changeset: 97149218a8ad Author: bae Date: 2013-04-26 11:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/97149218a8ad 8012601: Better validation of image layouts Reviewed-by: prr ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java Changeset: 40c65c6711ee Author: prr Date: 2013-04-26 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/40c65c6711ee 8012617: ArrayIndexOutOfBoundsException with some fonts using LineBreakMeasurer Reviewed-by: bae, srl ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SunLayoutEngine.cpp + test/java/awt/font/LineBreakMeasurer/AllFontsLBM.java Changeset: 30c8c83eeb70 Author: mullan Date: 2013-04-29 11:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/30c8c83eeb70 8009217: REGRESSION: test com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java fails to compile since 7u21b03 Reviewed-by: xuelei ! test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java ! test/com/sun/org/apache/xml/internal/security/transforms/MyTransform.java Changeset: 19af6fae7b98 Author: bae Date: 2013-04-30 04:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/19af6fae7b98 8012597: Better image channel verification Reviewed-by: vadim ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 1b86ce92dc2f Author: alexsch Date: 2013-04-30 13:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1b86ce92dc2f 8012330: [macosx] Sometimes the applet showing the modal dialog itself loses the ability to gain focus Reviewed-by: serb, ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: d4c5b2792d55 Author: dfuchs Date: 2013-05-02 10:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d4c5b2792d55 8012243: about 30% regression on specjvm2008.serial on 7u25 comparing 7u21 Reviewed-by: alanb, skoivu, smarks, mchung ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/ObjectStreamField.java Changeset: e898a9e1404b Author: mullan Date: 2013-05-02 11:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e898a9e1404b 8008744: Rework part of fix for JDK-6741606 Reviewed-by: xuelei, ahgross + src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java + src/share/classes/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java Changeset: b3850bdca7f1 Author: leonidr Date: 2013-05-06 16:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3850bdca7f1 8012933: Test closed/java/awt/Dialog/DialogAnotherThread/JaWSTest.java fails since jdk 7u25 b07 Summary: Do not mark context as disposed until we've posted all the events Reviewed-by: art ! src/share/classes/sun/awt/AppContext.java + test/sun/awt/AppContext/8012933/Test8012933.java Changeset: fb7dc7c54145 Author: jfranck Date: 2013-05-07 13:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fb7dc7c54145 8011139: (reflect) Revise checking in getEnclosingClass Reviewed-by: darcy, mchung, ahgross ! src/share/classes/java/lang/Class.java Changeset: cefd77938a6c Author: twisti Date: 2013-05-08 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cefd77938a6c 8009424: Restrict publicLookup with additional checks Reviewed-by: vlivanov, jdn ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 7f2fc413fb1d Author: coffeys Date: 2013-05-09 20:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7f2fc413fb1d 8013196: TimeZone.getDefault() throws NPE due to sun.awt.AppContext.getAppContext() Reviewed-by: mchung, okutsu ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/SharedSecrets.java Changeset: 3948bdc62c34 Author: mullan Date: 2013-05-13 17:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3948bdc62c34 8010714: XML DSig API allows a RetrievalMethod to reference another RetrievalMethod Reviewed-by: xuelei, hawtin ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java Changeset: 5d342b420db0 Author: xuelei Date: 2013-05-14 05:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d342b420db0 8014281: Better checking of XML signature Summary: also reviewed by Andrew Gross and Christophe Ravel Reviewed-by: mullan ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java Changeset: c261596407b5 Author: bae Date: 2013-05-14 21:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c261596407b5 8014427: REGRESSION: closed/javax/imageio/plugins/bmp/Write3ByteBgrTest.java fails since 7u25 b09 Reviewed-by: prr ! src/share/classes/java/awt/image/Raster.java Changeset: 392f03789497 Author: mchung Date: 2013-05-14 08:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/392f03789497 8010727: WLS fails to add a logger with "" in its own LogManager subclass instance Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/LogManagerInstanceTest.java Changeset: 8e07710dca9a Author: bae Date: 2013-05-17 16:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8e07710dca9a 8014205: Most of the Swing dialogs are blank on one win7 MUI Reviewed-by: vadim ! src/share/classes/java/awt/image/BufferedImage.java Changeset: 1d8fe72d3c4e Author: leonidr Date: 2013-05-20 19:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d8fe72d3c4e 8014718: Netbeans IDE begins to throw a lot exceptions since 7u25 b10 Summary: Removed logging from SunToolkit Reviewed-by: art ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 25baf6dc46a0 Author: chegar Date: 2013-05-22 13:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25baf6dc46a0 8014737: java/lang/invoke/7196190/MHProxyTest.java fails after 8009424 Reviewed-by: twisti - test/java/lang/invoke/7196190/MHProxyTest.java Changeset: a4ea4234facf Author: chegar Date: 2013-06-14 16:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a4ea4234facf 8012156: tools/javac/file/zip/T6865530.java fails for win32/64 in 7u25 nightly runs Reviewed-by: alanb ! src/share/classes/sun/misc/URLClassPath.java Changeset: 7d56b8a92f52 Author: chegar Date: 2013-06-17 11:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d56b8a92f52 Merge ! make/sun/awt/Makefile ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/security/KeyStore.java - src/share/classes/sun/misc/Hashing.java - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties ! src/solaris/native/sun/xawt/XlibWrapper.c - test/sun/misc/Hashing.java Changeset: e3b075b8f21f Author: chegar Date: 2013-06-17 14:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e3b075b8f21f Merge ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: c31fa946605c Author: chegar Date: 2013-06-18 09:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c31fa946605c Merge ! src/share/classes/java/lang/Class.java Changeset: 403e63195af5 Author: chegar Date: 2013-06-18 16:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/403e63195af5 Merge Changeset: ba544aab1fcd Author: bpb Date: 2013-06-18 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba544aab1fcd 8015395: NumberFormatException during startup if JDK-internal property java.lang.Integer.IntegerCache.high set to bad value Summary: Fall back to default if a bad value is passed for this property. Reviewed-by: mduigou ! src/share/classes/java/lang/Integer.java Changeset: eb1a3c50a2a9 Author: mduigou Date: 2013-06-18 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eb1a3c50a2a9 Merge Changeset: 1f7cbe4829fe Author: mduigou Date: 2013-06-18 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1f7cbe4829fe 8016446: Improve forEach/replaceAll for Map, HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap, ConcurrentMap Reviewed-by: forax, mduigou, psandoz Contributed-by: Mike Duigou , Remi Forax ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! test/java/util/Map/Defaults.java Changeset: 2d9da733014f Author: xuelei Date: 2013-06-18 18:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2d9da733014f 8000456: Add programmatic deadlock detection in SSLEngineDeadlock Reviewed-by: wetmore ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java Changeset: d82773b770ce Author: mfang Date: 2013-06-18 21:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d82773b770ce 8015657: jdk8 l10n resource file translation update 3 Reviewed-by: yhuang ! src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/serialver/serialver_zh_CN.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 Changeset: a76858faad59 Author: xuelei Date: 2013-06-19 02:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a76858faad59 7188658: Add possibility to disable client initiated renegotiation Reviewed-by: weijun, wetmore ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java Changeset: 22337da71eca Author: chegar Date: 2013-06-19 11:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/22337da71eca 8017044: anti-delta fix for 8015402 Reviewed-by: alanb ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java Changeset: 8bc1b313a082 Author: chegar Date: 2013-06-19 13:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8bc1b313a082 Merge Changeset: 9b802d99cb52 Author: bpb Date: 2013-06-19 08:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b802d99cb52 4837946: Faster multiplication and exponentiation of large integers 4646474: BigInteger.pow() algorithm slow in 1.4.0 Summary: Implement Karatsuba and 3-way Toom-Cook multiplication as well as exponentiation using Karatsuba and Toom-Cook squaring. Reviewed-by: alanb, bpb, martin Contributed-by: Alan Eliasen ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java Changeset: c3087d966f1f Author: chegar Date: 2013-06-19 11:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3087d966f1f Merge ! 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 Changeset: a5735e6d6616 Author: chegar Date: 2013-06-19 11:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a5735e6d6616 Merge Changeset: a9ad5ac3430b Author: chegar Date: 2013-06-19 15:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a9ad5ac3430b 8017057: More ProblemList.txt updates (6/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: 8fd1e39b1c2b Author: chegar Date: 2013-06-19 17:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8fd1e39b1c2b Merge Changeset: f6d72c4f6bf1 Author: dxu Date: 2013-06-19 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f6d72c4f6bf1 8016592: Clean-up Javac Overrides Warnings In javax/management/NotificationBroadcasterSupport.java Summary: Add hashCode() methods to ListenerInfo and WildcardListenerInfo classes Reviewed-by: dfuchs, alanb, sjiang, chegar ! src/share/classes/javax/management/NotificationBroadcasterSupport.java Changeset: de6b93fd6d23 Author: khazra Date: 2013-06-19 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/de6b93fd6d23 8016576: Overrides warnings in jdi and jconsole Summary: Implement hashCode() in classes emitting warnings Reviewed-by: alanb, chegar ! src/share/classes/com/sun/tools/jdi/SDE.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java Changeset: e1b18a666f76 Author: khazra Date: 2013-06-19 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e1b18a666f76 8016698: Cleanup overrides warning in sun/tools/ClassDeclaration.java Summary: Override Object.hashCode() Reviewed-by: alanb, chegar ! src/share/classes/sun/tools/java/ClassDeclaration.java Changeset: 2b156531b7eb Author: arieber Date: 2013-06-19 17:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2b156531b7eb 7025238: HttpURLConnection does not handle URLs with an empty path component. Summary: Prepend a '/' to file when path is empty Reviewed-by: chegar, khazra ! src/share/classes/sun/net/www/http/HttpClient.java + test/sun/net/www/http/HttpClient/B7025238.java Changeset: aa4610fe8a73 Author: lana Date: 2013-06-19 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aa4610fe8a73 Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java - src/solaris/classes/sun/awt/X11/XIconInfo.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: fce2eaa84b21 Author: lana Date: 2013-06-24 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fce2eaa84b21 Merge Changeset: 58e5d1149f97 Author: erikj Date: 2013-06-25 09:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/58e5d1149f97 8017480: Move copying of jfr files to closed makefile Reviewed-by: sla, tbell ! makefiles/CopyFiles.gmk Changeset: fd41ca58229c Author: katleman Date: 2013-06-25 13:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd41ca58229c Merge Changeset: 4a5d3cf2b3af Author: katleman Date: 2013-06-26 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4a5d3cf2b3af 8016684: JDK8 b94 source with GPL header errors Reviewed-by: tbell, darcy ! src/share/classes/java/nio/CharBufferSpliterator.java ! src/share/native/sun/management/DiagnosticCommandImpl.c ! test/java/lang/management/MXBean/MXBeanBehavior.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java Changeset: 2f1386fc2079 Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f1386fc2079 Added tag jdk8-b96 for changeset 4a5d3cf2b3af ! .hgtags From john.coomes at oracle.com Thu Jun 27 21:38:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jun 2013 04:38:11 +0000 Subject: hg: hsx/hotspot-main/nashorn: 33 new changesets Message-ID: <20130628043837.D9CD248611@hg.openjdk.java.net> Changeset: bab844827181 Author: sundar Date: 2013-06-06 21:41 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bab844827181 8015346: JSON parsing issues with escaped strings, octal, decimal numbers Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8015346.js Changeset: 918a986b0478 Author: hannesw Date: 2013-06-07 17:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/918a986b0478 8012291: NativeArray is inconsistent in using long for length and index in some places and int for the same in other places Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/examples/array-micro.js + test/script/basic/JDK-8012291.js + test/script/basic/JDK-8012291.js.EXPECTED Changeset: 8f890b6bf6de Author: lagergren Date: 2013-06-10 13:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8f890b6bf6de 8015892: canBeUndefined too conservative for some use before declaration cases Reviewed-by: attila, hannesw ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/ir/Symbol.java + test/script/basic/JDK-8015892.js + test/script/basic/fib_wtf.js + test/script/basic/fib_wtf.js.EXPECTED Changeset: a6f8ea57f048 Author: lagergren Date: 2013-06-10 13:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a6f8ea57f048 8016226: backing out test without third party license approval Reviewed-by: attila, sundar - test/script/basic/fib_wtf.js - test/script/basic/fib_wtf.js.EXPECTED Changeset: 966868ef75ee Author: sundar Date: 2013-06-10 19:54 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/966868ef75ee 8016239: loadWithNewGlobal should support user supplied arguments from the caller Reviewed-by: lagergren, attila, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8016239.js + test/script/basic/JDK-8016239.js.EXPECTED Changeset: 1a5d67424e83 Author: sundar Date: 2013-06-11 13:09 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1a5d67424e83 8015357: a = []; a[0x7fffffff]=1; a.sort()[0] should evaluate to 1 instead of undefined Reviewed-by: hannesw, lagergren + test/script/basic/JDK-8015357.js Changeset: fe830f6daa3f Author: sundar Date: 2013-06-11 13:12 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fe830f6daa3f Merge Changeset: 558d31c168ed Author: lana Date: 2013-06-16 22:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/558d31c168ed Merge Changeset: df5d7f34e35e Author: hannesw Date: 2013-06-11 17:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/df5d7f34e35e 8015379: PropertyMap.addProperty() is slow Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: aa16622193e1 Author: jlaskey Date: 2013-06-12 11:22 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/aa16622193e1 8016453: loadWithNewGlobal does not allow apply operation Reviewed-by: hannesw, sundar Contributed-by: james.laskey at oracle.com ! samples/test.js ! src/jdk/nashorn/internal/objects/Global.java Changeset: d26e069353c0 Author: hannesw Date: 2013-06-12 16:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d26e069353c0 8011893: JS Object builtin prototype is not thread safe Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java + test/script/basic/JDK-8011893.js + test/script/basic/JDK-8011893.js.EXPECTED Changeset: b0dcc3727fc3 Author: sundar Date: 2013-06-13 16:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b0dcc3727fc3 8015355: Array.prototype functions don't honour non-writable length and / or index properties Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java + test/script/basic/JDK-8015355.js Changeset: 6d6133ef1fd5 Author: hannesw Date: 2013-06-13 12:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6d6133ef1fd5 8016518: Parsing of octal string escapes is broken Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/parser/Lexer.java + test/script/basic/JDK-8016518.js + test/script/basic/JDK-8016518.js.EXPECTED Changeset: 18362e95e638 Author: hannesw Date: 2013-06-13 14:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/18362e95e638 8016522: Numeric literal must not be followed by IdentifierStart Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/error/JDK-8016522.js + test/script/error/JDK-8016522.js.EXPECTED Changeset: fe80eda7b57e Author: hannesw Date: 2013-06-13 15:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fe80eda7b57e 8016528: Hex code from escape() should be padded Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + test/script/basic/JDK-8016528.js + test/script/basic/JDK-8016528.js.EXPECTED Changeset: c5f783d83180 Author: hannesw Date: 2013-06-13 20:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c5f783d83180 8016542: String.prototype.replace called with function argument should not replace $ patterns Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8016542.js + test/script/basic/JDK-8016542.js.EXPECTED Changeset: 3efa56767847 Author: lagergren Date: 2013-06-14 13:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3efa56767847 8016235: Use in catch block that may not have been executed in try block caused illegal byte code to be generated Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java + test/script/basic/JDK-8016235.js Changeset: 3d947baa33cc Author: sundar Date: 2013-06-14 21:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3d947baa33cc 8016618: script mirror object access should be improved Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptObject.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/ReverseScriptObjectMirrorIterator.java + src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java + test/script/basic/JDK-8016618.js + test/script/basic/JDK-8016618.js.EXPECTED Changeset: a2fa56222fa2 Author: sundar Date: 2013-06-17 13:56 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a2fa56222fa2 8016550: nashorn.option.no.syntax.extensions has the wrong default Reviewed-by: hannesw, lagergren ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! test/script/basic/moduleload.js Changeset: bfac80dffc49 Author: sundar Date: 2013-06-18 13:25 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bfac80dffc49 Merge Changeset: 616ab697fcac Author: sundar Date: 2013-06-18 13:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/616ab697fcac 8008915: URLReader constructor should allow specifying encoding Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/URLReader.java ! src/jdk/nashorn/internal/runtime/Source.java Changeset: 2cf438a3a3aa Author: sundar Date: 2013-06-18 13:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2cf438a3a3aa Merge Changeset: af8a98ea83d4 Author: chegar Date: 2013-04-24 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/af8a98ea83d4 Merge Changeset: 2237e2ff3685 Author: chegar Date: 2013-04-28 08:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2237e2ff3685 Merge Changeset: 2a377892c255 Author: chegar Date: 2013-05-08 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2a377892c255 Merge Changeset: d8ae3d87ca26 Author: chegar Date: 2013-05-16 11:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d8ae3d87ca26 Merge Changeset: d3076aecc567 Author: chegar Date: 2013-05-23 12:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d3076aecc567 Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - src/jdk/nashorn/internal/runtime/SpillProperty.java - test/script/trusted/logcoverage.js Changeset: ded7168cb008 Author: chegar Date: 2013-05-31 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ded7168cb008 Merge Changeset: 2b61f82350de Author: chegar Date: 2013-06-10 09:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2b61f82350de Merge - src/jdk/nashorn/internal/objects/DateParser.java - src/jdk/nashorn/internal/runtime/options/ValueOption.java - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java - src/netscape/javascript/JSObject.java Changeset: 12f1d8d74375 Author: chegar Date: 2013-06-17 11:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/12f1d8d74375 Merge Changeset: fbcd5c26937a Author: chegar Date: 2013-06-18 16:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fbcd5c26937a Merge Changeset: d6bd440ac5b9 Author: lana Date: 2013-06-24 14:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d6bd440ac5b9 Merge Changeset: 1bf1d6ce3042 Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1bf1d6ce3042 Added tag jdk8-b96 for changeset d6bd440ac5b9 ! .hgtags From john.coomes at oracle.com Thu Jun 27 21:35:50 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jun 2013 04:35:50 +0000 Subject: hg: hsx/hotspot-main/langtools: 41 new changesets Message-ID: <20130628043754.A6DD54860F@hg.openjdk.java.net> Changeset: 8717586f7b05 Author: emc Date: 2013-06-06 08:48 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8717586f7b05 8015701: MethodParameters are not filled in for synthetic captured local variables Summary: Synthetic parameters for captured local variables in an anonymous inner class are not added to MethodParameters attributes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/8015701/AnonymousParameters.java Changeset: 6e30a513c945 Author: mcimadamore Date: 2013-06-06 15:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6e30a513c945 6360970: javac erroneously accept ambiguous field reference Summary: clash between ambiguous fields in superinterface and unambiguous field in subinterface is erroneously marked as unambiguous Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/6360970/T6360970.java + test/tools/javac/6360970/T6360970.out Changeset: 7889d1fe2597 Author: mcimadamore Date: 2013-06-06 15:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7889d1fe2597 7139681: Enhanced for loop: local variable scope inconsistent with JLS Summary: For-each loop variable is incorrectly visible from the for-each expression Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/foreach/7139681/T7139681neg.java + test/tools/javac/foreach/7139681/T7139681neg.out + test/tools/javac/foreach/7139681/T7139681pos.java Changeset: 349160289ba2 Author: mcimadamore Date: 2013-06-06 15:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/349160289ba2 8008627: Compiler mishandles three-way return-type-substitutability Summary: Compiler should not enforce an order in how ambiguous methods should be resolved Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/rawOverride/T8008627.java ! test/tools/javac/lambda/funcInterfaces/NonSAM2.java ! test/tools/javac/lambda/funcInterfaces/NonSAM2.out Changeset: f8472e561a97 Author: mcimadamore Date: 2013-06-06 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f8472e561a97 8015432: javac crashes with stack overflow when method called recursively from nested generic call Summary: Check.checkMethod should only be called after inference has completed Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/inference/7177306/T7177306a.out + test/tools/javac/lambda/TargetType74.java Changeset: f218bb5ebd53 Author: mcimadamore Date: 2013-06-06 15:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f218bb5ebd53 8015648: Duplicate variable in lambda causes javac crash Summary: Missing flag in synthetic lambda blog is causing duplicates symbol to go undetected Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/LambdaScope05.java + test/tools/javac/lambda/LambdaScope05.out Changeset: 5b039297151e Author: mcimadamore Date: 2013-06-06 15:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5b039297151e Merge Changeset: fd31bf97340f Author: jjg Date: 2013-06-07 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fd31bf97340f 8016193: Fix OAC issue in langtools docs Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/Tag.java Changeset: 105d1f9c1ab8 Author: vromero Date: 2013-06-10 15:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/105d1f9c1ab8 7113519: test/tools/javac/VersionOpt.java passes on windows Reviewed-by: jjg ! test/tools/javac/VersionOpt.java Changeset: 3582b62dccb2 Author: mcimadamore Date: 2013-06-10 15:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3582b62dccb2 8013576: Add stat support to LambdaToMethod Summary: LambdaToMethod should emit info to help diagnose/test lambda metafactory problems Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/LambdaStat.java + test/tools/javac/diags/examples/MrefStat.java + test/tools/javac/diags/examples/MrefStat.java.rej + test/tools/javac/diags/examples/MrefStat1.java + test/tools/javac/diags/examples/MrefStat1.java.rej + test/tools/javac/lambda/TestLambdaToMethodStats.java Changeset: bbedff0dc37e Author: vromero Date: 2013-06-11 09:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bbedff0dc37e 8008547: javac, warning message: use of ''_'' as an identifier might not be supported in future releases, should be more especific Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: 7fe655cad9b1 Author: vromero Date: 2013-06-11 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7fe655cad9b1 8007907: javap, method com.sun.tools.javap.Main.run returns 0 even in case of class not found error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/JavapTask.java ! test/tools/javac/constDebug/ConstDebugTest.java ! test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java + test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java ! test/tools/javap/T4777949.java ! test/tools/javap/T7190862.java Changeset: 6b48ebae2569 Author: vromero Date: 2013-06-14 16:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6b48ebae2569 8016569: javac, add new flag for polymorphic method signatures Reviewed-by: jjg 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/Symbol.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/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: 1936a884b290 Author: vromero Date: 2013-06-14 18:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1936a884b290 8008023: Get rid of utf8 chars in two tests Reviewed-by: jjg ! test/tools/javac/api/6437999/Utf8.java ! test/tools/javac/api/T6306137.java Changeset: 1eb09dba594a Author: lana Date: 2013-06-16 22:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1eb09dba594a Merge Changeset: b7a10bc02e7a Author: darcy Date: 2013-06-17 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b7a10bc02e7a 8016779: Fix doclint warnings in javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/ElementScanner8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java Changeset: 455be95bd1b5 Author: rfield Date: 2013-06-17 20:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/455be95bd1b5 8013789: Compiler should emit bridges in interfaces Summary: paired with 8015402: Lambda metafactory should not attempt to determine bridge methods Reviewed-by: vromero Contributed-by: maurizio.cimadamore at oracle.com ! 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/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java Changeset: e701af23a095 Author: vromero Date: 2013-06-18 18:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e701af23a095 8016607: javac, avoid analyzing lambdas for source 7 compilation Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 9851071b551a Author: vromero Date: 2013-06-18 19:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9851071b551a 8016267: javac, TypeTag refactoring has provoked performance issues Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.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/Infer.java Changeset: 4d4818b6df72 Author: chegar Date: 2013-04-24 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4d4818b6df72 Merge Changeset: 27cda5134748 Author: chegar Date: 2013-04-28 08:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/27cda5134748 Merge Changeset: c7c6bfe7fc1f Author: bpatel Date: 2013-05-03 08:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c7c6bfe7fc1f 8012375: Improve Javadoc framing Reviewed-by: mduigou, jlaskey ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java Changeset: 8074ccd57d89 Author: chegar Date: 2013-05-08 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8074ccd57d89 Merge Changeset: 9d7d36e6927c Author: chegar Date: 2013-05-08 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9d7d36e6927c Merge Changeset: 7ee1fd365cdd Author: chegar Date: 2013-05-16 11:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7ee1fd365cdd Merge Changeset: f1b90ea7d402 Author: chegar Date: 2013-05-23 12:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f1b90ea7d402 Merge - src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java - src/share/classes/javax/tools/annotation/GenerateNativeHeader.java - test/tools/javac/nativeHeaders/javahComparison/TestClass2.java - test/tools/javac/nativeHeaders/javahComparison/TestClass3.java Changeset: 76d08c649607 Author: chegar Date: 2013-05-31 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/76d08c649607 Merge Changeset: 536cad596942 Author: bpatel Date: 2013-06-07 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/536cad596942 8015997: Additional improvement in Javadoc framing Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java Changeset: da8d0ee0938e Author: chegar Date: 2013-06-10 09:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/da8d0ee0938e Merge - test/tools/javac/HiddenAbstractMethod/Test - test/tools/javac/NonAmbiguousField/Test Changeset: cc89c8333127 Author: chegar Date: 2013-06-11 09:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cc89c8333127 Merge Changeset: 31e1151ef3cc Author: chegar Date: 2013-06-17 11:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/31e1151ef3cc Merge Changeset: db6bf740a578 Author: chegar Date: 2013-06-18 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/db6bf740a578 Merge Changeset: 64f511787fd9 Author: chegar Date: 2013-06-18 20:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/64f511787fd9 Merge Changeset: 792c40d5185a Author: mfang Date: 2013-06-18 20:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/792c40d5185a 8015657: jdk8 l10n resource file translation update 3 Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties + src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties + src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties + src/share/classes/com/sun/tools/javap/resources/javap_ja.properties + src/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties + src/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties + src/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties Changeset: 6d3b33aea370 Author: vromero Date: 2013-06-19 11:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6d3b33aea370 8006981: javac, method toString() of class ...javac.code.Flags doesn't print all the flag bits Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: be62183f938a Author: chegar Date: 2013-06-19 11:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/be62183f938a 8017045: anti-delta fix for 8013789 Reviewed-by: alanb ! 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/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java Changeset: 29dcd6715b04 Author: chegar Date: 2013-06-19 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/29dcd6715b04 Merge ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: be10ac0081b2 Author: vromero Date: 2013-06-19 22:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/be10ac0081b2 8016610: javac, add new internal symbols to make operator resolution faster Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java Changeset: b3458329d060 Author: lana Date: 2013-06-24 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b3458329d060 Merge Changeset: 988aef3a8c3a Author: katleman Date: 2013-06-26 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/988aef3a8c3a 8016684: JDK8 b94 source with GPL header errors Reviewed-by: tbell, darcy ! test/tools/javac/6567415/T6567415.java Changeset: 6a11a81a8824 Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6a11a81a8824 Added tag jdk8-b96 for changeset 988aef3a8c3a ! .hgtags From alejandro.murillo at oracle.com Fri Jun 28 05:08:18 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 28 Jun 2013 12:08:18 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130628120828.2AE4948639@hg.openjdk.java.net> Changeset: 8c0bb41c24b2 Author: katleman Date: 2013-06-27 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8c0bb41c24b2 Added tag jdk7u40-b31 for changeset 645b68762a36 ! .hgtags Changeset: 2417fa1acf2b Author: amurillo Date: 2013-06-28 00:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2417fa1acf2b Merge - test/compiler/8011901/Test8011901.java Changeset: 9658c969b7cf Author: amurillo Date: 2013-06-28 00:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9658c969b7cf Added tag hs24-b51 for changeset 2417fa1acf2b ! .hgtags From tomas.hurka at googlemail.com Fri Jun 28 06:29:06 2013 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Fri, 28 Jun 2013 15:29:06 +0200 Subject: RFR: 8009204 : [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris Message-ID: <7CA026FE-AD1B-4A09-9312-3AE4C3C85977@googlemail.com> Hi All, I would like to ask for review of JDK-8009204 Description of the problem: jstack() returns corrupted method signatures on Solaris. The issue can be easily reproduce using the following DTrace script: dtrace -x jstackstrsize=2048 -Z \ -n 'hotspot_jni$target::: /0/{}' \ -n 'syscall::write:entry /pid==$target/{jstack(1024)}' \ -c 'java -version' With Java 6, the output is roughly: java/io/FileOutputStream.writeBytes([BII)V java/io/FileOutputStream.write([BII)V java/io/BufferedOutputStream.flushBuffer()V java/io/BufferedOutputStream.flush()V java/io/PrintStream.write([BII)V With Java 7 and Java 8, the output is roughly: java/io/FileOutputStream.riteBytes java/io/FileOutputStream.rite java/io/BufferedOutputStream.lushBuffer java/io/BufferedOutputStream.lush java/io/PrintStream.rite Evaluation: The problem is caused by SymbolTable changes JDK-6990754. jhelper.d was never updated with changes for CPSlot, so the low bit of the address of the Symbol is set, which causes the off by 1-ness of the output. The klass name uses a untagged constant pool entry, which is why it doesn't have the problem in the output. There is a very similar bug JDK-7019165 reported against pstack output and the proposed fix is basically backport of JDK-7019165 to jhelper.d. Webrev: I tested the fix using above D-script on latest JDK 8 and JDK 7u sources. Thanks, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.java.net Software Developer Oracle, Praha Czech Republic From coleen.phillimore at oracle.com Fri Jun 28 08:09:05 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Jun 2013 11:09:05 -0400 Subject: RFR: 8009204 : [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris In-Reply-To: <7CA026FE-AD1B-4A09-9312-3AE4C3C85977@googlemail.com> References: <7CA026FE-AD1B-4A09-9312-3AE4C3C85977@googlemail.com> Message-ID: <51CDA711.3050207@oracle.com> Tomas, This looks good. Does pstack work? Is the libjvm_db.c file still correct? I thought I'd fixed this once but apparently not. Is there a way to write a test for this for jtreg? Thanks for doing this, Coleen On 6/28/2013 9:29 AM, Tomas Hurka wrote: > Hi All, > I would like to ask for review of JDK-8009204 > > Description of the problem: > jstack() returns corrupted method signatures on Solaris. The issue can be easily reproduce using the following DTrace script: > > dtrace -x jstackstrsize=2048 -Z \ > -n 'hotspot_jni$target::: /0/{}' \ > -n 'syscall::write:entry /pid==$target/{jstack(1024)}' \ > -c 'java -version' > > With Java 6, the output is roughly: > > java/io/FileOutputStream.writeBytes([BII)V > java/io/FileOutputStream.write([BII)V > java/io/BufferedOutputStream.flushBuffer()V > java/io/BufferedOutputStream.flush()V > java/io/PrintStream.write([BII)V > > With Java 7 and Java 8, the output is roughly: > > java/io/FileOutputStream.riteBytes > java/io/FileOutputStream.rite > java/io/BufferedOutputStream.lushBuffer > java/io/BufferedOutputStream.lush > java/io/PrintStream.rite > > Evaluation: > The problem is caused by SymbolTable changes JDK-6990754. jhelper.d was never updated with changes for CPSlot, so the low bit of the address of the Symbol is set, which causes the off by 1-ness of the output. The klass name uses a untagged constant pool entry, which is why it doesn't have the problem in the output. There is a very similar bug JDK-7019165 reported against pstack output and the proposed fix is basically backport of JDK-7019165 to jhelper.d. > > Webrev: > > > I tested the fix using above D-script on latest JDK 8 and JDK 7u sources. > > Thanks, > -- > Tomas Hurka > NetBeans Profiler http://profiler.netbeans.org > VisualVM http://visualvm.java.net > Software Developer > Oracle, Praha Czech Republic > From alejandro.murillo at oracle.com Fri Jun 28 08:52:24 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 28 Jun 2013 15:52:24 +0000 Subject: hg: hsx/hsx25/hotspot: 41 new changesets Message-ID: <20130628155359.A448D4864A@hg.openjdk.java.net> Changeset: f75faf51e8c4 Author: hseigel Date: 2013-03-07 11:49 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f75faf51e8c4 7158805: Better rewriting of nested subroutine calls Reviewed-by: mschoene, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/oops/generateOopMap.cpp Changeset: b295e132102d Author: mullan Date: 2013-04-05 10:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b295e132102d 8001330: Improve on checking order Reviewed-by: acorn, hawtin ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: be131aa5a529 Author: mullan Date: 2013-04-22 08:33 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/be131aa5a529 8011896: Add check for invalid offset for new AccessControlContext isAuthorized field Reviewed-by: acorn ! src/share/vm/classfile/javaClasses.cpp Changeset: 3463b5b373f7 Author: chegar Date: 2013-04-24 10:17 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3463b5b373f7 Merge Changeset: f822ecf621ce Author: chegar Date: 2013-04-28 08:15 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f822ecf621ce Merge Changeset: 4b52137b07c9 Author: chegar Date: 2013-05-01 14:11 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4b52137b07c9 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp Changeset: 7ee0d5c53c78 Author: chegar Date: 2013-05-08 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ee0d5c53c78 Merge - agent/doc/c2replay.html ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: cb92413c6934 Author: chegar Date: 2013-05-16 11:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cb92413c6934 Merge ! src/share/vm/classfile/vmSymbols.hpp Changeset: ce9ecec70f99 Author: chegar Date: 2013-05-23 12:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ce9ecec70f99 Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: 0861193d358a Author: chegar Date: 2013-05-31 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0861193d358a Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: eaf3742822ec Author: chegar Date: 2013-06-17 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/eaf3742822ec Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jvm.cpp Changeset: 3a0774193f71 Author: chegar Date: 2013-06-19 11:02 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a0774193f71 Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp - src/share/vm/trace/traceEventTypes.hpp Changeset: 38e483cb1bcd Author: lana Date: 2013-06-24 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/38e483cb1bcd Merge Changeset: 9f3e3245b50f Author: amurillo Date: 2013-06-25 12:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9f3e3245b50f Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jvm.cpp Changeset: e6a4b8c71fa6 Author: katleman Date: 2013-06-26 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e6a4b8c71fa6 8017323: JDK8 b95 source with GPL header errors Reviewed-by: tbell, darcy ! src/share/vm/memory/referenceProcessorStats.hpp Changeset: b6d1e42655cd Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b6d1e42655cd Added tag jdk8-b96 for changeset e6a4b8c71fa6 ! .hgtags Changeset: fc8a1a5de78e Author: amurillo Date: 2013-06-21 00:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fc8a1a5de78e 8017253: new hotspot build - hs25-b39 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 91acb82a8b7a Author: dholmes Date: 2013-06-19 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/91acb82a8b7a 8014326: [OSX] All libjvm symbols are exported Summary: Add support for a MacOS X compatible form of the libjvm mapfile. Reviewed-by: dcubed, rdurbin, coleenp ! make/bsd/makefiles/build_vm_def.sh ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product Changeset: b9f4c4ec0f50 Author: iklam Date: 2013-06-19 20:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b9f4c4ec0f50 8008964: NPG: Memory regression: Thread::_metadata_handles uses 1 KB per thread. Summary: Reduce default size of Thread::_metadata_handles from 300 to 30 Reviewed-by: coleenp, sspitsyn ! src/share/vm/runtime/thread.cpp Changeset: b3cd8b58b798 Author: mgronlun Date: 2013-06-20 11:53 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b3cd8b58b798 8016735: Remove superfluous EnableInvokeDynamic warning from UnlockDiagnosticVMOptions check Reviewed-by: sla, dholmes ! src/share/vm/runtime/globals.cpp Changeset: 9ba41a4a71ff Author: coleenp Date: 2013-06-21 10:50 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9ba41a4a71ff 8004124: Handle and/or warn about SI_KERNEL Summary: Detect this crash in the signal handler and give a fatal error message instead of making us chase down bugs that don't reproduce Reviewed-by: kvn, mgerdin, dholmes ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: bed34a7a3b9b Author: coleenp Date: 2013-06-21 10:57 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bed34a7a3b9b 8017177: more explicit code location information in hs_err crash log Summary: Add code pc location for compiled code Reviewed-by: kvn, coleenp Contributed-by: doug.simon at oracle.com ! src/share/vm/runtime/frame.cpp Changeset: bb6c7f2f10fd Author: dcubed Date: 2013-06-21 08:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bb6c7f2f10fd Merge Changeset: b7bc7c94b4b5 Author: dcubed Date: 2013-06-21 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b7bc7c94b4b5 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: d9eed26d638a Author: iklam Date: 2013-06-23 22:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d9eed26d638a 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes Summary: Added Atomic::inc(short*) to support this change. Reviewed-by: coleenp, dcubed, dholmes, minqi ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: e0c9a1d29eb4 Author: coleenp Date: 2013-06-24 18:55 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e0c9a1d29eb4 8016325: JVM hangs verifying system dictionary Summary: Minimize redundant verifications of Klasses. Reviewed-by: hseigel, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/shark/sharkBuilder.cpp Changeset: 01e10b366055 Author: sla Date: 2013-06-25 14:11 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/01e10b366055 8017561: Build errors caused by missing .PHONY Reviewed-by: stefank, brutisso ! make/excludeSrc.make Changeset: feae15578b2f Author: tamao Date: 2013-06-07 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/feae15578b2f 7122222: GC log is limited to 2G for 32-bit Summary: Enable large file support for generated 32-bit ostream.o on Linux and Solaris (as only the two need this) by setting -D_FILE_OFFSET_BITS=64 in compilation Reviewed-by: tbell, mgerdin, dcubed Contributed-by: tamao ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/os/solaris/vm/os_solaris.inline.hpp Changeset: df7e1c0e3dc1 Author: jmasa Date: 2013-06-25 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/df7e1c0e3dc1 8014546: MetaspaceAux print_metaspace_change() should print "used" after GC not capacity Reviewed-by: johnc, tschatzl ! src/share/vm/memory/metaspace.cpp Changeset: f99cd6e20ab1 Author: jmasa Date: 2013-06-25 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f99cd6e20ab1 8014851: UseAdaptiveGCBoundary is broken Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp + test/gc/parallelScavenge/AdaptiveGCBoundary.java Changeset: 71963b3f802a Author: ehelin Date: 2013-06-26 16:58 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/71963b3f802a 8013590: NPG: Add a memory pool MXBean for Metaspace Reviewed-by: jmasa, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/metaspace/TestMetaspaceMemoryPool.java Changeset: f8972b867ded Author: ehelin Date: 2013-06-27 10:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f8972b867ded Merge Changeset: 7875ea94bea5 Author: goetz Date: 2013-06-24 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7875ea94bea5 8017308: Remove unused breakpoint relocation type Summary: remove unused breakpoint relocation type Reviewed-by: kvn ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: cc63bcb47cce Author: twisti Date: 2013-06-24 17:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cc63bcb47cce 8017538: Clang support broke slowdebug build for i586 Reviewed-by: kvn ! make/linux/makefiles/gcc.make Changeset: a023da4ffc15 Author: twisti Date: 2013-06-24 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a023da4ffc15 Merge Changeset: 3aa636f2a743 Author: adlertz Date: 2013-06-25 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3aa636f2a743 8017243: 8001345 is incomplete Summary: Replaces unused decodeN at MemBarAcquire with its corresponding loadN if loadN is used at more than one place. Reviewed-by: kvn, twisti ! src/share/vm/opto/memnode.cpp Changeset: 9347cae673f0 Author: adlertz Date: 2013-06-26 00:40 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9347cae673f0 8017510: Add a regression test for 8005956 Summary: Regression test for 8005956 Reviewed-by: kvn, twisti + test/compiler/8005956/PolynomialRoot.java Changeset: 6a0ead6dc6db Author: goetz Date: 2013-06-24 16:11 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6a0ead6dc6db 8017531: 8010460 changes broke bytecodeInterpreter.cpp Summary: Replace _indy by _jsr292 and also fix VERIFY_OOP macros. Reviewed-by: kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: be0600ec1102 Author: kvn Date: 2013-06-27 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/be0600ec1102 Merge Changeset: 2b9380b0bf0b Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2b9380b0bf0b Merge ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp Changeset: d197d377ab2e Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d197d377ab2e Added tag hs25-b39 for changeset 2b9380b0bf0b ! .hgtags From alejandro.murillo at oracle.com Fri Jun 28 12:26:12 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 28 Jun 2013 19:26:12 +0000 Subject: hg: hsx/hsx24/hotspot: 8019298: new hotspot build - hs24-b52 Message-ID: <20130628192621.42B5F4865C@hg.openjdk.java.net> Changeset: 4ebc4781f877 Author: amurillo Date: 2013-06-28 00:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4ebc4781f877 8019298: new hotspot build - hs24-b52 Reviewed-by: jcoomes ! make/hotspot_version From jon.masamitsu at oracle.com Fri Jun 28 14:22:48 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Jun 2013 14:22:48 -0700 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51CCE381.9010503@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> <51C89367.3080708@oracle.com> <51C8B428.3090507@oracle.com> <51CCE381.9010503@oracle.com> Message-ID: <51CDFEA8.2060800@oracle.com> Coleen, http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/memory/metaspace.cpp.frames.html > 1301 // The reason for someone using this flag is to limit reserved space. So > 1302 // for non-class virtual space that is what we compare against. For class > 1303 // virtual space, we only compare against the used space, not reserved space, > 1304 // because this is a larger region prereserved for compressed class pointers. > 1305 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { > 1306 size_t real_allocated = Metaspace::space_list()->virtual_space_total() + > 1307 Metaspace::class_space_list()->used_words_sum() * BytesPerWord; > 1308 if (real_allocated >= MaxMetaspaceSize) { > 1309 return false; > 1310 } > 1311 } At line 1307 the function used_words_sum() iterated over the virtual spaces. There are usually not that many virtual spaces but I think the iteration should still be avoided. I think you should use MetaspaceAux::allocated_capacity_bytes() In a virtual space any space that has been allocated to a Metaspace is considered "used". Not all that space holds Metadata yet. I think that corresponds to the "allocated_capacity_bytes()" above. That is the running sum (i.e. fast) of bytes allocated to a Metaspace. The allocated capacity also does not necessarily hold Metadata yet. The other choice would be MetaspaceAux::allocated_used_bytes() which is a running sum of the space which holds Metadata. Though it is a "used" quantity, I think it is different than the way "used" is in "used_words_sum". " used_words_sum()" should probably be renamed "allocated_words_sum()". But that's another clean up. http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/runtime/vmStructs.cpp.frames.html Why the delete of entries and not changing perm to Metadata named variables? I'm not challenging your change, just trying to learn about such things. Jon On 6/27/2013 6:14 PM, Coleen Phillimore wrote: > > Hi, I have made a few changes to this changeset. I reverted the > special case for application class loader until we have more tuning > information to decide how large this metaspace should be. I also > fixed the check in should_expand so that if you specify > MaxMetaspaceSize, it compares the MaxMetaspaceSize to (reserved for > data space + used for class space). So the test in the bug report > runs with the smaller sizes for MaxMetaspaceSize and also for smaller > ClassMetaspaceSize without hitting OOM for either sort of space. > Hope the comment there is clear. > > http://cr.openjdk.java.net/~coleenp/8015391_2/ > > > Reran nsk quick testlist and some jtreg tests. Please (re)review. > > Thanks, > Coleen > > On 6/24/2013 5:03 PM, Coleen Phillimore wrote: >> >> On 06/24/2013 02:43 PM, Jon Masamitsu wrote: >>> >>> On 6/24/13 11:23 AM, Coleen Phillimore wrote: >>>> >>>> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >>>>> >>>>> >>>>>> 2673 size_t specialized_count = 0, small_count = 0, >>>>>> medium_count = 0, large_count = 0; >>>>>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, >>>>>> cls_medium_count = 0, cls_large_count = 0; >>>>> >>>>> Not introduced by your change but >>>>> >>>>> humongous_count instead of large_count >>>>> and >>>>> cls_humongous_count instead of cls_large_count >>>>> >>>>> would be more consistent. >>>> >>>> Yes, it is. I changed it. >>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >>>>> >>>>> >>>>> I'd suggest adding Metaspace::AppClassMetaspaceType >>>>>> 385 } else if >>>>>> (SystemDictionary::is_app_class_loader(class_loader())) { >>>>>> 386 if (TraceClassLoaderData && Verbose && class_loader() >>>>>> != NULL) { >>>>>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class >>>>>> loader"); >>>>>> 388 } >>>>>> 389 set_metaspace(new Metaspace(_metaspace_lock, >>>>>> Metaspace::BootMetaspaceType)); >>>>> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >>>>> obvious to me >>>>> that we should always be reserving the same amount of space for >>>>> the AppClassLoader >>>>> as the BootClassLoader. The same default is OK with me. >>>> >>>> Hmm. Ok. I don't like adding new flags, so can I add an >>>> AppMetaspaceType and give it the same initial size as >>>> BootMetaspaceSize until proven that it doesn't need to be the same >>>> size. >>> >>> With the BootClassLoader the space for the initial Metaspace is >>> committed >>> when the first system class is loaded. The same would be true for any >>> Java application (all have some type of AppLoader, right)? We know >>> we're >>> going to use the space committed for the BootClassLoader Metaspace. >>> Are >>> we going to get yelled at for committing 4m and not using it. >>>> >>>> I suppose adding an AppMetaspaceInitialSize flag will give me more >>>> to talk about at the Permgen Elimination JavaOne talk though (but >>>> I'd still rather not). >>> >>> When you have 100000000000000000 flags, who's going to >>> notice the 100000000000000001-st :-) >> >> Okay, you convinced me to revert this part of the change. It wasn't >> necessary to make this stress test finish and there hasn't been very >> much tuning for "normal" application classes, just a suspicion of mine. >> >> Committing an extra 4m might be bad for embedded platforms. >> >> Thanks, >> Coleen >> >>> >>> Jon >>>> >>>> Coleen >>>> >>>>> >>>>> Rest looks good. >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>>>>> Summary: Allocate medium chunks for class metaspace when class >>>>>> loader has lots of classes >>>>>> >>>>>> I originally made class metaspace keep small chunks and not start >>>>>> allocating from medium chunks, because I thought with only Klass >>>>>> objects, small chunks is enough. This test has a large set of >>>>>> class loaders who have a lot of classes, so allocated thousands >>>>>> of small chunks each. Class loaders with that many classes should >>>>>> start allocating from medium chunks, for class metaspace. >>>>>> >>>>>> I also increased the ClassMediumChunk size to 4k and measured a >>>>>> lot less fragmentation waste than 1K or 2K for this test. >>>>>> Lastly, the AppClassLoader instance should have as large of an >>>>>> initial metaspace as the bootclass loader. >>>>>> >>>>>> Tested with vm.quick.testlist and the failing test. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>>>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>> >>>> >>> >> > From alejandro.murillo at oracle.com Fri Jun 28 14:33:43 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 28 Jun 2013 21:33:43 +0000 Subject: hg: hsx/hotspot-main/hotspot: 19 new changesets Message-ID: <20130628213433.9328348664@hg.openjdk.java.net> Changeset: f75faf51e8c4 Author: hseigel Date: 2013-03-07 11:49 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f75faf51e8c4 7158805: Better rewriting of nested subroutine calls Reviewed-by: mschoene, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/oops/generateOopMap.cpp Changeset: b295e132102d Author: mullan Date: 2013-04-05 10:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b295e132102d 8001330: Improve on checking order Reviewed-by: acorn, hawtin ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: be131aa5a529 Author: mullan Date: 2013-04-22 08:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be131aa5a529 8011896: Add check for invalid offset for new AccessControlContext isAuthorized field Reviewed-by: acorn ! src/share/vm/classfile/javaClasses.cpp Changeset: 3463b5b373f7 Author: chegar Date: 2013-04-24 10:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3463b5b373f7 Merge Changeset: f822ecf621ce Author: chegar Date: 2013-04-28 08:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f822ecf621ce Merge Changeset: 4b52137b07c9 Author: chegar Date: 2013-05-01 14:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4b52137b07c9 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp Changeset: 7ee0d5c53c78 Author: chegar Date: 2013-05-08 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ee0d5c53c78 Merge - agent/doc/c2replay.html ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: cb92413c6934 Author: chegar Date: 2013-05-16 11:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cb92413c6934 Merge ! src/share/vm/classfile/vmSymbols.hpp Changeset: ce9ecec70f99 Author: chegar Date: 2013-05-23 12:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce9ecec70f99 Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: 0861193d358a Author: chegar Date: 2013-05-31 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0861193d358a Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: eaf3742822ec Author: chegar Date: 2013-06-17 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eaf3742822ec Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jvm.cpp Changeset: 3a0774193f71 Author: chegar Date: 2013-06-19 11:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a0774193f71 Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp - src/share/vm/trace/traceEventTypes.hpp Changeset: 38e483cb1bcd Author: lana Date: 2013-06-24 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/38e483cb1bcd Merge Changeset: 9f3e3245b50f Author: amurillo Date: 2013-06-25 12:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9f3e3245b50f Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jvm.cpp Changeset: e6a4b8c71fa6 Author: katleman Date: 2013-06-26 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e6a4b8c71fa6 8017323: JDK8 b95 source with GPL header errors Reviewed-by: tbell, darcy ! src/share/vm/memory/referenceProcessorStats.hpp Changeset: b6d1e42655cd Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b6d1e42655cd Added tag jdk8-b96 for changeset e6a4b8c71fa6 ! .hgtags Changeset: 2b9380b0bf0b Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2b9380b0bf0b Merge ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp Changeset: d197d377ab2e Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d197d377ab2e Added tag hs25-b39 for changeset 2b9380b0bf0b ! .hgtags Changeset: 8c4424890028 Author: amurillo Date: 2013-06-28 02:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8c4424890028 8019302: new hotspot build - hs25-b40 Reviewed-by: jcoomes ! make/hotspot_version From tomas.hurka at googlemail.com Fri Jun 28 15:03:24 2013 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Sat, 29 Jun 2013 00:03:24 +0200 Subject: RFR: 8009204 : [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris In-Reply-To: <51CDA711.3050207@oracle.com> References: <7CA026FE-AD1B-4A09-9312-3AE4C3C85977@googlemail.com> <51CDA711.3050207@oracle.com> Message-ID: <038CC3C4-7BF5-44B5-98E1-A9EAF685A8BD@googlemail.com> Hi Coleen, thanks a lot for review. pstack works fine. I can try to write a test, but first I need similar one. Is there a similar test for pstack? Are there any tests using dtrace? On 28 Jun 2013, at 17:09, Coleen Phillimore wrote: > This looks good. Does pstack work? Is the libjvm_db.c file still correct? I thought I'd fixed this once but apparently not. Is there a way to write a test for this for jtreg? > > Thanks for doing this, > Coleen > > On 6/28/2013 9:29 AM, Tomas Hurka wrote: >> Hi All, >> I would like to ask for review of JDK-8009204 >> >> Description of the problem: >> jstack() returns corrupted method signatures on Solaris. The issue can be easily reproduce using the following DTrace script: >> >> dtrace -x jstackstrsize=2048 -Z \ >> -n 'hotspot_jni$target::: /0/{}' \ >> -n 'syscall::write:entry /pid==$target/{jstack(1024)}' \ >> -c 'java -version' >> >> With Java 6, the output is roughly: >> >> java/io/FileOutputStream.writeBytes([BII)V >> java/io/FileOutputStream.write([BII)V >> java/io/BufferedOutputStream.flushBuffer()V >> java/io/BufferedOutputStream.flush()V >> java/io/PrintStream.write([BII)V >> >> With Java 7 and Java 8, the output is roughly: >> >> java/io/FileOutputStream.riteBytes >> java/io/FileOutputStream.rite >> java/io/BufferedOutputStream.lushBuffer >> java/io/BufferedOutputStream.lush >> java/io/PrintStream.rite >> >> Evaluation: >> The problem is caused by SymbolTable changes JDK-6990754. jhelper.d was never updated with changes for CPSlot, so the low bit of the address of the Symbol is set, which causes the off by 1-ness of the output. The klass name uses a untagged constant pool entry, which is why it doesn't have the problem in the output. There is a very similar bug JDK-7019165 reported against pstack output and the proposed fix is basically backport of JDK-7019165 to jhelper.d. >> >> Webrev: >> >> >> I tested the fix using above D-script on latest JDK 8 and JDK 7u sources. >> Thanks, >> -- >> Tomas Hurka >> NetBeans Profiler http://profiler.netbeans.org >> VisualVM http://visualvm.java.net >> Software Developer >> Oracle, Praha Czech Republic >> > -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.java.net Software Developer Oracle, Praha Czech Republic From coleen.phillimore at oracle.com Fri Jun 28 15:17:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Jun 2013 18:17:39 -0400 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51CDFEA8.2060800@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> <51C89367.3080708@oracle.com> <51C8B428.3090507@oracle.com> <51CCE381.9010503@oracle.com> <51CDFEA8.2060800@oracle.com> Message-ID: <51CE0B83.90500@oracle.com> Thanks Jon! Comments inline. On 6/28/2013 5:22 PM, Jon Masamitsu wrote: > Coleen, > > http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/memory/metaspace.cpp.frames.html > >> 1301 // The reason for someone using this flag is to limit reserved >> space. So >> 1302 // for non-class virtual space that is what we compare >> against. For class >> 1303 // virtual space, we only compare against the used space, not >> reserved space, >> 1304 // because this is a larger region prereserved for compressed >> class pointers. >> 1305 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >> 1306 size_t real_allocated = >> Metaspace::space_list()->virtual_space_total() + >> 1307 Metaspace::class_space_list()->used_words_sum() * BytesPerWord; >> 1308 if (real_allocated >= MaxMetaspaceSize) { >> 1309 return false; >> 1310 } >> 1311 } > > At line 1307 the function used_words_sum() iterated over the virtual > spaces. > There are usually not that many virtual spaces but I think the iteration > should still be avoided. I think you should use > > MetaspaceAux::allocated_capacity_bytes() > > In a virtual space any space that has been allocated to a Metaspace is > considered "used". > Not all that space holds Metadata yet. I think that corresponds to > the "allocated_capacity_bytes()" > above. That is the running sum (i.e. fast) of bytes allocated to a > Metaspace. The allocated capacity > also does not necessarily hold Metadata yet. The other choice would be > MetaspaceAux::allocated_used_bytes() which is a running sum of the > space which > holds Metadata. Though it is a "used" quantity, I think it is > different than the > way "used" is in "used_words_sum". " used_words_sum()" should probably > be renamed "allocated_words_sum()". But that's another clean up. You must have sent this new code to hotspot-gc when I wasn't watching. I didn't notice the different running counts. So allocated_capacity_bytes(Metaspace::ClassType) is how much space has been allocated for chunks in the class metaspace. allocated_used_bytes() is the running count of returned for class types. I think for comparison purposes to MaxMetaspaceSize, we want capacity_bytes() because that's what is committed in the class virtual space. So we use reserved(data_space) + committed(class_space) to determine if the MaxMetaspaceSize is reached. I updated the comment also (and reran the tests). See version 3 http://cr.openjdk.java.net/~coleenp/8015391_3/ > > http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/runtime/vmStructs.cpp.frames.html > > > Why the delete of entries and not changing perm to Metadata named > variables? I'm not > challenging your change, just trying to learn about such things. We pass these objects to the serviceability agent but it never used them, so I decided to not pass these things. The SA doesn't need to know which exceptions we've preallocated. Coleen > > Jon > > > > > On 6/27/2013 6:14 PM, Coleen Phillimore wrote: >> >> Hi, I have made a few changes to this changeset. I reverted the >> special case for application class loader until we have more tuning >> information to decide how large this metaspace should be. I also >> fixed the check in should_expand so that if you specify >> MaxMetaspaceSize, it compares the MaxMetaspaceSize to (reserved for >> data space + used for class space). So the test in the bug report >> runs with the smaller sizes for MaxMetaspaceSize and also for smaller >> ClassMetaspaceSize without hitting OOM for either sort of space. >> Hope the comment there is clear. >> >> http://cr.openjdk.java.net/~coleenp/8015391_2/ >> >> >> Reran nsk quick testlist and some jtreg tests. Please (re)review. >> >> Thanks, >> Coleen >> >> On 6/24/2013 5:03 PM, Coleen Phillimore wrote: >>> >>> On 06/24/2013 02:43 PM, Jon Masamitsu wrote: >>>> >>>> On 6/24/13 11:23 AM, Coleen Phillimore wrote: >>>>> >>>>> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >>>>>> >>>>>> >>>>>>> 2673 size_t specialized_count = 0, small_count = 0, >>>>>>> medium_count = 0, large_count = 0; >>>>>>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, >>>>>>> cls_medium_count = 0, cls_large_count = 0; >>>>>> >>>>>> Not introduced by your change but >>>>>> >>>>>> humongous_count instead of large_count >>>>>> and >>>>>> cls_humongous_count instead of cls_large_count >>>>>> >>>>>> would be more consistent. >>>>> >>>>> Yes, it is. I changed it. >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >>>>>> >>>>>> >>>>>> I'd suggest adding Metaspace::AppClassMetaspaceType >>>>>>> 385 } else if >>>>>>> (SystemDictionary::is_app_class_loader(class_loader())) { >>>>>>> 386 if (TraceClassLoaderData && Verbose && >>>>>>> class_loader() != NULL) { >>>>>>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class >>>>>>> loader"); >>>>>>> 388 } >>>>>>> 389 set_metaspace(new Metaspace(_metaspace_lock, >>>>>>> Metaspace::BootMetaspaceType)); >>>>>> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >>>>>> obvious to me >>>>>> that we should always be reserving the same amount of space for >>>>>> the AppClassLoader >>>>>> as the BootClassLoader. The same default is OK with me. >>>>> >>>>> Hmm. Ok. I don't like adding new flags, so can I add an >>>>> AppMetaspaceType and give it the same initial size as >>>>> BootMetaspaceSize until proven that it doesn't need to be the same >>>>> size. >>>> >>>> With the BootClassLoader the space for the initial Metaspace is >>>> committed >>>> when the first system class is loaded. The same would be true for any >>>> Java application (all have some type of AppLoader, right)? We know >>>> we're >>>> going to use the space committed for the BootClassLoader >>>> Metaspace. Are >>>> we going to get yelled at for committing 4m and not using it. >>>>> >>>>> I suppose adding an AppMetaspaceInitialSize flag will give me more >>>>> to talk about at the Permgen Elimination JavaOne talk though (but >>>>> I'd still rather not). >>>> >>>> When you have 100000000000000000 flags, who's going to >>>> notice the 100000000000000001-st :-) >>> >>> Okay, you convinced me to revert this part of the change. It >>> wasn't necessary to make this stress test finish and there hasn't >>> been very much tuning for "normal" application classes, just a >>> suspicion of mine. >>> >>> Committing an extra 4m might be bad for embedded platforms. >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Jon >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Rest looks good. >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>>>>>> Summary: Allocate medium chunks for class metaspace when class >>>>>>> loader has lots of classes >>>>>>> >>>>>>> I originally made class metaspace keep small chunks and not >>>>>>> start allocating from medium chunks, because I thought with only >>>>>>> Klass objects, small chunks is enough. This test has a large >>>>>>> set of class loaders who have a lot of classes, so allocated >>>>>>> thousands of small chunks each. Class loaders with that many >>>>>>> classes should start allocating from medium chunks, for class >>>>>>> metaspace. >>>>>>> >>>>>>> I also increased the ClassMediumChunk size to 4k and measured a >>>>>>> lot less fragmentation waste than 1K or 2K for this test. >>>>>>> Lastly, the AppClassLoader instance should have as large of an >>>>>>> initial metaspace as the bootclass loader. >>>>>>> >>>>>>> Tested with vm.quick.testlist and the failing test. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>>>>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Fri Jun 28 15:37:34 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Jun 2013 15:37:34 -0700 Subject: RFR 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadat, a space could occur when metaspace is almost empty In-Reply-To: <51CE0B83.90500@oracle.com> References: <51C32D25.8050408@oracle.com> <51C885E0.3000801@oracle.com> <51C88EA0.9090208@oracle.com> <51C89367.3080708@oracle.com> <51C8B428.3090507@oracle.com> <51CCE381.9010503@oracle.com> <51CDFEA8.2060800@oracle.com> <51CE0B83.90500@oracle.com> Message-ID: <51CE102E.30605@oracle.com> On 6/28/2013 3:17 PM, Coleen Phillimore wrote: > > Thanks Jon! Comments inline. > > On 6/28/2013 5:22 PM, Jon Masamitsu wrote: >> Coleen, >> >> http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/memory/metaspace.cpp.frames.html >> >>> 1301 // The reason for someone using this flag is to limit >>> reserved space. So >>> 1302 // for non-class virtual space that is what we compare >>> against. For class >>> 1303 // virtual space, we only compare against the used space, not >>> reserved space, >>> 1304 // because this is a larger region prereserved for compressed >>> class pointers. >>> 1305 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>> 1306 size_t real_allocated = >>> Metaspace::space_list()->virtual_space_total() + >>> 1307 Metaspace::class_space_list()->used_words_sum() * BytesPerWord; >>> 1308 if (real_allocated >= MaxMetaspaceSize) { >>> 1309 return false; >>> 1310 } >>> 1311 } >> >> At line 1307 the function used_words_sum() iterated over the virtual >> spaces. >> There are usually not that many virtual spaces but I think the iteration >> should still be avoided. I think you should use >> >> MetaspaceAux::allocated_capacity_bytes() >> >> In a virtual space any space that has been allocated to a Metaspace >> is considered "used". >> Not all that space holds Metadata yet. I think that corresponds to >> the "allocated_capacity_bytes()" >> above. That is the running sum (i.e. fast) of bytes allocated to a >> Metaspace. The allocated capacity >> also does not necessarily hold Metadata yet. The other choice would be >> MetaspaceAux::allocated_used_bytes() which is a running sum of the >> space which >> holds Metadata. Though it is a "used" quantity, I think it is >> different than the >> way "used" is in "used_words_sum". " used_words_sum()" should probably >> be renamed "allocated_words_sum()". But that's another clean up. > > You must have sent this new code to hotspot-gc when I wasn't > watching. I didn't notice the different running counts. Yes, it went back not too long ago. > So allocated_capacity_bytes(Metaspace::ClassType) is how much space > has been allocated for chunks in the class metaspace. Yes. > allocated_used_bytes() is the running count of returned for class types. If by "returned" you mean returned to the application, yes. > > I think for comparison purposes to MaxMetaspaceSize, we want > capacity_bytes() because that's what is committed in the class virtual > space. So we use reserved(data_space) + committed(class_space) to > determine if the MaxMetaspaceSize is reached. I updated the comment > also (and reran the tests). > > See version 3 > > http://cr.openjdk.java.net/~coleenp/8015391_3/ > Looks good. > >> >> http://cr.openjdk.java.net/~coleenp/8015391_2/src/share/vm/runtime/vmStructs.cpp.frames.html >> >> >> Why the delete of entries and not changing perm to Metadata named >> variables? I'm not >> challenging your change, just trying to learn about such things. > > We pass these objects to the serviceability agent but it never used > them, so I decided to not pass these things. The SA doesn't need to > know which exceptions we've preallocated. Good. Less for me to know also (in terms of what SA has to know). Jon > > Coleen > >> >> Jon >> >> >> >> >> On 6/27/2013 6:14 PM, Coleen Phillimore wrote: >>> >>> Hi, I have made a few changes to this changeset. I reverted the >>> special case for application class loader until we have more tuning >>> information to decide how large this metaspace should be. I also >>> fixed the check in should_expand so that if you specify >>> MaxMetaspaceSize, it compares the MaxMetaspaceSize to (reserved for >>> data space + used for class space). So the test in the bug report >>> runs with the smaller sizes for MaxMetaspaceSize and also for >>> smaller ClassMetaspaceSize without hitting OOM for either sort of >>> space. Hope the comment there is clear. >>> >>> http://cr.openjdk.java.net/~coleenp/8015391_2/ >>> >>> >>> Reran nsk quick testlist and some jtreg tests. Please (re)review. >>> >>> Thanks, >>> Coleen >>> >>> On 6/24/2013 5:03 PM, Coleen Phillimore wrote: >>>> >>>> On 06/24/2013 02:43 PM, Jon Masamitsu wrote: >>>>> >>>>> On 6/24/13 11:23 AM, Coleen Phillimore wrote: >>>>>> >>>>>> On 06/24/2013 01:46 PM, Jon Masamitsu wrote: >>>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/memory/metaspace.cpp.frames.html >>>>>>> >>>>>>> >>>>>>>> 2673 size_t specialized_count = 0, small_count = 0, >>>>>>>> medium_count = 0, large_count = 0; >>>>>>>> 2675 size_t cls_specialized_count = 0, cls_small_count = 0, >>>>>>>> cls_medium_count = 0, cls_large_count = 0; >>>>>>> >>>>>>> Not introduced by your change but >>>>>>> >>>>>>> humongous_count instead of large_count >>>>>>> and >>>>>>> cls_humongous_count instead of cls_large_count >>>>>>> >>>>>>> would be more consistent. >>>>>> >>>>>> Yes, it is. I changed it. >>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8015391/src/share/vm/classfile/classLoaderData.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> I'd suggest adding Metaspace::AppClassMetaspaceType >>>>>>>> 385 } else if >>>>>>>> (SystemDictionary::is_app_class_loader(class_loader())) { >>>>>>>> 386 if (TraceClassLoaderData && Verbose && >>>>>>>> class_loader() != NULL) { >>>>>>>> 387 tty->print_cr("sun/misc/Launcher$AppClassLoader class >>>>>>>> loader"); >>>>>>>> 388 } >>>>>>>> 389 set_metaspace(new Metaspace(_metaspace_lock, >>>>>>>> Metaspace::BootMetaspaceType)); >>>>>>> and adding a flag InitialAppClassLoaderMetaspaceSize. It's not >>>>>>> obvious to me >>>>>>> that we should always be reserving the same amount of space for >>>>>>> the AppClassLoader >>>>>>> as the BootClassLoader. The same default is OK with me. >>>>>> >>>>>> Hmm. Ok. I don't like adding new flags, so can I add an >>>>>> AppMetaspaceType and give it the same initial size as >>>>>> BootMetaspaceSize until proven that it doesn't need to be the >>>>>> same size. >>>>> >>>>> With the BootClassLoader the space for the initial Metaspace is >>>>> committed >>>>> when the first system class is loaded. The same would be true for >>>>> any >>>>> Java application (all have some type of AppLoader, right)? We know >>>>> we're >>>>> going to use the space committed for the BootClassLoader >>>>> Metaspace. Are >>>>> we going to get yelled at for committing 4m and not using it. >>>>>> >>>>>> I suppose adding an AppMetaspaceInitialSize flag will give me >>>>>> more to talk about at the Permgen Elimination JavaOne talk though >>>>>> (but I'd still rather not). >>>>> >>>>> When you have 100000000000000000 flags, who's going to >>>>> notice the 100000000000000001-st :-) >>>> >>>> Okay, you convinced me to revert this part of the change. It wasn't >>>> necessary to make this stress test finish and there hasn't been >>>> very much tuning for "normal" application classes, just a suspicion >>>> of mine. >>>> >>>> Committing an extra 4m might be bad for embedded platforms. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Jon >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Rest looks good. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>> On 6/20/13 9:26 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Allocate medium chunks for class metaspace when class >>>>>>>> loader has lots of classes >>>>>>>> >>>>>>>> I originally made class metaspace keep small chunks and not >>>>>>>> start allocating from medium chunks, because I thought with >>>>>>>> only Klass objects, small chunks is enough. This test has a >>>>>>>> large set of class loaders who have a lot of classes, so >>>>>>>> allocated thousands of small chunks each. Class loaders with >>>>>>>> that many classes should start allocating from medium chunks, >>>>>>>> for class metaspace. >>>>>>>> >>>>>>>> I also increased the ClassMediumChunk size to 4k and measured a >>>>>>>> lot less fragmentation waste than 1K or 2K for this test. >>>>>>>> Lastly, the AppClassLoader instance should have as large of an >>>>>>>> initial metaspace as the bootclass loader. >>>>>>>> >>>>>>>> Tested with vm.quick.testlist and the failing test. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8015391/ >>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8015391 >>>>>>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8015391 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From bengt.rutisson at oracle.com Fri Jun 28 17:37:09 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Sat, 29 Jun 2013 00:37:09 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130629003721.C5C574866B@hg.openjdk.java.net> Changeset: 973c3ede4866 Author: brutisso Date: 2013-06-27 09:59 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/973c3ede4866 8017483: G1 tests fail with native OOME on Solaris x86 after HeapBaseMinAddress has been increased Summary: Set HeapBaseMinAddress as default rather than ergo Reviewed-by: stefank, jmasa, kvn ! src/share/vm/runtime/arguments.cpp Changeset: 1dad4752d5f7 Author: brutisso Date: 2013-06-28 14:25 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1dad4752d5f7 Merge Changeset: 12019d9953a8 Author: brutisso Date: 2013-06-29 01:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12019d9953a8 Merge From serguei.spitsyn at oracle.com Sun Jun 30 01:06:09 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 30 Jun 2013 01:06:09 -0700 Subject: RFR: 8009204 : [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris In-Reply-To: <7CA026FE-AD1B-4A09-9312-3AE4C3C85977@googlemail.com> References: <7CA026FE-AD1B-4A09-9312-3AE4C3C85977@googlemail.com> Message-ID: <51CFE6F1.5060608@oracle.com> Hi Tomas, The fix looks good. Thank you for discovering, tracking down and fixing the issue! Thanks, Serguei On 6/28/13 6:29 AM, Tomas Hurka wrote: > Hi All, > I would like to ask for review of JDK-8009204 > > Description of the problem: > jstack() returns corrupted method signatures on Solaris. The issue can be easily reproduce using the following DTrace script: > > dtrace -x jstackstrsize=2048 -Z \ > -n 'hotspot_jni$target::: /0/{}' \ > -n 'syscall::write:entry /pid==$target/{jstack(1024)}' \ > -c 'java -version' > > With Java 6, the output is roughly: > > java/io/FileOutputStream.writeBytes([BII)V > java/io/FileOutputStream.write([BII)V > java/io/BufferedOutputStream.flushBuffer()V > java/io/BufferedOutputStream.flush()V > java/io/PrintStream.write([BII)V > > With Java 7 and Java 8, the output is roughly: > > java/io/FileOutputStream.riteBytes > java/io/FileOutputStream.rite > java/io/BufferedOutputStream.lushBuffer > java/io/BufferedOutputStream.lush > java/io/PrintStream.rite > > Evaluation: > The problem is caused by SymbolTable changes JDK-6990754. jhelper.d was never updated with changes for CPSlot, so the low bit of the address of the Symbol is set, which causes the off by 1-ness of the output. The klass name uses a untagged constant pool entry, which is why it doesn't have the problem in the output. There is a very similar bug JDK-7019165 reported against pstack output and the proposed fix is basically backport of JDK-7019165 to jhelper.d. > > Webrev: > > > I tested the fix using above D-script on latest JDK 8 and JDK 7u sources. > > Thanks, > -- > Tomas Hurka > NetBeans Profiler http://profiler.netbeans.org > VisualVM http://visualvm.java.net > Software Developer > Oracle, Praha Czech Republic >