From tom.rodriguez at oracle.com Thu Sep 1 01:17:42 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 01 Sep 2011 08:17:42 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7083786: dead various dead chunks of code Message-ID: <20110901081746.835FB47296@hg.openjdk.java.net> Changeset: c124e2e7463e Author: never Date: 2011-08-31 16:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c124e2e7463e 7083786: dead various dead chunks of code Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From christian.thalinger at oracle.com Thu Sep 1 02:17:36 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 1 Sep 2011 11:17:36 +0200 Subject: Request for reviews (S): 7085404: JSR 292: VolatileCallSites should have push notification too Message-ID: <6C7FABE1-0779-4169-8488-CA5F54A75BB4@oracle.com> Here is the official review for 7085404. Tom has already reviewed this change in another thread on this list. http://cr.openjdk.java.net/~twisti/7085404/ 7085404: JSR 292: VolatileCallSites should have push notification too Reviewed-by: never 7071653 implemented push notification for ConstantCallSites and MutableCallSites. This should be extended to VolatileCallSites too. src/share/vm/c1/c1_GraphBuilder.cpp src/share/vm/ci/ciField.hpp src/share/vm/interpreter/interpreterRuntime.cpp src/share/vm/opto/callGenerator.cpp src/share/vm/opto/doCall.cpp src/share/vm/opto/parse3.cpp src/share/vm/prims/unsafe.cpp From christian.thalinger at oracle.com Thu Sep 1 05:40:44 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 01 Sep 2011 12:40:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7079673: JSR 292: C1 should inline bytecoded method handle adapters Message-ID: <20110901124049.82EF8472A3@hg.openjdk.java.net> Changeset: a32de5085326 Author: twisti Date: 2011-09-01 01:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a32de5085326 7079673: JSR 292: C1 should inline bytecoded method handle adapters Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/parse.hpp From vladimir.kozlov at oracle.com Thu Sep 1 08:37:51 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 01 Sep 2011 08:37:51 -0700 Subject: Request for reviews (S): 7085404: JSR 292: VolatileCallSites should have push notification too In-Reply-To: <6C7FABE1-0779-4169-8488-CA5F54A75BB4@oracle.com> References: <6C7FABE1-0779-4169-8488-CA5F54A75BB4@oracle.com> Message-ID: <4E5FA6CF.3060604@oracle.com> Looks good. Vladimir On 9/1/11 2:17 AM, Christian Thalinger wrote: > Here is the official review for 7085404. Tom has already reviewed this change in another thread on this list. > > http://cr.openjdk.java.net/~twisti/7085404/ > > 7085404: JSR 292: VolatileCallSites should have push notification too > Reviewed-by: never > > 7071653 implemented push notification for ConstantCallSites and > MutableCallSites. This should be extended to VolatileCallSites too. > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/ci/ciField.hpp > src/share/vm/interpreter/interpreterRuntime.cpp > src/share/vm/opto/callGenerator.cpp > src/share/vm/opto/doCall.cpp > src/share/vm/opto/parse3.cpp > src/share/vm/prims/unsafe.cpp > From christian.thalinger at oracle.com Thu Sep 1 09:02:31 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 1 Sep 2011 18:02:31 +0200 Subject: Request for reviews (S): 7085404: JSR 292: VolatileCallSites should have push notification too In-Reply-To: <4E5FA6CF.3060604@oracle.com> References: <6C7FABE1-0779-4169-8488-CA5F54A75BB4@oracle.com> <4E5FA6CF.3060604@oracle.com> Message-ID: <92CC590D-2AFC-4BEB-9A0C-2FAD4F2D7A0F@oracle.com> Thank you, Vladimir. -- Christian On Sep 1, 2011, at 5:37 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 9/1/11 2:17 AM, Christian Thalinger wrote: >> Here is the official review for 7085404. Tom has already reviewed this change in another thread on this list. >> >> http://cr.openjdk.java.net/~twisti/7085404/ >> >> 7085404: JSR 292: VolatileCallSites should have push notification too >> Reviewed-by: never >> >> 7071653 implemented push notification for ConstantCallSites and >> MutableCallSites. This should be extended to VolatileCallSites too. >> >> src/share/vm/c1/c1_GraphBuilder.cpp >> src/share/vm/ci/ciField.hpp >> src/share/vm/interpreter/interpreterRuntime.cpp >> src/share/vm/opto/callGenerator.cpp >> src/share/vm/opto/doCall.cpp >> src/share/vm/opto/parse3.cpp >> src/share/vm/prims/unsafe.cpp >> From headius at headius.com Thu Sep 1 15:49:15 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 1 Sep 2011 17:49:15 -0500 Subject: Crash on current head + switchpoint patch Message-ID: I'm running a build of hotspot-comp from today plus Christian's "switchpoint push invalidation" patch. Getting the following crash running the "redblack" benchmark (http://github.com/headius/redblack): headius at headius-vbox-ubuntu:~/projects/redblack$ JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby -Xinvokedynamic.all=true -X+C bm1.rb 20 # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 # # JRE version: 7.0_02-b05 # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x2719c0] InlineTree::should_inline(ciMethod*, ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/headius/projects/redblack/hs_err_pid14498.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Aborted Should be easy to produce, but I can provide any info you need. JRuby master, amd64 product build. -Xinvokedynamic.all is the same as -Djruby.invokedynamic.all and turns on all current uses of invokedynamic (some are off because they're slow in Java 7 GA). - Charlie From headius at headius.com Thu Sep 1 15:53:37 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 1 Sep 2011 17:53:37 -0500 Subject: Crash on current head + switchpoint patch In-Reply-To: References: Message-ID: FWIW, same crash without the switchpoint patch (i.e. current head of hotspot-comp). - Charlie On Thu, Sep 1, 2011 at 5:49 PM, Charles Oliver Nutter wrote: > I'm running a build of hotspot-comp from today plus Christian's > "switchpoint push invalidation" patch. Getting the following crash > running the "redblack" benchmark (http://github.com/headius/redblack): > > headius at headius-vbox-ubuntu:~/projects/redblack$ > JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby > -Xinvokedynamic.all=true -X+C bm1.rb 20 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # ?SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 > # > # JRE version: 7.0_02-b05 > # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode > linux-amd64 compressed oops) > # Problematic frame: > # V ?[libjvm.so+0x2719c0] ?InlineTree::should_inline(ciMethod*, > ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 > # > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /home/headius/projects/redblack/hs_err_pid14498.log > # > # If you would like to submit a bug report, please visit: > # ? http://bugreport.sun.com/bugreport/crash.jsp > # > Aborted > > Should be easy to produce, but I can provide any info you need. JRuby > master, amd64 product build. -Xinvokedynamic.all is the same as > -Djruby.invokedynamic.all and turns on all current uses of > invokedynamic (some are off because they're slow in Java 7 GA). > > - Charlie > From tom.rodriguez at oracle.com Thu Sep 1 17:13:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Sep 2011 17:13:27 -0700 Subject: Crash on current head + switchpoint patch In-Reply-To: References: Message-ID: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> I reproduced it. Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. When we try to use that zero as a scale for inlining tests of callees we get a div by zero. The problem has always been there I think but it was masked by the inline size cutoffs. We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. I filed 7086187 for this. If you need a workaround, this should work. diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp --- a/src/share/vm/opto/bytecodeInfo.cpp +++ b/src/share/vm/opto/bytecodeInfo.cpp @@ -145,7 +145,7 @@ } assert(invoke_count != 0, "require invocation count greater than zero"); - int freq = call_site_count / invoke_count; + int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0; // bump the max size if the call is frequent if ((freq >= InlineFrequencyRatio) || You'd need to disable the assert too if you wanted to run fastdebug. By the way, after working around it, I get this: dbx) c MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject from MethodHandles.java:2166:in `misMatchedTypes' from MethodHandles.java:2150:in `guardWithTest' from SwitchPoint.java:173:in `guardWithTest' from InvokeDynamicSupport.java:660:in `updateInvocationTarget' from InvokeDynamicSupport.java:462:in `invocationFallback' from ./red_black_tree.rb:68:in `method__11$RUBY$initialize' from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call' from CachingCallSite.java:142:in `callBlock' from CachingCallSite.java:148:in `call' from RubyClass.java:798:in `newInstance' from RubyClass$i$newInstance.gen:65535:in `call' from JavaMethod.java:256:in `call' from MethodHandle.java:566:in `invokeWithArguments' from InvokeDynamicSupport.java:464:in `invocationFallback' from bm1.rb:16:in `method__0$RUBY$rbt_bm' from bm1$method__0$RUBY$rbt_bm:65535:in `call' from bm1$method__0$RUBY$rbt_bm:65535:in `call' from MethodHandle.java:566:in `invokeWithArguments' from InvokeDynamicSupport.java:464:in `invocationFallback' from bm1.rb:30:in `block_10$RUBY$__file__' from bm1$block_10$RUBY$__file__:65535:in `call' from CompiledBlock.java:112:in `yield' from CompiledBlock.java:95:in `yield' from Block.java:130:in `yield' from RubyFixnum.java:252:in `times' from MethodHandleImpl.java:1154:in `invoke_L5' from MethodHandleImpl.java:1154:in `invoke_L5' from MethodHandle.java:566:in `invokeWithArguments' from InvokeDynamicSupport.java:538:in `invocationFallback' from bm1.rb:29:in `__file__' from bm1.rb:-1:in `load' from Ruby.java:715:in `runScript' from Ruby.java:708:in `runScript' from Ruby.java:615:in `runNormally' from Ruby.java:464:in `runFromMain' from Main.java:317:in `doRunFromMain' from Main.java:237:in `internalRun' from Main.java:203:in `run' from Main.java:187:in `run' from Main.java:167:in `main' Anyway, thanks for the report. tom On Sep 1, 2011, at 3:49 PM, Charles Oliver Nutter wrote: > I'm running a build of hotspot-comp from today plus Christian's > "switchpoint push invalidation" patch. Getting the following crash > running the "redblack" benchmark (http://github.com/headius/redblack): > > headius at headius-vbox-ubuntu:~/projects/redblack$ > JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby > -Xinvokedynamic.all=true -X+C bm1.rb 20 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 > # > # JRE version: 7.0_02-b05 > # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode > linux-amd64 compressed oops) > # Problematic frame: > # V [libjvm.so+0x2719c0] InlineTree::should_inline(ciMethod*, > ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 > # > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /home/headius/projects/redblack/hs_err_pid14498.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Aborted > > Should be easy to produce, but I can provide any info you need. JRuby > master, amd64 product build. -Xinvokedynamic.all is the same as > -Djruby.invokedynamic.all and turns on all current uses of > invokedynamic (some are off because they're slow in Java 7 GA). > > - Charlie From forax at univ-mlv.fr Thu Sep 1 18:11:34 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 02 Sep 2011 03:11:34 +0200 Subject: Crash on current head + switchpoint patch In-Reply-To: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> Message-ID: <4E602D46.4000502@univ-mlv.fr> On 09/02/2011 02:13 AM, Tom Rodriguez wrote: > I reproduced it. Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. When we try to use that zero as a scale for inlining tests of callees we get a div by zero. The problem has always been there I think but it was masked by the inline size cutoffs. We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. I filed 7086187 for this. If you need a workaround, this should work. > > diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp > --- a/src/share/vm/opto/bytecodeInfo.cpp > +++ b/src/share/vm/opto/bytecodeInfo.cpp > @@ -145,7 +145,7 @@ > } > > assert(invoke_count != 0, "require invocation count greater than zero"); > - int freq = call_site_count / invoke_count; > + int freq = invoke_count> 0 ? (call_site_count / invoke_count) : 0; > > // bump the max size if the call is frequent > if ((freq>= InlineFrequencyRatio) || > > You'd need to disable the assert too if you wanted to run fastdebug. > > By the way, after working around it, I get this: > > dbx) c > MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject > from MethodHandles.java:2166:in `misMatchedTypes' > from MethodHandles.java:2150:in `guardWithTest' > from SwitchPoint.java:173:in `guardWithTest' > from InvokeDynamicSupport.java:660:in `updateInvocationTarget' > from InvokeDynamicSupport.java:462:in `invocationFallback' > from ./red_black_tree.rb:68:in `method__11$RUBY$initialize' > from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call' > from CachingCallSite.java:142:in `callBlock' > from CachingCallSite.java:148:in `call' > from RubyClass.java:798:in `newInstance' > from RubyClass$i$newInstance.gen:65535:in `call' > from JavaMethod.java:256:in `call' > from MethodHandle.java:566:in `invokeWithArguments' > from InvokeDynamicSupport.java:464:in `invocationFallback' > from bm1.rb:16:in `method__0$RUBY$rbt_bm' > from bm1$method__0$RUBY$rbt_bm:65535:in `call' > from bm1$method__0$RUBY$rbt_bm:65535:in `call' > from MethodHandle.java:566:in `invokeWithArguments' > from InvokeDynamicSupport.java:464:in `invocationFallback' > from bm1.rb:30:in `block_10$RUBY$__file__' > from bm1$block_10$RUBY$__file__:65535:in `call' > from CompiledBlock.java:112:in `yield' > from CompiledBlock.java:95:in `yield' > from Block.java:130:in `yield' > from RubyFixnum.java:252:in `times' > from MethodHandleImpl.java:1154:in `invoke_L5' > from MethodHandleImpl.java:1154:in `invoke_L5' > from MethodHandle.java:566:in `invokeWithArguments' > from InvokeDynamicSupport.java:538:in `invocationFallback' > from bm1.rb:29:in `__file__' > from bm1.rb:-1:in `load' > from Ruby.java:715:in `runScript' > from Ruby.java:708:in `runScript' > from Ruby.java:615:in `runNormally' > from Ruby.java:464:in `runFromMain' > from Main.java:317:in `doRunFromMain' > from Main.java:237:in `internalRun' > from Main.java:203:in `run' > from Main.java:187:in `run' > from Main.java:167:in `main' oups, Charles, you forget to bind the callsite :) > > Anyway, thanks for the report. > > tom R?mi From headius at headius.com Thu Sep 1 19:37:44 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 1 Sep 2011 21:37:44 -0500 Subject: Crash on current head + switchpoint patch In-Reply-To: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> Message-ID: On Thu, Sep 1, 2011 at 7:13 PM, Tom Rodriguez wrote: > I reproduced it. ?Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. ?When we try to use that zero as a scale for inlining tests of callees we get a div by zero. ?The problem has always been there I think but it was masked by the inline size cutoffs. ?We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. ?I filed 7086187 for this. ?If you need a workaround, this should work. > > diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp > --- a/src/share/vm/opto/bytecodeInfo.cpp > +++ b/src/share/vm/opto/bytecodeInfo.cpp > @@ -145,7 +145,7 @@ > ? } > > ? assert(invoke_count != 0, "require invocation count greater than zero"); > - ?int freq = call_site_count / invoke_count; > + ?int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0; Heh, I fixed it the same way :) > By the way, after working around it, I get this: > > dbx) c > MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject Yeah, just fixed on master (like 15 minutes ago). - Charlie From headius at headius.com Thu Sep 1 19:59:00 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 1 Sep 2011 21:59:00 -0500 Subject: Crash on current head + switchpoint patch In-Reply-To: <4E602D46.4000502@univ-mlv.fr> References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> <4E602D46.4000502@univ-mlv.fr> Message-ID: On Thu, Sep 1, 2011 at 8:11 PM, R?mi Forax wrote: > oups, Charles, you forget to bind the callsite :) No, just a simple mismatched target + fallback for SwitchPoint.gwt. - Charlie From john.r.rose at oracle.com Thu Sep 1 23:04:46 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 02 Sep 2011 06:04:46 +0000 Subject: hg: hsx/hotspot-comp/langtools: 70 new changesets Message-ID: <20110902060706.114C1472DA@hg.openjdk.java.net> Changeset: bbd053476ec3 Author: bpatel Date: 2011-04-18 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bbd053476ec3 6758050: javadoc handles nested generic types incorrectly Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java + test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java + test/com/sun/javadoc/testNestedGenerics/pkg/NestedGenerics.java Changeset: 671bb63f3ed5 Author: mcimadamore Date: 2011-04-19 13:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/671bb63f3ed5 7036906: Scope: CompoundScope.getElements() doesn't pass scope filter to subscopes Summary: CompoundScope.getElements() is not filtering elements according to the ScopeFilter argument Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java Changeset: fb84cfca28a1 Author: jjg Date: 2011-04-25 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fb84cfca28a1 7039019: test cannot run standalone Reviewed-by: dlsmith ! test/tools/javac/processing/model/TestSymtabItems.java Changeset: 4c5f13798b8d Author: jjg Date: 2011-04-25 15:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4c5f13798b8d 7038363: cast from object to primitive should be for source >= 1.7 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/types/CastObjectToPrimitiveTest.java + test/tools/javac/types/CastObjectToPrimitiveTest.out Changeset: a8f5cad1e6bb Author: darcy Date: 2011-04-27 17:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a8f5cad1e6bb 7039822: Project Coin: add explicit tests for the lub of an exception parameter Reviewed-by: mcimadamore, jjg + test/tools/javac/multicatch/Neg07.java + test/tools/javac/multicatch/Neg07.out + test/tools/javac/multicatch/Pos10.java Changeset: 5c81ba0eddff Author: bpatel Date: 2011-04-27 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5c81ba0eddff 7028815: Missing styles for some bulleted items in the new stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: c7841bbe1227 Author: mchung Date: 2011-04-28 08:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c7841bbe1227 7037081: Remove com.sun.tracing from NON_CORE_PKGS Reviewed-by: ohair, jjg, jmasa ! src/share/classes/com/sun/tools/javac/resources/legacy.properties Changeset: 7ae6c0fd479b Author: jjg Date: 2011-04-28 15:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7ae6c0fd479b 7029150: Project Coin: present union types from the tree API through to javax.lang.model Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! test/tools/javac/multicatch/model/Model01.java ! test/tools/javac/multicatch/model/ModelChecker.java + test/tools/javac/multicatch/model/UnionTypeInfo.java + test/tools/javac/processing/model/type/TestUnionType.java Changeset: 4c03383f6529 Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4c03383f6529 7040104: javac NPE on Object a[]; Object o = (a=null)[0]; Summary: When a null literal is found on top of stack, if expected type is 1-dimension array no checkcast is emitted Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java + test/tools/javac/T7040104.java Changeset: 9a847a77205d Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9a847a77205d 7039937: Improved catch analysis fails to handle a common idiom in the libraries Summary: Disable generation of 'unreachable catch' warnings for catch statements catching Exception/Throwable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! test/tools/javac/6558548/T6558548.java ! test/tools/javac/6558548/T6558548_6.out ! test/tools/javac/6558548/T6558548_latest.out ! test/tools/javac/diags/examples/UnreachableCatch1.java Changeset: 1092b67b3cad Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1092b67b3cad 7034495: Javac asserts on usage of wildcards in bounds Summary: Problem with intersection types and wildcards causing javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/wildcards/7034495/T7034495.java + test/tools/javac/generics/wildcards/7034495/T7034495.out Changeset: dc3d9ef880a1 Author: mcimadamore Date: 2011-04-29 16:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/dc3d9ef880a1 6550655: com.sun.tools.javac.code.Symbol$CompletionFailure Summary: Accessing a non-existing enum constant from an annotation whose class is available results in an internal error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/annotations/6550655/T6550655.java ! test/tools/javac/diags/examples.not-yet.txt Changeset: 4caf17560ae0 Author: mcimadamore Date: 2011-04-30 11:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4caf17560ae0 7039931: Project Coin: diamond inference fail with generic constructor explicit type-arguments Summary: diamond should be disallowed in cases where explicit generic constructor parameters are specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DiamondAndExplicitParams.java ! test/tools/javac/generics/diamond/7030150/GenericConstructorAndDiamondTest.java - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 459854f564ed Author: lana Date: 2011-04-30 16:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/459854f564ed Merge Changeset: 62bc3775d5bb Author: bpatel Date: 2011-05-02 02:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/62bc3775d5bb 6492694: @deprecated tag doesn't work in package-info files. Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java + test/com/sun/javadoc/testPackageDeprecation/C2.java + test/com/sun/javadoc/testPackageDeprecation/FooDepr.java + test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java + test/com/sun/javadoc/testPackageDeprecation/pkg/A.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/ClassUseTest1.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/Foo.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/Foo2.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/package-info.java ! test/com/sun/javadoc/testSubTitle/TestSubTitle.java Changeset: 384ea9a98912 Author: mcimadamore Date: 2011-05-02 12:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/384ea9a98912 7040883: Compilation error: "length in Array is defined in an inaccessible class or interface" Summary: Fix of 7034511 (now backed out) is causing spurious accessibility errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511b.java + test/tools/javac/generics/typevars/T7040883.java Changeset: dbc4ced9d171 Author: bpatel Date: 2011-05-02 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/dbc4ced9d171 6553182: Need to modify javadoc doclet for GPL Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java + test/com/sun/javadoc/testDocRootLink/pkg1/C1.java + test/com/sun/javadoc/testDocRootLink/pkg1/package.html + test/com/sun/javadoc/testDocRootLink/pkg2/C2.java + test/com/sun/javadoc/testDocRootLink/pkg2/package.html ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java Changeset: 14ff19ca715f Author: jgodinez Date: 2011-05-03 22:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/14ff19ca715f Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: b72d70f33ee4 Author: jgodinez Date: 2011-05-09 12:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b72d70f33ee4 Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 66956f601f5a Author: mfang Date: 2011-05-10 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/66956f601f5a 7022005: [ja,zh_CN] javadoc, part of navigation bar in generated html are not translated. 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 Changeset: c60f85f28aa9 Author: mfang Date: 2011-05-10 15:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c60f85f28aa9 7043548: message drop 3 translation integration Reviewed-by: yhuang ! 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/javadoc/resources/javadoc_zh_CN.properties Changeset: 7476b164194c Author: mfang Date: 2011-05-10 19:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7476b164194c Merge Changeset: 4d05949f8d6b Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4d05949f8d6b Added tag jdk7-b142 for changeset 7476b164194c ! .hgtags Changeset: c3e3945cc24f Author: alanb Date: 2011-05-09 01:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c3e3945cc24f Merge Changeset: 68fde7f5863b Author: jjg Date: 2011-05-10 19:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/68fde7f5863b 7043694: printStackTrace call should be removed Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java Changeset: a2d422d480cb Author: mcimadamore Date: 2011-05-11 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a2d422d480cb 7042566: Regression: new ambiguity between varargs method Summary: Erroneous ambiguity error when choosing most specific varargs method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/7042566/T7042566.java Changeset: 95fc7fd39be2 Author: mcimadamore Date: 2011-05-11 13:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/95fc7fd39be2 7041730: Regression: compiler accepts invalid cast from int to Byte Summary: Implementation of cast conversion rules between primitive and boxed types is too liberal Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/types/BoxingConversionTest.java ! test/tools/javac/types/CastTest.java Changeset: bdfa48f80c82 Author: jjg Date: 2011-05-11 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bdfa48f80c82 7043867: docs/jdk/api/javac have html files that have issues with HTML4 compliance Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/SynchronizedTree.java Changeset: 652f0daf74a7 Author: lana Date: 2011-05-14 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/652f0daf74a7 Merge Changeset: 5faa9eedc44e Author: mcimadamore Date: 2011-05-16 09:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5faa9eedc44e 7043922: Regression: internal compiler error for nested anonymous inner class featuring varargs constructor Summary: Attributing a constructor call does not clean up the compiler's attribution context Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/varargs/7043922/T7043922.java Changeset: 8987de9a4ab8 Author: schien Date: 2011-05-20 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8987de9a4ab8 Added tag jdk7-b143 for changeset 5faa9eedc44e ! .hgtags Changeset: 8eb952f43b11 Author: katleman Date: 2011-05-25 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8eb952f43b11 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! test/tools/javac/4241573/T4241573.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/TryWithResources/DuplicateResource.java ! test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/T6838467.java ! test/tools/javac/api/T6877206.java ! test/tools/javac/api/TestClientCodeWrapper.java ! test/tools/javac/api/TestJavacTask_Lock.java ! test/tools/javac/api/TestJavacTask_Multiple.java ! test/tools/javac/api/TestJavacTask_ParseAttrGen.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/tree/T6963934.java Changeset: 9f25c6a3ac23 Author: schien Date: 2011-05-26 20:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9f25c6a3ac23 Added tag jdk7-b144 for changeset 8eb952f43b11 ! .hgtags Changeset: 6bb526ccf5ff Author: mcimadamore Date: 2011-05-23 11:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6bb526ccf5ff 7046348: Regression: javac complains of missing classfile for a seemingly unrelated interface Summary: Types.implementation forces unnecessary symbol completion on superinterfaces of a given type Reviewed-by: jjg ! 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/Check.java + test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: 6211df69f7e0 Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6211df69f7e0 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 6762754eb7c0 Author: jjg Date: 2011-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6762754eb7c0 7042623: Regression: javac silently crash when attributing non-existent annotation Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T7042623.java + test/tools/javac/T7042623.out Changeset: c455e2ae5c93 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c455e2ae5c93 Merge Changeset: 9ff91d0e7154 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9ff91d0e7154 Added tag jdk7-b145 for changeset c455e2ae5c93 ! .hgtags Changeset: fdc22d73b6f3 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fdc22d73b6f3 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: f27b6f45a449 Author: schien Date: 2011-06-08 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f27b6f45a449 Merge Changeset: 347349c981f2 Author: jjh Date: 2011-06-09 09:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/347349c981f2 7052782: Two langtools regression tests fail due to fix for 7034977 which removed the invokeGeneric method Summary: Change the tests to call invoke instead of invokeGeneric Reviewed-by: jrose, mcimadamore ! test/tools/javac/meth/InvokeMH.java ! test/tools/javac/meth/XlintWarn.java Changeset: b8a2c9c87018 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b8a2c9c87018 Merge Changeset: 588d366d96df Author: asaha Date: 2011-04-21 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/588d366d96df Merge Changeset: 219b522d09e4 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/219b522d09e4 Merge Changeset: 145d832616d3 Author: asaha Date: 2011-05-05 22:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/145d832616d3 Merge Changeset: 8b6e015ae7d0 Author: asaha Date: 2011-05-24 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8b6e015ae7d0 Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 35cc19ae29b5 Author: asaha Date: 2011-05-26 17:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/35cc19ae29b5 Merge Changeset: 8b65930602c3 Author: asaha Date: 2011-05-26 21:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8b65930602c3 Merge Changeset: 0adb806caf9d Author: asaha Date: 2011-06-06 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0adb806caf9d Merge Changeset: bb1fdcebde01 Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bb1fdcebde01 Merge Changeset: 8ed03b0e3c9c Author: asaha Date: 2011-06-06 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8ed03b0e3c9c Merge Changeset: f494ca4bca0d Author: lana Date: 2011-06-15 16:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f494ca4bca0d Merge Changeset: 7eba9df190ae Author: bpatel Date: 2011-06-17 20:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7eba9df190ae 7052425: Change the look and feel of the javadoc generate HTML pages using stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: c3a3440fe6e8 Author: bpatel Date: 2011-06-17 20:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c3a3440fe6e8 Merge Changeset: 9425dd4f53d5 Author: schien Date: 2011-06-18 09:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9425dd4f53d5 Merge Changeset: 436fb6aeda5a Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/436fb6aeda5a Added tag jdk7-b146 for changeset 9425dd4f53d5 ! .hgtags Changeset: 06b6bbbe2787 Author: schien Date: 2011-06-20 17:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/06b6bbbe2787 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: a72412b148d7 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a72412b148d7 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 58bc532d6341 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/58bc532d6341 Merge Changeset: ce654f4ecfd8 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ce654f4ecfd8 Added tag jdk7-b147 for changeset 58bc532d6341 ! .hgtags Changeset: e0dec1645823 Author: schien Date: 2011-06-27 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e0dec1645823 Merge Changeset: defdd98cb7ce Author: darcy Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/defdd98cb7ce 7025784: Add SourceVersion.RELEASE_8 7025786: Add -source 8 and -target 8 to javac 7025789: Change javac source and target default to 8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/javax/lang/model/SourceVersion.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/quid/T6999438.java ! test/tools/javac/versions/check.sh Changeset: 3b1fd4ac2e71 Author: darcy Date: 2011-06-13 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3b1fd4ac2e71 7052122: Update JDK_MINOR_VERSION for JDK 8 Reviewed-by: mr, katleman + test/tools/javac/processing/model/TestSourceVersion.java Changeset: 4844a9fd3a62 Author: darcy Date: 2011-06-22 17:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4844a9fd3a62 6449184: Provide JavacProcessingEnvironment.getWriter Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/util/T6597678.java Changeset: 18002d039806 Author: jjg Date: 2011-06-23 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/18002d039806 7058174: Reduce langtools build warnings Reviewed-by: jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/build.xml ! make/tools/CompileProperties/CompileProperties.java Changeset: d59414955614 Author: lana Date: 2011-06-22 23:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d59414955614 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: 9eb36cac6b64 Author: lana Date: 2011-06-23 17:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9eb36cac6b64 Merge Changeset: f74e4269a50a Author: darcy Date: 2011-06-24 13:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f74e4269a50a 6575445: Update annotation processor to only use java.util.ServiceLoader Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt Changeset: 858ae8fec72f Author: jjg Date: 2011-06-30 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/858ae8fec72f 7060926: Attr.PostAttrAnalyzer misses a case Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/failover/FailOver15.java + test/tools/javac/failover/FailOver15.out Changeset: 469e3bec9b27 Author: lana Date: 2011-06-30 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/469e3bec9b27 Merge From christian.thalinger at oracle.com Fri Sep 2 02:48:05 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 02 Sep 2011 09:48:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7085404: JSR 292: VolatileCallSites should have push notification too Message-ID: <20110902094810.96FAC472E7@hg.openjdk.java.net> Changeset: aa67216400d3 Author: twisti Date: 2011-09-02 00:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aa67216400d3 7085404: JSR 292: VolatileCallSites should have push notification too Reviewed-by: never, kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/unsafe.cpp From christian.thalinger at oracle.com Fri Sep 2 04:25:22 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 2 Sep 2011 13:25:22 +0200 Subject: Request for reviews (S): 7071709: JSR 292: switchpoint invalidation should be pushed not pulled In-Reply-To: References: <5F4038AD-6959-480E-9DB8-1DEF17D6C4A6@oracle.com> <52852391-3B23-4326-B75C-D2CB502C52AF@oracle.com> <9EC6D299-AE3B-44C7-AC71-5526AB810557@oracle.com> <0EEADB80-E8F9-49B7-BF9C-9FD4A50BD73D@oracle.com> <2F4D4364-320E-4CCD-A6CB-28E1535FBACF@oracle.com> Message-ID: <347CD45E-BAA2-41BA-A032-466B6C975DBC@oracle.com> On Aug 31, 2011, at 11:34 PM, John Rose wrote: > On Aug 31, 2011, at 3:42 AM, Christian Thalinger wrote: > >> This patch now only contains the SwitchPoint optimization and will be pushed as the last of my fixes (as stated in an earlier email): >> >> http://cr.openjdk.java.net/~twisti/7071709/ >> >> Tom, John, can you review this again? > > > It is good, but I have a question. What happens when this line produces a null value for the target (because of -Xcomp etc.): > ciMethodHandle* target = call_site->get_target(); > > Shouldn't there be a guard for that edge case, in case Murphy's Law kicks in? Yes, there should be one. I added a null check. -- Christian > > -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110902/4622f3f4/attachment.html From christian.thalinger at oracle.com Fri Sep 2 06:40:27 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 02 Sep 2011 13:40:27 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7071709: JSR 292: switchpoint invalidation should be pushed not pulled Message-ID: <20110902134031.7F5E5472FB@hg.openjdk.java.net> Changeset: 11a4af030e4b Author: twisti Date: 2011-09-02 04:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/11a4af030e4b 7071709: JSR 292: switchpoint invalidation should be pushed not pulled Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse3.cpp From john.coomes at oracle.com Fri Sep 2 07:08:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Sep 2011 14:08:36 +0000 Subject: hg: hsx/hotspot-comp: 24 new changesets Message-ID: <20110902140837.365A4472FD@hg.openjdk.java.net> Changeset: bde8f3d56ffa Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/bde8f3d56ffa Added tag jdk7-b142 for changeset cfbbdb77eac0 ! .hgtags Changeset: 14b8e7eee105 Author: ohair Date: 2011-05-16 08:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/14b8e7eee105 7043700: Regression for IcedTea builds Reviewed-by: dholmes, omajid ! Makefile ! make/jprt.gmk Changeset: 7203965666a4 Author: schien Date: 2011-05-20 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/7203965666a4 Added tag jdk7-b143 for changeset 14b8e7eee105 ! .hgtags Changeset: 3408a19567a6 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3408a19567a6 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 4373d87e6f37 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4373d87e6f37 Added tag jdk7-b144 for changeset 7203965666a4 ! .hgtags Changeset: 93d2590fd849 Author: jeff Date: 2011-05-27 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/93d2590fd849 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 55e9ebf03218 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/55e9ebf03218 Merge Changeset: 2d38c2a79c14 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2d38c2a79c14 Added tag jdk7-b145 for changeset 55e9ebf03218 ! .hgtags Changeset: 404bd0b9385f Author: schien Date: 2011-06-08 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/404bd0b9385f Merge Changeset: 3e0b96f8f6a0 Author: schien Date: 2011-06-20 16:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3e0b96f8f6a0 Added tag jdk7-b146 for changeset 2d38c2a79c14 ! .hgtags Changeset: 29e7e1474b5e Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/29e7e1474b5e Merge Changeset: 8da980eedab6 Author: jeff Date: 2011-06-22 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8da980eedab6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d91364304d7c Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/d91364304d7c Merge Changeset: ee67ee3bd597 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ee67ee3bd597 Added tag jdk7-b147 for changeset d91364304d7c ! .hgtags Changeset: 04734fe746f0 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/04734fe746f0 Merge Changeset: 0b615980879e Author: jjg Date: 2011-06-30 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/0b615980879e 7061195: Clean up makefiles for JDK 8 Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/sanity-rules.gmk Changeset: 05e24d6ed56d Author: lana Date: 2011-07-14 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/05e24d6ed56d Merge Changeset: fd8615098a54 Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/fd8615098a54 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: f42e3d9394b4 Author: ohair Date: 2011-07-22 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/f42e3d9394b4 Merge Changeset: 3bec5415a227 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3bec5415a227 Added tag jdk8-b01 for changeset f42e3d9394b4 ! .hgtags Changeset: e01201e727da Author: neugens Date: 2011-07-26 21:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e01201e727da 7071275: Fix jdk7 references in README files, remove Forest Extension mentions Summary: Change documentation to remove reference to forest and reflect update to jdk8. Reviewed-by: ohair ! README ! README-builds.html Changeset: 69f592185747 Author: schien Date: 2011-08-24 13:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/69f592185747 Merge Changeset: 587bb549dff8 Author: schien Date: 2011-08-25 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/587bb549dff8 Added tag jdk8-b02 for changeset 69f592185747 ! .hgtags Changeset: 0b66a233bfb9 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/0b66a233bfb9 Added tag jdk8-b03 for changeset 587bb549dff8 ! .hgtags From john.coomes at oracle.com Fri Sep 2 07:08:47 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Sep 2011 14:08:47 +0000 Subject: hg: hsx/hotspot-comp/corba: 23 new changesets Message-ID: <20110902140902.171C0472FE@hg.openjdk.java.net> Changeset: 62a6a0a1a350 Author: mfang Date: 2011-05-10 15:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/62a6a0a1a350 7043548: message drop 3 translation integration Reviewed-by: yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties Changeset: a2f340a048c8 Author: mfang Date: 2011-05-10 19:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/a2f340a048c8 Merge Changeset: 51ed32f6f4de Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/51ed32f6f4de Added tag jdk7-b142 for changeset a2f340a048c8 ! .hgtags Changeset: b06dd44a2740 Author: schien Date: 2011-05-20 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/b06dd44a2740 Added tag jdk7-b143 for changeset 51ed32f6f4de ! .hgtags Changeset: c908ae06bd6b Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/c908ae06bd6b 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 7033a5756ad5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/7033a5756ad5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java Changeset: 74eb715474f2 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/74eb715474f2 Added tag jdk7-b144 for changeset 7033a5756ad5 ! .hgtags Changeset: 93e77c49b3bb Author: miroslawzn Date: 2011-05-26 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/93e77c49b3bb 7046882: Regression : JDK 7b123 : Enum exchanged as parameters using CORBA call results in Exception Reviewed-by: raginip ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 643f267ca234 Author: jeff Date: 2011-05-27 14:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/643f267ca234 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 7839048ec99e Author: jeff Date: 2011-05-27 15:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/7839048ec99e Merge Changeset: 77ec0541aa2a Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/77ec0541aa2a Merge Changeset: 770227a4087e Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/770227a4087e Added tag jdk7-b145 for changeset 77ec0541aa2a ! .hgtags Changeset: e85ff90212ad Author: schien Date: 2011-06-08 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/e85ff90212ad Merge Changeset: 36f0efbc66ef Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/36f0efbc66ef Added tag jdk7-b146 for changeset 770227a4087e ! .hgtags Changeset: abe4723b9b7f Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/abe4723b9b7f Merge Changeset: bba0e37d7006 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/bba0e37d7006 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 73323cb33962 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/73323cb33962 Merge Changeset: 960011ba4bf2 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/960011ba4bf2 Added tag jdk7-b147 for changeset 73323cb33962 ! .hgtags Changeset: 97014e43181f Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/97014e43181f Merge Changeset: 949fb60ca830 Author: ohair Date: 2011-07-22 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/949fb60ca830 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: ed8d94519a87 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/ed8d94519a87 Added tag jdk8-b01 for changeset 949fb60ca830 ! .hgtags Changeset: cd0da00694fb Author: schien Date: 2011-08-25 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/cd0da00694fb Added tag jdk8-b02 for changeset ed8d94519a87 ! .hgtags Changeset: 60a68d688e24 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/60a68d688e24 Added tag jdk8-b03 for changeset cd0da00694fb ! .hgtags From john.coomes at oracle.com Fri Sep 2 07:09:11 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Sep 2011 14:09:11 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 26 new changesets Message-ID: <20110902140911.731C1472FF@hg.openjdk.java.net> Changeset: 30129a58aacc Author: ohair Date: 2011-04-29 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/30129a58aacc 7040147: jaxp 1.4.5 jdk7 integration Reviewed-by: joehw ! jaxp.properties Changeset: 5598bd5ede94 Author: lana Date: 2011-04-30 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/5598bd5ede94 Merge Changeset: 9da6d4f2c640 Author: jgodinez Date: 2011-05-03 22:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/9da6d4f2c640 Merge Changeset: 7d067af4b25e Author: jgodinez Date: 2011-05-09 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/7d067af4b25e Merge Changeset: 3910007a86d8 Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/3910007a86d8 Added tag jdk7-b142 for changeset 7d067af4b25e ! .hgtags Changeset: 7691aa48eba4 Author: alanb Date: 2011-05-09 01:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/7691aa48eba4 Merge Changeset: 16b847e9bbd7 Author: lana Date: 2011-05-14 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/16b847e9bbd7 Merge Changeset: 39bf6dcaab23 Author: schien Date: 2011-05-20 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/39bf6dcaab23 Added tag jdk7-b143 for changeset 16b847e9bbd7 ! .hgtags Changeset: f816d9ea0b34 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/f816d9ea0b34 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: bee49f47043f Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/bee49f47043f Added tag jdk7-b144 for changeset 39bf6dcaab23 ! .hgtags Changeset: bdf77cbd9958 Author: ohair Date: 2011-05-19 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/bdf77cbd9958 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop Reviewed-by: joehw ! jaxp.properties Changeset: 775dd77e4730 Author: lana Date: 2011-05-20 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/775dd77e4730 Merge Changeset: a70a042c8600 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/a70a042c8600 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 10ca7570f47f Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/10ca7570f47f Merge Changeset: bcd31fa1e3c6 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/bcd31fa1e3c6 Added tag jdk7-b145 for changeset 10ca7570f47f ! .hgtags Changeset: bae5f389d17b Author: schien Date: 2011-06-08 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/bae5f389d17b Merge Changeset: 9a4d09f33f01 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/9a4d09f33f01 Added tag jdk7-b146 for changeset bcd31fa1e3c6 ! .hgtags Changeset: 03692de33ca8 Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/03692de33ca8 Merge Changeset: eed2486cb10b Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/eed2486cb10b 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: fc268cd1dd5d Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/fc268cd1dd5d Merge Changeset: 6c9ac74190a0 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/6c9ac74190a0 Added tag jdk7-b147 for changeset fc268cd1dd5d ! .hgtags Changeset: 58dfc6f729e8 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/58dfc6f729e8 Merge Changeset: 4f0fcb812767 Author: ohair Date: 2011-07-22 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/4f0fcb812767 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: ca4d6ad55a66 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/ca4d6ad55a66 Added tag jdk8-b01 for changeset 4f0fcb812767 ! .hgtags Changeset: 7a74371ce0c6 Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/7a74371ce0c6 Added tag jdk8-b02 for changeset ca4d6ad55a66 ! .hgtags Changeset: acbcadef0b21 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/acbcadef0b21 Added tag jdk8-b03 for changeset 7a74371ce0c6 ! .hgtags From john.coomes at oracle.com Fri Sep 2 07:09:20 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Sep 2011 14:09:20 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 31 new changesets Message-ID: <20110902140920.71E9047300@hg.openjdk.java.net> Changeset: 7439eee6371b Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/7439eee6371b Added tag jdk7-b142 for changeset 0ef3ef823c39 ! .hgtags Changeset: 6d59d563f187 Author: ohair Date: 2011-05-10 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/6d59d563f187 7042773: Integrate JAXWS 2.2.4 update to JDK7 Reviewed-by: ramap ! jaxws.properties Changeset: 569d1e7ea980 Author: lana Date: 2011-05-14 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/569d1e7ea980 Merge Changeset: 6bd683f2d527 Author: schien Date: 2011-05-20 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/6bd683f2d527 Added tag jdk7-b143 for changeset 569d1e7ea980 ! .hgtags Changeset: b52d1b2f4a52 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/b52d1b2f4a52 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 6158298d2b94 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/6158298d2b94 Added tag jdk7-b144 for changeset 6bd683f2d527 ! .hgtags Changeset: c902e39c384e Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c902e39c384e 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: bcca8afc019f Author: ohair Date: 2011-06-01 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/bcca8afc019f 7049699: Problem with xml/jax-ws Reviewed-by: ramap ! jaxws.properties Changeset: 42bfba80beb7 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/42bfba80beb7 Merge Changeset: 6ec12c60ad13 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/6ec12c60ad13 Added tag jdk7-b145 for changeset 42bfba80beb7 ! .hgtags Changeset: 1b7851b9e113 Author: schien Date: 2011-06-08 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/1b7851b9e113 Merge Changeset: 581dab3f0773 Author: asaha Date: 2011-04-21 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/581dab3f0773 Merge Changeset: 26610bb80151 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/26610bb80151 Merge Changeset: c6ff860428c7 Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c6ff860428c7 Merge Changeset: f4e1caef46d0 Author: asaha Date: 2011-05-24 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/f4e1caef46d0 Merge Changeset: 9896cee00786 Author: asaha Date: 2011-05-26 17:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/9896cee00786 Merge Changeset: d1febdcb0351 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/d1febdcb0351 Merge Changeset: 239c80c331da Author: asaha Date: 2011-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/239c80c331da Merge Changeset: 09412171ca4b Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/09412171ca4b Merge Changeset: 9d8fd0982fb8 Author: asaha Date: 2011-06-06 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/9d8fd0982fb8 Merge Changeset: 05469dd4c366 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/05469dd4c366 Merge Changeset: faa394edbfe3 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/faa394edbfe3 Added tag jdk7-b146 for changeset 05469dd4c366 ! .hgtags Changeset: 9244c440c0df Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/9244c440c0df Merge Changeset: 632e38191caa Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/632e38191caa 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d13b1f877bb5 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/d13b1f877bb5 Merge Changeset: 2605f832dfbf Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/2605f832dfbf Added tag jdk7-b147 for changeset d13b1f877bb5 ! .hgtags Changeset: 47022a1b59be Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/47022a1b59be Merge Changeset: 64df57a1edec Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/64df57a1edec 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: 1034127ed402 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/1034127ed402 Added tag jdk8-b01 for changeset 64df57a1edec ! .hgtags Changeset: 7dcb0307508f Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/7dcb0307508f Added tag jdk8-b02 for changeset 1034127ed402 ! .hgtags Changeset: 3f6f08163331 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/3f6f08163331 Added tag jdk8-b03 for changeset 7dcb0307508f ! .hgtags From john.coomes at oracle.com Fri Sep 2 07:11:01 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Sep 2011 14:11:01 +0000 Subject: hg: hsx/hotspot-comp/jdk: 78 new changesets Message-ID: <20110902142604.A7CC847309@hg.openjdk.java.net> Changeset: 74598b748a57 Author: lana Date: 2011-07-01 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/74598b748a57 Merge Changeset: 0a00216a858c Author: lana Date: 2011-07-07 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0a00216a858c Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: 77d5cc943286 Author: prr Date: 2011-07-19 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/77d5cc943286 7068471: NPE in sun.font.FontConfigManager.getFontConfigFont() when libfontconfig.so is not installed Reviewed-by: jgodinez, prr Contributed-by: spoole at linux.vnet.ibm.com ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: ae05aa9ede7b Author: bae Date: 2011-07-20 16:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ae05aa9ede7b 7044285: 64 bit VM crashes in Java_sun_java2d_loops_MaskFill_MaskFill Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h Changeset: 40d0dea5d0fc Author: neugens Date: 2011-07-26 21:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/40d0dea5d0fc 7070155: A small refactoring patch for the abstract RenderingEngine. Summary: Simplify code by using ReflectiveOperationException instead of 3 ignored catch blocks Reviewed-by: prr ! src/share/classes/sun/java2d/pipe/RenderingEngine.java Changeset: 0795f0dacfec Author: bagiras Date: 2011-07-11 15:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0795f0dacfec 7050935: closed/java/awt/Choice/WheelEventsConsumed/WheelEventsConsumed.html fails on win32 Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp + test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java Changeset: acea32663757 Author: peytoia Date: 2011-07-12 08:00 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/acea32663757 7042148: closed/java/awt/font/TextLayout/CheckLayoutLTR.java failed Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java + test/java/text/Bidi/Bug7042148.java Changeset: 75ee78eb7322 Author: peytoia Date: 2011-07-12 08:46 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/75ee78eb7322 7051769: java.text.Bidi.toString() output is wrong Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java + test/java/text/Bidi/Bug7051769.java Changeset: 6bc0e1709d97 Author: lana Date: 2011-07-11 16:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6bc0e1709d97 Merge Changeset: cce5659427bb Author: rupashka Date: 2011-07-12 11:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cce5659427bb 7019963: The goto parent directory button doesn't operate in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 5c22624d193e Author: rupashka Date: 2011-07-15 14:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5c22624d193e 4909150: WindowsTreeUI can cause NullPointerException occasionally Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java Changeset: 6ee24f03760d Author: serb Date: 2011-07-15 19:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6ee24f03760d 7043679: Wrong class name is used in Java_sun_awt_windows_WPrinterJob_initIDs Reviewed-by: dav, art ! src/windows/native/sun/windows/awt_PrintJob.cpp Changeset: c90a43ebf8fd Author: serb Date: 2011-07-15 19:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c90a43ebf8fd 7043815: AWT-XAWT - AWT-EventQueue-0 deadlock. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java Changeset: 252f71b26b23 Author: serb Date: 2011-07-15 19:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/252f71b26b23 6596915: JCK-runtime-6a/tests/api/java_awt/Component/index.html tesPaintAll fails Reviewed-by: art, dcherepanov, anthony ! src/solaris/classes/sun/awt/X11/XButtonPeer.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/XLabelPeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XPanelPeer.java ! src/solaris/classes/sun/awt/X11/XRepaintArea.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Component/PaintAll/PaintAll.java Changeset: 3ed58dbad819 Author: serb Date: 2011-07-15 19:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3ed58dbad819 6642728: Use reflection to access ScrollPane's private method from within sun.awt package Reviewed-by: art, anthony ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/native/sun/windows/awt_ScrollPane.cpp Changeset: 9c642ae9a543 Author: serb Date: 2011-07-15 19:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9c642ae9a543 4717864: setFont() does not update Fonts of Menus already on screen Reviewed-by: art, bagiras ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/native/sun/windows/awt_Menu.cpp ! src/windows/native/sun/windows/awt_Menu.h ! src/windows/native/sun/windows/awt_MenuBar.cpp ! src/windows/native/sun/windows/awt_MenuBar.h ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_MenuItem.h Changeset: 3ac81907aa7d Author: rupashka Date: 2011-07-18 17:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3ac81907aa7d 6509273: Password in JPasswordField gets Printed in clear text Reviewed-by: alexp ! src/share/classes/sun/swing/text/TextComponentPrintable.java Changeset: c05b36e4749e Author: rupashka Date: 2011-07-18 18:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c05b36e4749e 7031941: Use generificated JComboBox and JList in core libraries Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionComboBoxModel.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 190b11164876 Author: lana Date: 2011-07-27 22:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/190b11164876 Merge Changeset: 996547848b00 Author: lana Date: 2011-08-01 17:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/996547848b00 Merge Changeset: 34fdcdb70d20 Author: rupashka Date: 2011-07-28 18:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/34fdcdb70d20 6995769: occasion NPE thrown from SwingUtilities.computeIntersection() Reviewed-by: alexp ! src/share/classes/javax/swing/RepaintManager.java Changeset: 86098b3f7789 Author: rupashka Date: 2011-07-28 18:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/86098b3f7789 7071166: LayoutStyle.getPreferredGap() - IAE is expected but not thrown Reviewed-by: peterz ! src/share/classes/sun/swing/DefaultLayoutStyle.java + test/javax/swing/GroupLayout/7071166/bug7071166.java Changeset: 0ce1f0b21446 Author: serb Date: 2011-08-01 17:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0ce1f0b21446 7068060: closed/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java failed on windows Reviewed-by: art, dcherepanov + test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java Changeset: 854e74d8d956 Author: rupashka Date: 2011-08-03 16:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/854e74d8d956 7072328: Sun URL in the MetalLookAndFeel.getLayoutStyle() specification should be replaced with Oracle one Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java Changeset: 634c2a492cf5 Author: lana Date: 2011-08-05 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/634c2a492cf5 Merge - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java Changeset: e4c936c28960 Author: jjg Date: 2011-06-30 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e4c936c28960 7061190: Update boot JDK version for JDK 8 Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/common/shared/Defs-versions.gmk Changeset: cf4edfcd7119 Author: jjg Date: 2011-06-30 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cf4edfcd7119 7061195: Clean up makefiles for JDK 8 Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/common/shared/Defs-java.gmk Changeset: 74328e59a4bf Author: jjg Date: 2011-06-30 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/74328e59a4bf 7058708: Eliminate JDK build tools build warnings Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/tools/Makefile ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java ! make/tools/src/build/tools/compileproperties/CompileProperties.java ! make/tools/src/build/tools/dirdiff/DirDiff.java ! make/tools/src/build/tools/dtdbuilder/DTDBuilder.java ! make/tools/src/build/tools/dtdbuilder/DTDInputStream.java ! make/tools/src/build/tools/dtdbuilder/DTDParser.java ! make/tools/src/build/tools/dtdbuilder/PublicMapping.java ! make/tools/src/build/tools/generatebreakiteratordata/CharSet.java ! make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java ! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java ! make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java ! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java ! make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java ! make/tools/src/build/tools/generatecharacter/UnicodeSpec.java ! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java ! make/tools/src/build/tools/hasher/Hasher.java ! make/tools/src/build/tools/jarsplit/JarSplit.java ! make/tools/src/build/tools/javazic/Gen.java ! make/tools/src/build/tools/javazic/GenDoc.java ! make/tools/src/build/tools/javazic/Main.java ! make/tools/src/build/tools/javazic/Mappings.java ! make/tools/src/build/tools/javazic/Simple.java ! make/tools/src/build/tools/javazic/Time.java ! make/tools/src/build/tools/javazic/Zoneinfo.java ! make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java ! make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java ! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java ! make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java ! make/tools/src/build/tools/jdwpgen/AltNode.java ! make/tools/src/build/tools/jdwpgen/CommandSetNode.java ! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java ! make/tools/src/build/tools/jdwpgen/ErrorSetNode.java ! make/tools/src/build/tools/jdwpgen/Node.java ! make/tools/src/build/tools/jdwpgen/OutNode.java ! make/tools/src/build/tools/jdwpgen/RootNode.java ! make/tools/src/build/tools/jdwpgen/SelectNode.java ! make/tools/src/build/tools/makeclasslist/MakeClasslist.java ! make/tools/src/build/tools/stripproperties/StripProperties.java Changeset: e93679cf1e1a Author: valeriep Date: 2011-06-30 18:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e93679cf1e1a 7058133: Javah should use the freshly built classes instead of those from the BOOTDIR jdk Summary: Changed javah to use the newly built classes specified by $(CLASSDESTDIR) Reviewed-by: vinnie ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile Changeset: f0ec49c21d09 Author: valeriep Date: 2011-07-01 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f0ec49c21d09 Merge Changeset: e88093d75e36 Author: coffeys Date: 2011-07-05 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e88093d75e36 7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: f68d30c0a2e3 Author: mullan Date: 2011-07-06 11:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f68d30c0a2e3 7054969: Null-check-in-finally pattern in java/security documentation Reviewed-by: vinnie ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/security/cert/X509Extension.java Changeset: 63be90976177 Author: ksrini Date: 2011-07-08 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/63be90976177 7060849: Eliminate pack200 build warnings Reviewed-by: ksrini, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/java/pack/Makefile ! make/common/shared/Defs-java.gmk ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java Changeset: 5adf431673ac Author: peytoia Date: 2011-07-12 07:32 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5adf431673ac 7012364: test/java/util/Locale/LocaleCategory.sh fails on Cygwin Reviewed-by: okutsu ! test/java/util/Locale/LocaleCategory.sh Changeset: 549b7c3f0bdc Author: dl Date: 2011-07-12 15:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/549b7c3f0bdc 7058828: test/java/util/concurrent/Phaser/Arrive.java fails intermittently Reviewed-by: chegar ! test/java/util/concurrent/Phaser/Arrive.java Changeset: 42fe05e54e69 Author: naoto Date: 2011-07-12 10:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/42fe05e54e69 7022407: Spinning CPU in LocaleObjectCache.get() Reviewed-by: okutsu ! src/share/classes/sun/util/locale/LocaleObjectCache.java Changeset: db419c454f92 Author: dl Date: 2011-07-13 12:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/db419c454f92 7057320: test/java/util/concurrent/Executors/AutoShutdown.java failing intermittently Summary: Add retry/timeout for checking activeCount Reviewed-by: chegar ! test/java/util/concurrent/Executors/AutoShutdown.java Changeset: 7ac6a297f9a0 Author: lana Date: 2011-07-14 18:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7ac6a297f9a0 Merge Changeset: c0c983ca797b Author: ksrini Date: 2011-07-15 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c0c983ca797b 7062969: java -help still shows http://java.sun.com/javase/reference Reviewed-by: ohair, darcy ! src/share/classes/sun/launcher/resources/launcher.properties Changeset: d987f8738096 Author: darcy Date: 2011-07-17 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d987f8738096 7062430: Minor inconsistency in ulp descriptions Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: cbfc7f910af3 Author: alanb Date: 2011-07-18 13:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cbfc7f910af3 7068059: Update jdk/test/ProblemList.txt Reviewed-by: mchung, chegar ! test/ProblemList.txt Changeset: 8bbea505b060 Author: chegar Date: 2011-07-18 22:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8bbea505b060 7021280: SocketPermission should accept wildcards Reviewed-by: michaelm ! src/share/classes/java/net/SocketPermission.java + test/java/net/SocketPermission/Wildcard.java Changeset: 5355b9ccd19d Author: xuelei Date: 2011-07-19 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5355b9ccd19d 7059709: close the IO in a final block Reviewed-by: smarks, mullan, wetmore ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java Changeset: d17eb3380a49 Author: ksrini Date: 2011-07-19 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d17eb3380a49 7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute Reviewed-by: darcy, ohair, alanb, mduigou ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: d083644bc615 Author: darcy Date: 2011-07-19 17:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d083644bc615 7007535: (reflect) Please generalize Constructor and Method Reviewed-by: mduigou, peterjones, dholmes, andrew ! src/share/classes/java/lang/reflect/Constructor.java + src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java Changeset: 99dc852080e1 Author: xuelei Date: 2011-07-19 21:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/99dc852080e1 7065972: Some race condition may happen in SSLSocketImpl class Reviewed-by: wetmore, weijun, dgu ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 9505edecc8b5 Author: jjg Date: 2011-07-20 12:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9505edecc8b5 7068617: Core libraries don't build with javac -Xlint:all -Werror Reviewed-by: darcy Contributed-by: alexandre.boulgakov at oracle.com ! make/java/java/Makefile ! src/share/classes/sun/reflect/generics/reflectiveObjects/NotImplementedException.java ! src/share/classes/sun/reflect/misc/ConstructorUtil.java ! src/share/classes/sun/reflect/misc/FieldUtil.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 70ec3aa8e99a Author: chegar Date: 2011-07-21 17:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/70ec3aa8e99a 7068416: Lightweight HTTP Server should support TCP_NODELAY Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! test/com/sun/net/httpserver/Test1.java Changeset: c8dbb9e19355 Author: weijun Date: 2011-07-22 10:25 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c8dbb9e19355 6330275: Rework the PaddingTest regression test. Reviewed-by: wetmore, smarks ! test/ProblemList.txt ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java Changeset: 0ec4b6498a69 Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0ec4b6498a69 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: a499fdfbe723 Author: ohair Date: 2011-07-22 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a499fdfbe723 Merge Changeset: 07a12583d4ea Author: chegar Date: 2011-07-25 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/07a12583d4ea 7035556: DatagramSocket.java:183: warning: unreachable catch clause Summary: Remove redundant catches in bind Reviewed-by: alanb, michaelm, wetmore, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/DatagramSocket.java Changeset: c563e8060adf Author: jjg Date: 2011-07-25 16:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c563e8060adf 7069870: Parts of the JDK erroneously rely on generic array initializers with diamond Reviewed-by: ksrini, mcimadamore Contributed-by: alexandre.boulgakov at oracle.com ! make/tools/src/build/tools/jarsplit/JarSplit.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java Changeset: a80562f7ea50 Author: chegar Date: 2011-07-27 18:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a80562f7ea50 6670868: StackOverFlow with bad authenticated Proxy tunnels Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java Changeset: 7525866a4046 Author: jjg Date: 2011-07-28 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7525866a4046 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror Reviewed-by: alanb, chegar Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Makefile ! make/java/nio/Makefile ! make/java/sun_nio/Makefile ! make/sun/nio/Makefile ! make/sun/nio/cs/Makefile ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Reflect.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/FastCharsetProvider.java ! src/share/classes/sun/nio/cs/StreamDecoder.java ! src/share/classes/sun/nio/cs/ThreadLocalCoders.java ! src/share/classes/sun/nio/fs/Util.java ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/PendingIoCache.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Changeset: cea7c749f805 Author: xuelei Date: 2011-07-29 02:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cea7c749f805 7068662: Reserve and restore the default locale Reviewed-by: alanb, weijun ! test/com/sun/org/apache/xml/internal/security/exceptions/LocaleTest.java ! test/java/beans/XMLDecoder/Test6341798.java ! test/java/io/pathNames/win32/bug6344646.java ! test/java/net/CookieHandler/B6791927.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/util/Locale/LocaleCategory.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/ResourceBundle/Bug6190861.java ! test/java/util/ResourceBundle/Control/Bug6530694.java ! test/java/util/ResourceBundle/Control/StressTest.java ! test/java/util/ResourceBundle/Test4314141.java ! test/java/util/ResourceBundle/Test4318520.java ! test/java/util/jar/JarFile/TurkCert.java ! test/javax/crypto/Cipher/Turkish.java ! test/javax/swing/JColorChooser/Test6524757.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/text/resources/Collator/Bug4248694.java ! test/sun/text/resources/Collator/Bug4804273.java ! test/sun/text/resources/Collator/Bug4848897.java ! test/sun/text/resources/Format/Bug4651568.java ! test/sun/util/resources/Locale/Bug4965260.java ! test/sun/util/resources/TimeZone/Bug4640234.java Changeset: 4030297803eb Author: jjg Date: 2011-07-29 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4030297803eb 7072523: java.math should be built with javac -Xlint:all -Werror Reviewed-by: darcy Contributed-by: alexandre.boulgakov at oracle.com ! make/java/math/Makefile Changeset: 809e8db0c142 Author: chegar Date: 2011-07-29 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/809e8db0c142 6978200: ServerSocket.toString include "port=0" in the returned String Summary: Removal of "port=0" from ServerSocket.toString method Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/ServerSocket.java Changeset: e68db408d08c Author: weijun Date: 2011-08-04 18:18 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e68db408d08c 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/PrincipalName.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/PrincipalNameEquals.java Changeset: 565555e89034 Author: mduigou Date: 2011-08-04 08:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/565555e89034 7073296: Executable.equalParamTypes() incorrectly returns true when the number of params differs. Reviewed-by: alanb, darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Executable.java + test/java/lang/reflect/Constructor/Equals.java Changeset: b9fffbe98230 Author: darcy Date: 2011-08-06 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b9fffbe98230 7075098: Remove unused fdlibm files Reviewed-by: alanb, mduigou ! make/java/fdlibm/FILES_c.gmk ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/fdlibm/include/jfdlibm.h - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 3f3a59423a7e Author: lana Date: 2011-08-05 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3f3a59423a7e Merge - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java Changeset: a5f825ef8587 Author: lana Date: 2011-08-07 17:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a5f825ef8587 Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 94934ebbb654 Author: alanb Date: 2011-08-08 13:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/94934ebbb654 7076215: (jli) jdk/src/share/bin/jli_util.h should include function prototypes for str functions Reviewed-by: alanb Contributed-by: neil.richards at ngmr.net ! src/share/bin/jli_util.h Changeset: d4ab25d65adb Author: darcy Date: 2011-08-08 09:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d4ab25d65adb 6380161: (reflect) Exception from newInstance() not chained to cause. Reviewed-by: dholmes, lancea, forax ! src/share/classes/java/lang/Class.java Changeset: 0f1b4b3bc833 Author: mchung Date: 2011-08-08 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0f1b4b3bc833 7036518: TEST_BUG: add cygwin support to test/java/nio/charset/coders/CheckSJISMappingProp.sh 7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh Reviewed-by: sherman ! test/demo/zipfs/basic.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh Changeset: 39498fc31d63 Author: mchung Date: 2011-08-08 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39498fc31d63 7012365: TEST_BUG: test/java/nio/charset/spi/basic.sh can be run with Cygwin Reviewed-by: darcy ! test/java/nio/charset/spi/basic.sh Changeset: 26fe74aa48ef Author: chegar Date: 2011-08-09 16:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/26fe74aa48ef 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win) Reviewed-by: mchung ! test/java/lang/instrument/ManifestTest.sh Changeset: cf203f293b4e Author: chegar Date: 2011-08-09 16:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cf203f293b4e 7076756: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin Reviewed-by: alanb, dcubed ! test/com/sun/jdi/ShellScaffold.sh Changeset: 2cdbbc4a6359 Author: lana Date: 2011-08-09 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2cdbbc4a6359 Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 13e70aa1398e Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/13e70aa1398e Added tag jdk8-b01 for changeset 2cdbbc4a6359 ! .hgtags Changeset: dfa15ff0f99e Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dfa15ff0f99e Added tag jdk8-b02 for changeset 13e70aa1398e ! .hgtags Changeset: d8fccd6db59b Author: nloodin Date: 2011-08-31 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d8fccd6db59b 7067811: Update demo/sample code to state it should not be used for production Summary: Added comment block after copyright block stating that code is unfit for production. Reviewed-by: ohair ! make/common/Defs.gmk ! make/mkdemo/Makefile ! make/mksample/Makefile ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/InputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/OutputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ParseException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SessionListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/JDIListener.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassManager.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextListener.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/Icons.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/OutputSink.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceListener.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventNotifier.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java + src/share/demo/README ! src/share/demo/applets/ArcTest/ArcTest.java ! src/share/demo/applets/BarChart/BarChart.java ! src/share/demo/applets/Blink/Blink.java ! src/share/demo/applets/CardTest/CardTest.java ! src/share/demo/applets/Clock/Clock.java ! src/share/demo/applets/DitherTest/DitherTest.java ! src/share/demo/applets/DrawTest/DrawTest.java ! src/share/demo/applets/Fractal/CLSFractal.java ! src/share/demo/applets/GraphicsTest/AppletFrame.java ! src/share/demo/applets/GraphicsTest/GraphicsTest.java ! src/share/demo/applets/MoleculeViewer/Matrix3D.java ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/NervousText/NervousText.java ! src/share/demo/applets/SimpleGraph/GraphApplet.java ! src/share/demo/applets/SortDemo/BidirBubbleSortAlgorithm.java ! src/share/demo/applets/SortDemo/BubbleSortAlgorithm.java ! src/share/demo/applets/SortDemo/QSortAlgorithm.java ! src/share/demo/applets/SortDemo/SortAlgorithm.java ! src/share/demo/applets/SortDemo/SortItem.java ! src/share/demo/applets/SpreadSheet/SpreadSheet.java ! src/share/demo/applets/WireFrame/Matrix3D.java ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Destinations.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Group.java ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Modifier.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Node.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ResultSet.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Test.java ! src/share/demo/java2d/J2DBench/src/j2dbench/TestEnvironment.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/HTMLSeriesReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/IIOComparator.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/XMLHTMLReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/MiscTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/RenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextConstructionTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextMeasureTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextRenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/CompactLayout.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/EnableButton.java ! src/share/demo/jfc/CodePointIM/CodePointIM.java ! src/share/demo/jfc/CodePointIM/CodePointInputMethod.java ! src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java ! src/share/demo/jfc/FileChooserDemo/ExampleFileSystemView.java ! src/share/demo/jfc/FileChooserDemo/ExampleFileView.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java ! src/share/demo/jfc/Font2DTest/Font2DTest.java ! src/share/demo/jfc/Font2DTest/Font2DTestApplet.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/Font2DTest/RangeMenu.java ! src/share/demo/jfc/Metalworks/AquaMetalTheme.java ! src/share/demo/jfc/Metalworks/BigContrastMetalTheme.java ! src/share/demo/jfc/Metalworks/ContrastMetalTheme.java ! src/share/demo/jfc/Metalworks/DemoMetalTheme.java ! src/share/demo/jfc/Metalworks/GreenMetalTheme.java ! src/share/demo/jfc/Metalworks/KhakiMetalTheme.java ! src/share/demo/jfc/Metalworks/MetalThemeMenu.java ! src/share/demo/jfc/Metalworks/Metalworks.java ! src/share/demo/jfc/Metalworks/MetalworksDocumentFrame.java ! src/share/demo/jfc/Metalworks/MetalworksFrame.java ! src/share/demo/jfc/Metalworks/MetalworksHelp.java ! src/share/demo/jfc/Metalworks/MetalworksInBox.java ! src/share/demo/jfc/Metalworks/MetalworksPrefs.java ! src/share/demo/jfc/Metalworks/PropertiesMetalTheme.java ! src/share/demo/jfc/Metalworks/UISwitchListener.java ! src/share/demo/jfc/Notepad/ElementTreePanel.java ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jfc/SampleTree/DynamicTreeNode.java ! src/share/demo/jfc/SampleTree/SampleData.java ! src/share/demo/jfc/SampleTree/SampleTree.java ! src/share/demo/jfc/SampleTree/SampleTreeCellRenderer.java ! src/share/demo/jfc/SampleTree/SampleTreeModel.java ! src/share/demo/jfc/SwingApplet/SwingApplet.java ! src/share/demo/jfc/TableExample/JDBCAdapter.java ! src/share/demo/jfc/TableExample/OldJTable.java ! src/share/demo/jfc/TableExample/TableExample.java ! src/share/demo/jfc/TableExample/TableExample2.java ! src/share/demo/jfc/TableExample/TableExample3.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jfc/TableExample/TableMap.java ! src/share/demo/jfc/TableExample/TableSorter.java ! src/share/demo/jfc/TransparentRuler/transparentruler/Ruler.java ! src/share/demo/jvmti/agent_util/agent_util.c ! src/share/demo/jvmti/agent_util/agent_util.h ! src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c ! src/share/demo/jvmti/gctest/gctest.c ! src/share/demo/jvmti/heapTracker/HeapTracker.java ! src/share/demo/jvmti/heapTracker/heapTracker.c ! src/share/demo/jvmti/heapTracker/heapTracker.h ! src/share/demo/jvmti/heapViewer/heapViewer.c ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/debug_malloc.h ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_blocks.c ! src/share/demo/jvmti/hprof/hprof_blocks.h ! src/share/demo/jvmti/hprof/hprof_check.c ! src/share/demo/jvmti/hprof/hprof_check.h ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_class.h ! src/share/demo/jvmti/hprof/hprof_cpu.c ! src/share/demo/jvmti/hprof/hprof_cpu.h ! src/share/demo/jvmti/hprof/hprof_error.c ! src/share/demo/jvmti/hprof/hprof_error.h ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_event.h ! src/share/demo/jvmti/hprof/hprof_frame.c ! src/share/demo/jvmti/hprof/hprof_frame.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_init.h ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_io.h ! src/share/demo/jvmti/hprof/hprof_ioname.c ! src/share/demo/jvmti/hprof/hprof_ioname.h ! src/share/demo/jvmti/hprof/hprof_listener.c ! src/share/demo/jvmti/hprof/hprof_listener.h ! src/share/demo/jvmti/hprof/hprof_loader.c ! src/share/demo/jvmti/hprof/hprof_loader.h ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/hprof/hprof_monitor.c ! src/share/demo/jvmti/hprof/hprof_monitor.h ! src/share/demo/jvmti/hprof/hprof_object.c ! src/share/demo/jvmti/hprof/hprof_object.h ! src/share/demo/jvmti/hprof/hprof_reference.c ! src/share/demo/jvmti/hprof/hprof_reference.h ! src/share/demo/jvmti/hprof/hprof_site.c ! src/share/demo/jvmti/hprof/hprof_site.h ! src/share/demo/jvmti/hprof/hprof_stack.c ! src/share/demo/jvmti/hprof/hprof_stack.h ! src/share/demo/jvmti/hprof/hprof_string.c ! src/share/demo/jvmti/hprof/hprof_string.h ! src/share/demo/jvmti/hprof/hprof_table.c ! src/share/demo/jvmti/hprof/hprof_table.h ! src/share/demo/jvmti/hprof/hprof_tag.c ! src/share/demo/jvmti/hprof/hprof_tag.h ! src/share/demo/jvmti/hprof/hprof_tls.c ! src/share/demo/jvmti/hprof/hprof_tls.h ! src/share/demo/jvmti/hprof/hprof_trace.c ! src/share/demo/jvmti/hprof/hprof_trace.h ! src/share/demo/jvmti/hprof/hprof_tracker.c ! src/share/demo/jvmti/hprof/hprof_tracker.h ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/demo/jvmti/hprof/hprof_util.h ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.h ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/jvmti/minst/minst.c ! src/share/demo/jvmti/minst/minst.h ! src/share/demo/jvmti/mtrace/Mtrace.java ! src/share/demo/jvmti/mtrace/mtrace.c ! src/share/demo/jvmti/mtrace/mtrace.h ! src/share/demo/jvmti/versionCheck/versionCheck.c ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp ! src/share/demo/jvmti/waiters/Thread.cpp ! src/share/demo/jvmti/waiters/Thread.hpp ! src/share/demo/jvmti/waiters/waiters.cpp ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/FullThreadDump.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipDirectoryStream.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/heapdump.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/hello.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/verbose.js + src/share/sample/README ! src/share/sample/forkjoin/mergesort/MergeDemo.java ! src/share/sample/forkjoin/mergesort/MergeSort.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScanner.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScannerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirAgent.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirClient.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfigMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/DirectoryScannerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/FileMatch.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultLogConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultRecord.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ScanManagerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/XmlConfigUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/DirectoryScannerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanDirConfigTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanManagerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/TestUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/config/XmlConfigUtilsTest.java ! src/share/sample/nio/chatserver/ChatServer.java ! src/share/sample/nio/chatserver/Client.java ! src/share/sample/nio/chatserver/ClientReader.java ! src/share/sample/nio/chatserver/DataReader.java ! src/share/sample/nio/chatserver/MessageReader.java ! src/share/sample/nio/chatserver/NameReader.java ! src/share/sample/nio/file/AclEdit.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/DiskUsage.java ! src/share/sample/nio/file/FileType.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/file/Xdd.java ! src/share/sample/nio/multicast/MulticastAddress.java ! src/share/sample/nio/multicast/Reader.java ! src/share/sample/nio/multicast/Sender.java ! src/share/sample/nio/server/AcceptHandler.java ! src/share/sample/nio/server/Acceptor.java ! src/share/sample/nio/server/B1.java ! src/share/sample/nio/server/BN.java ! src/share/sample/nio/server/BP.java ! src/share/sample/nio/server/ChannelIO.java ! src/share/sample/nio/server/ChannelIOSecure.java ! src/share/sample/nio/server/Content.java ! src/share/sample/nio/server/Dispatcher.java ! src/share/sample/nio/server/Dispatcher1.java ! src/share/sample/nio/server/DispatcherN.java ! src/share/sample/nio/server/FileContent.java ! src/share/sample/nio/server/Handler.java ! src/share/sample/nio/server/MalformedRequestException.java ! src/share/sample/nio/server/N1.java ! src/share/sample/nio/server/N2.java ! src/share/sample/nio/server/Reply.java ! src/share/sample/nio/server/Request.java ! src/share/sample/nio/server/RequestHandler.java ! src/share/sample/nio/server/RequestServicer.java ! src/share/sample/nio/server/Sendable.java ! src/share/sample/nio/server/Server.java ! src/share/sample/nio/server/StringContent.java ! src/share/sample/nio/server/URLDumper.java ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js ! src/share/sample/vm/clr-jvm/invoked.java ! src/share/sample/vm/clr-jvm/jinvoker.cpp ! src/share/sample/vm/clr-jvm/jinvokerExp.h ! src/share/sample/vm/jvm-clr/invoker.cpp ! src/share/sample/vm/jvm-clr/invoker.h ! src/share/sample/vm/jvm-clr/invoker.java ! src/share/sample/vm/jvm-clr/invokerExp.h ! src/solaris/demo/jni/Poller/Client.java ! src/solaris/demo/jni/Poller/LinkedQueue.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jni/Poller/Poller.java ! src/solaris/demo/jni/Poller/PollingServer.java ! src/solaris/demo/jni/Poller/SimpleServer.java ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: c9956a6753fb Author: yhuang Date: 2011-08-14 23:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c9956a6753fb 7066203: Update currency data to the latest ISO 4217 standard Reviewed-by: naoto ! make/java/util/FILES_properties.gmk ! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! src/share/classes/sun/util/resources/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/CurrencyNames_es.properties + src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties ! src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties ! src/share/classes/sun/util/resources/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 954efddeee41 Author: mfang Date: 2011-08-17 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/954efddeee41 Merge ! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java Changeset: f10654c857fd Author: mfang Date: 2011-08-29 17:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f10654c857fd Merge Changeset: 7989ee9fe673 Author: mfang Date: 2011-08-31 09:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7989ee9fe673 Merge Changeset: d977bcc79584 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d977bcc79584 Added tag jdk8-b03 for changeset 7989ee9fe673 ! .hgtags From john.coomes at oracle.com Fri Sep 2 08:42:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Sep 2011 15:42:39 +0000 Subject: hg: hsx/hotspot-comp/langtools: 18 new changesets Message-ID: <20110902154318.9864D47311@hg.openjdk.java.net> Changeset: b0909f992710 Author: ksrini Date: 2011-06-30 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b0909f992710 7059905: (javadoc) promote method visibility for netbeans usage Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java Changeset: 409b104f8b86 Author: ksrini Date: 2011-07-01 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/409b104f8b86 6735320: StringIndexOutOfBoundsException for empty @serialField tag Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java + test/com/sun/javadoc/T6735320/SerialFieldTest.java + test/com/sun/javadoc/T6735320/T6735320.java ! test/com/sun/javadoc/lib/JavadocTester.java Changeset: 0d8edba73d70 Author: ksrini Date: 2011-07-01 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0d8edba73d70 7060642: (javadoc) improve performance on accessing inlinedTags Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java Changeset: 111bbf1ad913 Author: darcy Date: 2011-07-05 16:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/111bbf1ad913 7025809: Provided new utility visitors supporting SourceVersion.RELEASE_8 Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java + src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java + src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java + src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java + src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! 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/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java + src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java + src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java + src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java + src/share/classes/javax/lang/model/util/TypeKindVisitor8.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java ! test/tools/javac/6402516/CheckLocalElements.java ! test/tools/javac/api/TestOperators.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/failover/FailOver15.out ! test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/TestSymtabItems.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestUnionType.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 7337295434b6 Author: jjg Date: 2011-07-07 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7337295434b6 7061125: Proposed javac argument processing performance improvement Reviewed-by: jjg, dlsmith, mcimadamore, forax Contributed-by: schlosna at gmail.com ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6358168.java Changeset: 025a370b9fc3 Author: lana Date: 2011-07-14 18:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/025a370b9fc3 Merge Changeset: 2d3096441387 Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2d3096441387 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: 36f31b87b0ab Author: ohair Date: 2011-07-22 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/36f31b87b0ab Merge Changeset: 0b5beb9562c6 Author: mcimadamore Date: 2011-07-27 19:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0b5beb9562c6 7062745: Regression: difference in overload resolution when two methods are maximally specific Summary: Fix most specific when two methods are maximally specific and only one has non-raw return type Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java + test/tools/javac/generics/rawOverride/7062745/T7062745neg.java + test/tools/javac/generics/rawOverride/7062745/T7062745neg.out + test/tools/javac/generics/rawOverride/7062745/T7062745pos.java Changeset: d5f33267a06d Author: mcimadamore Date: 2011-07-27 19:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d5f33267a06d 7046778: Project Coin: problem with diamond and member inner classes Summary: Diamond inference generates spurious error messages when target type is a member inner class Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/diamond/neg/Neg09.out Changeset: e427c42e1a7e Author: mcimadamore Date: 2011-07-27 19:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e427c42e1a7e 7057297: Project Coin: diamond erroneously accepts in array initializer expressions Summary: Diamond in array initializer expressions should be rejected Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CannotCreateArrayWithDiamond.java + test/tools/javac/generics/diamond/7057297/T7057297.java + test/tools/javac/generics/diamond/7057297/T7057297.out Changeset: 0d6d41563040 Author: ksrini Date: 2011-07-27 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0d6d41563040 7068902: (javac) allow enabling or disabling of String folding Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/StringFoldingTest.java Changeset: 64b9b7ae3366 Author: darcy Date: 2011-08-04 11:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/64b9b7ae3366 7071246: Enclosing string literal in parenthesis in switch-case crashes javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/StringsInSwitch/StringSwitches.java Changeset: c0d5f93af048 Author: jjg Date: 2011-08-05 15:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c0d5f93af048 7074189: some javac tests fail with latest jtreg 4.1 b03 Reviewed-by: darcy + test/tools/javac/lib/CompileFail.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/warnings/Serial.java Changeset: e9f118c2bd3c Author: ksrini Date: 2011-08-05 19:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e9f118c2bd3c 7064544: (javadoc) miscellaneous fixes requested by netbeans Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkTaglet/pkg/C.java Changeset: b3c059de2a61 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b3c059de2a61 Added tag jdk8-b01 for changeset e9f118c2bd3c ! .hgtags Changeset: f497fac86cf9 Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f497fac86cf9 Added tag jdk8-b02 for changeset b3c059de2a61 ! .hgtags Changeset: 5df63fd8fa64 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5df63fd8fa64 Added tag jdk8-b03 for changeset f497fac86cf9 ! .hgtags From vladimir.kozlov at oracle.com Fri Sep 2 09:57:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Sep 2011 09:57:55 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC Message-ID: <4E610B13.3000404@oracle.com> http://cr.openjdk.java.net/~kvn/7039731/webrev 7039731: arraycopy could use prefetch on SPARC Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). Thanks, Vladimir From tom.rodriguez at oracle.com Fri Sep 2 11:51:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Sep 2011 11:51:15 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC In-Reply-To: <4E610B13.3000404@oracle.com> References: <4E610B13.3000404@oracle.com> Message-ID: <05D36AA7-B761-4F32-843E-169A8AD7C8A9@oracle.com> I think this looks ok. How did you settle on 64 bytes? tom On Sep 2, 2011, at 9:57 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7039731/webrev > > 7039731: arraycopy could use prefetch on SPARC > > Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Sep 2 11:54:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Sep 2011 11:54:10 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC In-Reply-To: <05D36AA7-B761-4F32-843E-169A8AD7C8A9@oracle.com> References: <4E610B13.3000404@oracle.com> <05D36AA7-B761-4F32-843E-169A8AD7C8A9@oracle.com> Message-ID: <4E612652.1000908@oracle.com> Thank you, Tom Tom Rodriguez wrote: > I think this looks ok. How did you settle on 64 bytes? What do you mean? disjoint_long_copy_core() already did 64 bytes copy per iteration before these changes. For smaller element's sizes the shifting code is large enough to hide latency from compare and branch so it only copy 16 bytes per iteration. Thanks, Vladimir > > tom > > On Sep 2, 2011, at 9:57 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7039731/webrev >> >> 7039731: arraycopy could use prefetch on SPARC >> >> Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Fri Sep 2 12:00:18 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Sep 2011 12:00:18 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC In-Reply-To: <4E612652.1000908@oracle.com> References: <4E610B13.3000404@oracle.com> <05D36AA7-B761-4F32-843E-169A8AD7C8A9@oracle.com> <4E612652.1000908@oracle.com> Message-ID: <81738EC7-5150-4AD1-8821-90415EE99923@oracle.com> On Sep 2, 2011, at 11:54 AM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> I think this looks ok. How did you settle on 64 bytes? > > What do you mean? disjoint_long_copy_core() already did 64 bytes copy per iteration before these changes. For smaller element's sizes the shifting code is large enough to hide latency from compare and branch so it only copy 16 bytes per iteration. I'm just wondering whether 64 is big enough. It seems kind of small but maybe there's no benefit to larger sizes. tom > > Thanks, > Vladimir > >> tom >> On Sep 2, 2011, at 9:57 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7039731/webrev >>> >>> 7039731: arraycopy could use prefetch on SPARC >>> >>> Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Fri Sep 2 12:06:51 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Sep 2011 12:06:51 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC In-Reply-To: <81738EC7-5150-4AD1-8821-90415EE99923@oracle.com> References: <4E610B13.3000404@oracle.com> <05D36AA7-B761-4F32-843E-169A8AD7C8A9@oracle.com> <4E612652.1000908@oracle.com> <81738EC7-5150-4AD1-8821-90415EE99923@oracle.com> Message-ID: <4E61294B.3070409@oracle.com> I think, it is big enough. Java object are mostly small. I think I did an experiment back on T2 and did not saw improvement with larger unroll. Vladimir Tom Rodriguez wrote: > On Sep 2, 2011, at 11:54 AM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> I think this looks ok. How did you settle on 64 bytes? >> What do you mean? disjoint_long_copy_core() already did 64 bytes copy per iteration before these changes. For smaller element's sizes the shifting code is large enough to hide latency from compare and branch so it only copy 16 bytes per iteration. > > I'm just wondering whether 64 is big enough. It seems kind of small but maybe there's no benefit to larger sizes. > > tom > >> Thanks, >> Vladimir >> >>> tom >>> On Sep 2, 2011, at 9:57 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7039731/webrev >>>> >>>> 7039731: arraycopy could use prefetch on SPARC >>>> >>>> Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). >>>> >>>> Thanks, >>>> Vladimir > From tom.rodriguez at oracle.com Fri Sep 2 12:14:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Sep 2011 12:14:38 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC In-Reply-To: <4E61294B.3070409@oracle.com> References: <4E610B13.3000404@oracle.com> <05D36AA7-B761-4F32-843E-169A8AD7C8A9@oracle.com> <4E612652.1000908@oracle.com> <81738EC7-5150-4AD1-8821-90415EE99923@oracle.com> <4E61294B.3070409@oracle.com> Message-ID: <6658DE67-615E-4DE5-BB7C-63908AA0603D@oracle.com> On Sep 2, 2011, at 12:06 PM, Vladimir Kozlov wrote: > I think, it is big enough. Java object are mostly small. I think I did an experiment back on T2 and did not saw improvement with larger unroll. I agree that for common Java programs it's probably good but I think we may fall down when compared to memcpy for large arrays used as buffers. I don't think you need to address it as part of these changes but I think it's probably the main remaining flaw with our own routines. tom > > Vladimir > > Tom Rodriguez wrote: >> On Sep 2, 2011, at 11:54 AM, Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> Tom Rodriguez wrote: >>>> I think this looks ok. How did you settle on 64 bytes? >>> What do you mean? disjoint_long_copy_core() already did 64 bytes copy per iteration before these changes. For smaller element's sizes the shifting code is large enough to hide latency from compare and branch so it only copy 16 bytes per iteration. >> I'm just wondering whether 64 is big enough. It seems kind of small but maybe there's no benefit to larger sizes. >> tom >>> Thanks, >>> Vladimir >>> >>>> tom >>>> On Sep 2, 2011, at 9:57 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7039731/webrev >>>>> >>>>> 7039731: arraycopy could use prefetch on SPARC >>>>> >>>>> Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). >>>>> >>>>> Thanks, >>>>> Vladimir From igor.veresov at oracle.com Fri Sep 2 13:37:04 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 2 Sep 2011 13:37:04 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC In-Reply-To: <4E610B13.3000404@oracle.com> References: <4E610B13.3000404@oracle.com> Message-ID: <849FA51C84AD4285870BC7BEA91BE10C@oracle.com> I think this looks good. igor On Friday, September 2, 2011 at 9:57 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7039731/webrev > > 7039731: arraycopy could use prefetch on SPARC > > Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Sep 2 13:33:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Sep 2011 13:33:48 -0700 Subject: Request for reviews (M): 7039731: arraycopy could use prefetch on SPARC In-Reply-To: <849FA51C84AD4285870BC7BEA91BE10C@oracle.com> References: <4E610B13.3000404@oracle.com> <849FA51C84AD4285870BC7BEA91BE10C@oracle.com> Message-ID: <4E613DAC.1000504@oracle.com> Thank you, Igor Vladimir Igor Veresov wrote: > I think this looks good. > > igor > > On Friday, September 2, 2011 at 9:57 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7039731/webrev >> >> 7039731: arraycopy could use prefetch on SPARC >> >> Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). >> >> Thanks, >> Vladimir > > From vladimir.kozlov at oracle.com Fri Sep 2 15:23:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Sep 2011 15:23:08 -0700 Subject: Request for reviews (XXS): 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic Message-ID: <4E61574C.7020208@oracle.com> http://cr.openjdk.java.net/~kvn/7086560/webrev 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic Add check that ciEnv::_CallSite_klass is initialized. Thanks, Vladimir From john.r.rose at oracle.com Fri Sep 2 15:45:37 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 2 Sep 2011 15:45:37 -0700 Subject: Request for reviews (XXS): 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic In-Reply-To: <4E61574C.7020208@oracle.com> References: <4E61574C.7020208@oracle.com> Message-ID: <72407DEA-6578-4E7C-87D5-6745F86A59D5@oracle.com> Good. Thanks for fixing that. How was it discovered? -- John On Sep 2, 2011, at 3:23 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7086560/webrev > > 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic > > Add check that ciEnv::_CallSite_klass is initialized. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Sep 2 15:49:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Sep 2011 15:49:42 -0700 Subject: Request for reviews (XXS): 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic In-Reply-To: <72407DEA-6578-4E7C-87D5-6745F86A59D5@oracle.com> References: <4E61574C.7020208@oracle.com> <72407DEA-6578-4E7C-87D5-6745F86A59D5@oracle.com> Message-ID: <4E615D86.7040509@oracle.com> Thank you, John I am testing performance regression versus jdk7 b135 which does not have needed jsr292 java code so I have to run VM with -XX:-EnableInvokeDynamic, otherwise you get next failure: % gamma -Xcomp t Using java runtime at: /java/re/jdk/7/promoted/all/b135/binaries/solaris-amd64/jre Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/invoke/MethodHandle And today I updated my Hotspot sources to latest changeset, rebuild and it crashed in ciField()::is_call_site_target(). Vladimir John Rose wrote: > Good. Thanks for fixing that. How was it discovered? -- John > > On Sep 2, 2011, at 3:23 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7086560/webrev >> >> 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic >> >> Add check that ciEnv::_CallSite_klass is initialized. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Sep 2 17:37:08 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 03 Sep 2011 00:37:08 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7039731: arraycopy could use prefetch on SPARC Message-ID: <20110903003710.BD5DE4732B@hg.openjdk.java.net> Changeset: 2f9b79ddb05c Author: kvn Date: 2011-09-02 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2f9b79ddb05c 7039731: arraycopy could use prefetch on SPARC Summary: Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). Reviewed-by: never, iveresov ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp From tom.rodriguez at oracle.com Sat Sep 3 07:44:06 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 03 Sep 2011 14:44:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7016881: JSR 292: JDI: sun.jvm.hotspot.utilities.AssertionFailure: index out of bounds Message-ID: <20110903144412.599724734D@hg.openjdk.java.net> Changeset: 2090c623107e Author: never Date: 2011-09-02 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2090c623107e 7016881: JSR 292: JDI: sun.jvm.hotspot.utilities.AssertionFailure: index out of bounds Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java From tom.rodriguez at oracle.com Sat Sep 3 13:54:38 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 03 Sep 2011 20:54:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110903205445.C6C6F4735B@hg.openjdk.java.net> Changeset: c26de9aef2ed Author: never Date: 2011-09-02 20:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c26de9aef2ed 7071307: MethodHandle bimorphic inlining should consider the frequency Reviewed-by: twisti, roland, kvn, iveresov ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 7ffacbb338d4 Author: never Date: 2011-09-03 09:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ffacbb338d4 Merge From vladimir.kozlov at oracle.com Sat Sep 3 18:42:00 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sun, 04 Sep 2011 01:42:00 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic Message-ID: <20110904014203.D91B447365@hg.openjdk.java.net> Changeset: 7b5c767f229c Author: kvn Date: 2011-09-03 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7b5c767f229c 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic Summary: Add check that ciEnv::_CallSite_klass is initialized. Reviewed-by: jrose ! src/share/vm/ci/ciField.hpp From christian.thalinger at oracle.com Mon Sep 5 06:31:50 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 5 Sep 2011 15:31:50 +0200 Subject: Crash on current head + switchpoint patch In-Reply-To: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> Message-ID: <83A918AE-4161-42CA-93AF-1595BF36B647@oracle.com> I'm not able to reproduce it. What JRuby GIT revision fails? -- Christian On Sep 2, 2011, at 2:13 AM, Tom Rodriguez wrote: > I reproduced it. Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. When we try to use that zero as a scale for inlining tests of callees we get a div by zero. The problem has always been there I think but it was masked by the inline size cutoffs. We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. I filed 7086187 for this. If you need a workaround, this should work. > > diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp > --- a/src/share/vm/opto/bytecodeInfo.cpp > +++ b/src/share/vm/opto/bytecodeInfo.cpp > @@ -145,7 +145,7 @@ > } > > assert(invoke_count != 0, "require invocation count greater than zero"); > - int freq = call_site_count / invoke_count; > + int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0; > > // bump the max size if the call is frequent > if ((freq >= InlineFrequencyRatio) || > > You'd need to disable the assert too if you wanted to run fastdebug. > > By the way, after working around it, I get this: > > dbx) c > MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject > from MethodHandles.java:2166:in `misMatchedTypes' > from MethodHandles.java:2150:in `guardWithTest' > from SwitchPoint.java:173:in `guardWithTest' > from InvokeDynamicSupport.java:660:in `updateInvocationTarget' > from InvokeDynamicSupport.java:462:in `invocationFallback' > from ./red_black_tree.rb:68:in `method__11$RUBY$initialize' > from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call' > from CachingCallSite.java:142:in `callBlock' > from CachingCallSite.java:148:in `call' > from RubyClass.java:798:in `newInstance' > from RubyClass$i$newInstance.gen:65535:in `call' > from JavaMethod.java:256:in `call' > from MethodHandle.java:566:in `invokeWithArguments' > from InvokeDynamicSupport.java:464:in `invocationFallback' > from bm1.rb:16:in `method__0$RUBY$rbt_bm' > from bm1$method__0$RUBY$rbt_bm:65535:in `call' > from bm1$method__0$RUBY$rbt_bm:65535:in `call' > from MethodHandle.java:566:in `invokeWithArguments' > from InvokeDynamicSupport.java:464:in `invocationFallback' > from bm1.rb:30:in `block_10$RUBY$__file__' > from bm1$block_10$RUBY$__file__:65535:in `call' > from CompiledBlock.java:112:in `yield' > from CompiledBlock.java:95:in `yield' > from Block.java:130:in `yield' > from RubyFixnum.java:252:in `times' > from MethodHandleImpl.java:1154:in `invoke_L5' > from MethodHandleImpl.java:1154:in `invoke_L5' > from MethodHandle.java:566:in `invokeWithArguments' > from InvokeDynamicSupport.java:538:in `invocationFallback' > from bm1.rb:29:in `__file__' > from bm1.rb:-1:in `load' > from Ruby.java:715:in `runScript' > from Ruby.java:708:in `runScript' > from Ruby.java:615:in `runNormally' > from Ruby.java:464:in `runFromMain' > from Main.java:317:in `doRunFromMain' > from Main.java:237:in `internalRun' > from Main.java:203:in `run' > from Main.java:187:in `run' > from Main.java:167:in `main' > > Anyway, thanks for the report. > > tom > > On Sep 1, 2011, at 3:49 PM, Charles Oliver Nutter wrote: > >> I'm running a build of hotspot-comp from today plus Christian's >> "switchpoint push invalidation" patch. Getting the following crash >> running the "redblack" benchmark (http://github.com/headius/redblack): >> >> headius at headius-vbox-ubuntu:~/projects/redblack$ >> JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby >> -Xinvokedynamic.all=true -X+C bm1.rb 20 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 >> # >> # JRE version: 7.0_02-b05 >> # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode >> linux-amd64 compressed oops) >> # Problematic frame: >> # V [libjvm.so+0x2719c0] InlineTree::should_inline(ciMethod*, >> ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 >> # >> # Failed to write core dump. Core dumps have been disabled. To enable >> core dumping, try "ulimit -c unlimited" before starting Java again >> # >> # An error report file with more information is saved as: >> # /home/headius/projects/redblack/hs_err_pid14498.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> Aborted >> >> Should be easy to produce, but I can provide any info you need. JRuby >> master, amd64 product build. -Xinvokedynamic.all is the same as >> -Djruby.invokedynamic.all and turns on all current uses of >> invokedynamic (some are off because they're slow in Java 7 GA). >> >> - Charlie > From headius at headius.com Mon Sep 5 16:02:04 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 5 Sep 2011 18:02:04 -0500 Subject: Crash on current head + switchpoint patch In-Reply-To: <83A918AE-4161-42CA-93AF-1595BF36B647@oracle.com> References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> <83A918AE-4161-42CA-93AF-1595BF36B647@oracle.com> Message-ID: The same case that blew up before doesn't blow up now with hotspot-comp tip. Not sure if it's a heisenbug or if other changes made the >0 check unnecessary. - Charlie On Mon, Sep 5, 2011 at 8:31 AM, Christian Thalinger wrote: > I'm not able to reproduce it. ?What JRuby GIT revision fails? > > -- Christian > > On Sep 2, 2011, at 2:13 AM, Tom Rodriguez wrote: > >> I reproduced it. ?Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. ?When we try to use that zero as a scale for inlining tests of callees we get a div by zero. ?The problem has always been there I think but it was masked by the inline size cutoffs. ?We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. ?I filed 7086187 for this. ?If you need a workaround, this should work. >> >> diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp >> --- a/src/share/vm/opto/bytecodeInfo.cpp >> +++ b/src/share/vm/opto/bytecodeInfo.cpp >> @@ -145,7 +145,7 @@ >> ? } >> >> ? assert(invoke_count != 0, "require invocation count greater than zero"); >> - ?int freq = call_site_count / invoke_count; >> + ?int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0; >> >> ? // bump the max size if the call is frequent >> ? if ((freq >= InlineFrequencyRatio) || >> >> You'd need to disable the assert too if you wanted to run fastdebug. >> >> By the way, after working around it, I get this: >> >> dbx) c >> MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject >> ? ? ? ?from MethodHandles.java:2166:in `misMatchedTypes' >> ? ? ? ?from MethodHandles.java:2150:in `guardWithTest' >> ? ? ? ?from SwitchPoint.java:173:in `guardWithTest' >> ? ? ? ?from InvokeDynamicSupport.java:660:in `updateInvocationTarget' >> ? ? ? ?from InvokeDynamicSupport.java:462:in `invocationFallback' >> ? ? ? ?from ./red_black_tree.rb:68:in `method__11$RUBY$initialize' >> ? ? ? ?from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call' >> ? ? ? ?from CachingCallSite.java:142:in `callBlock' >> ? ? ? ?from CachingCallSite.java:148:in `call' >> ? ? ? ?from RubyClass.java:798:in `newInstance' >> ? ? ? ?from RubyClass$i$newInstance.gen:65535:in `call' >> ? ? ? ?from JavaMethod.java:256:in `call' >> ? ? ? ?from MethodHandle.java:566:in `invokeWithArguments' >> ? ? ? ?from InvokeDynamicSupport.java:464:in `invocationFallback' >> ? ? ? ?from bm1.rb:16:in `method__0$RUBY$rbt_bm' >> ? ? ? ?from bm1$method__0$RUBY$rbt_bm:65535:in `call' >> ? ? ? ?from bm1$method__0$RUBY$rbt_bm:65535:in `call' >> ? ? ? ?from MethodHandle.java:566:in `invokeWithArguments' >> ? ? ? ?from InvokeDynamicSupport.java:464:in `invocationFallback' >> ? ? ? ?from bm1.rb:30:in `block_10$RUBY$__file__' >> ? ? ? ?from bm1$block_10$RUBY$__file__:65535:in `call' >> ? ? ? ?from CompiledBlock.java:112:in `yield' >> ? ? ? ?from CompiledBlock.java:95:in `yield' >> ? ? ? ?from Block.java:130:in `yield' >> ? ? ? ?from RubyFixnum.java:252:in `times' >> ? ? ? ?from MethodHandleImpl.java:1154:in `invoke_L5' >> ? ? ? ?from MethodHandleImpl.java:1154:in `invoke_L5' >> ? ? ? ?from MethodHandle.java:566:in `invokeWithArguments' >> ? ? ? ?from InvokeDynamicSupport.java:538:in `invocationFallback' >> ? ? ? ?from bm1.rb:29:in `__file__' >> ? ? ? ?from bm1.rb:-1:in `load' >> ? ? ? ?from Ruby.java:715:in `runScript' >> ? ? ? ?from Ruby.java:708:in `runScript' >> ? ? ? ?from Ruby.java:615:in `runNormally' >> ? ? ? ?from Ruby.java:464:in `runFromMain' >> ? ? ? ?from Main.java:317:in `doRunFromMain' >> ? ? ? ?from Main.java:237:in `internalRun' >> ? ? ? ?from Main.java:203:in `run' >> ? ? ? ?from Main.java:187:in `run' >> ? ? ? ?from Main.java:167:in `main' >> >> Anyway, thanks for the report. >> >> tom >> >> On Sep 1, 2011, at 3:49 PM, Charles Oliver Nutter wrote: >> >>> I'm running a build of hotspot-comp from today plus Christian's >>> "switchpoint push invalidation" patch. Getting the following crash >>> running the "redblack" benchmark (http://github.com/headius/redblack): >>> >>> headius at headius-vbox-ubuntu:~/projects/redblack$ >>> JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby >>> -Xinvokedynamic.all=true -X+C bm1.rb 20 >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # ?SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 >>> # >>> # JRE version: 7.0_02-b05 >>> # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode >>> linux-amd64 compressed oops) >>> # Problematic frame: >>> # V ?[libjvm.so+0x2719c0] ?InlineTree::should_inline(ciMethod*, >>> ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 >>> # >>> # Failed to write core dump. Core dumps have been disabled. To enable >>> core dumping, try "ulimit -c unlimited" before starting Java again >>> # >>> # An error report file with more information is saved as: >>> # /home/headius/projects/redblack/hs_err_pid14498.log >>> # >>> # If you would like to submit a bug report, please visit: >>> # ? http://bugreport.sun.com/bugreport/crash.jsp >>> # >>> Aborted >>> >>> Should be easy to produce, but I can provide any info you need. JRuby >>> master, amd64 product build. -Xinvokedynamic.all is the same as >>> -Djruby.invokedynamic.all and turns on all current uses of >>> invokedynamic (some are off because they're slow in Java 7 GA). >>> >>> - Charlie >> > > From tom.rodriguez at oracle.com Mon Sep 5 19:21:39 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 06 Sep 2011 02:21:39 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7051798: SA-JDI: NPE in Frame.addressOfStackSlot(Frame.java:244) Message-ID: <20110906022142.14A72473D0@hg.openjdk.java.net> Changeset: 7588156f5cf9 Author: never Date: 2011-09-05 17:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7588156f5cf9 7051798: SA-JDI: NPE in Frame.addressOfStackSlot(Frame.java:244) Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java + agent/src/share/classes/sun/jvm/hotspot/code/MethodHandlesAdapterBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/RuntimeStub.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapSet.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/StackFrameImpl.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/StackValue.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/linux_amd64/LinuxAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/solaris_amd64/SolarisAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java + agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java + agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp From tom.rodriguez at oracle.com Mon Sep 5 22:50:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 5 Sep 2011 22:50:32 -0700 Subject: Crash on current head + switchpoint patch In-Reply-To: References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> <83A918AE-4161-42CA-93AF-1595BF36B647@oracle.com> Message-ID: The fix for 7071307 seems to have made it disappear, though I'm not sure why. It may just perturb the inlining such that it doesn't occur in this case. I think it's still a potential problem or at least it needs to be confirmed that it isn't a problem. tom On Sep 5, 2011, at 4:02 PM, Charles Oliver Nutter wrote: > The same case that blew up before doesn't blow up now with > hotspot-comp tip. Not sure if it's a heisenbug or if other changes > made the >0 check unnecessary. > > - Charlie > > On Mon, Sep 5, 2011 at 8:31 AM, Christian Thalinger > wrote: >> I'm not able to reproduce it. What JRuby GIT revision fails? >> >> -- Christian >> >> On Sep 2, 2011, at 2:13 AM, Tom Rodriguez wrote: >> >>> I reproduced it. Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. When we try to use that zero as a scale for inlining tests of callees we get a div by zero. The problem has always been there I think but it was masked by the inline size cutoffs. We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. I filed 7086187 for this. If you need a workaround, this should work. >>> >>> diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp >>> --- a/src/share/vm/opto/bytecodeInfo.cpp >>> +++ b/src/share/vm/opto/bytecodeInfo.cpp >>> @@ -145,7 +145,7 @@ >>> } >>> >>> assert(invoke_count != 0, "require invocation count greater than zero"); >>> - int freq = call_site_count / invoke_count; >>> + int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0; >>> >>> // bump the max size if the call is frequent >>> if ((freq >= InlineFrequencyRatio) || >>> >>> You'd need to disable the assert too if you wanted to run fastdebug. >>> >>> By the way, after working around it, I get this: >>> >>> dbx) c >>> MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject >>> from MethodHandles.java:2166:in `misMatchedTypes' >>> from MethodHandles.java:2150:in `guardWithTest' >>> from SwitchPoint.java:173:in `guardWithTest' >>> from InvokeDynamicSupport.java:660:in `updateInvocationTarget' >>> from InvokeDynamicSupport.java:462:in `invocationFallback' >>> from ./red_black_tree.rb:68:in `method__11$RUBY$initialize' >>> from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call' >>> from CachingCallSite.java:142:in `callBlock' >>> from CachingCallSite.java:148:in `call' >>> from RubyClass.java:798:in `newInstance' >>> from RubyClass$i$newInstance.gen:65535:in `call' >>> from JavaMethod.java:256:in `call' >>> from MethodHandle.java:566:in `invokeWithArguments' >>> from InvokeDynamicSupport.java:464:in `invocationFallback' >>> from bm1.rb:16:in `method__0$RUBY$rbt_bm' >>> from bm1$method__0$RUBY$rbt_bm:65535:in `call' >>> from bm1$method__0$RUBY$rbt_bm:65535:in `call' >>> from MethodHandle.java:566:in `invokeWithArguments' >>> from InvokeDynamicSupport.java:464:in `invocationFallback' >>> from bm1.rb:30:in `block_10$RUBY$__file__' >>> from bm1$block_10$RUBY$__file__:65535:in `call' >>> from CompiledBlock.java:112:in `yield' >>> from CompiledBlock.java:95:in `yield' >>> from Block.java:130:in `yield' >>> from RubyFixnum.java:252:in `times' >>> from MethodHandleImpl.java:1154:in `invoke_L5' >>> from MethodHandleImpl.java:1154:in `invoke_L5' >>> from MethodHandle.java:566:in `invokeWithArguments' >>> from InvokeDynamicSupport.java:538:in `invocationFallback' >>> from bm1.rb:29:in `__file__' >>> from bm1.rb:-1:in `load' >>> from Ruby.java:715:in `runScript' >>> from Ruby.java:708:in `runScript' >>> from Ruby.java:615:in `runNormally' >>> from Ruby.java:464:in `runFromMain' >>> from Main.java:317:in `doRunFromMain' >>> from Main.java:237:in `internalRun' >>> from Main.java:203:in `run' >>> from Main.java:187:in `run' >>> from Main.java:167:in `main' >>> >>> Anyway, thanks for the report. >>> >>> tom >>> >>> On Sep 1, 2011, at 3:49 PM, Charles Oliver Nutter wrote: >>> >>>> I'm running a build of hotspot-comp from today plus Christian's >>>> "switchpoint push invalidation" patch. Getting the following crash >>>> running the "redblack" benchmark (http://github.com/headius/redblack): >>>> >>>> headius at headius-vbox-ubuntu:~/projects/redblack$ >>>> JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby >>>> -Xinvokedynamic.all=true -X+C bm1.rb 20 >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 >>>> # >>>> # JRE version: 7.0_02-b05 >>>> # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode >>>> linux-amd64 compressed oops) >>>> # Problematic frame: >>>> # V [libjvm.so+0x2719c0] InlineTree::should_inline(ciMethod*, >>>> ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 >>>> # >>>> # Failed to write core dump. Core dumps have been disabled. To enable >>>> core dumping, try "ulimit -c unlimited" before starting Java again >>>> # >>>> # An error report file with more information is saved as: >>>> # /home/headius/projects/redblack/hs_err_pid14498.log >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>> # >>>> Aborted >>>> >>>> Should be easy to produce, but I can provide any info you need. JRuby >>>> master, amd64 product build. -Xinvokedynamic.all is the same as >>>> -Djruby.invokedynamic.all and turns on all current uses of >>>> invokedynamic (some are off because they're slow in Java 7 GA). >>>> >>>> - Charlie >>> >> >> From christian.thalinger at oracle.com Tue Sep 6 01:40:12 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Sep 2011 10:40:12 +0200 Subject: Crash on current head + switchpoint patch In-Reply-To: References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> <83A918AE-4161-42CA-93AF-1595BF36B647@oracle.com> Message-ID: On Sep 6, 2011, at 7:50 AM, Tom Rodriguez wrote: > The fix for 7071307 seems to have made it disappear, though I'm not sure why. It may just perturb the inlining such that it doesn't occur in this case. I think it's still a potential problem or at least it needs to be confirmed that it isn't a problem. I think it's not a problem. The caller is a method handle adapter and so is the callee: (dbx) p caller_method->is_method_handle_adapter() caller_method->is_method_handle_adapter() = true (dbx) p callee_method->is_method_handle_adapter() callee_method->is_method_handle_adapter() = true The logic in InlineTree::should_inline tests for caller_method->is_method_handle_adapter() and since the MDO data returns zero as invoke_count we hit the assert. But 7071307 adds this check: + if (invoke_count == 0) { + return "method handle not reached"; + } resulting in: @ 200 java.lang.invoke.MethodHandle::invokeExact (41 bytes) inline (hot) @ 8 java.lang.invoke.MethodHandle::invokeExact (20 bytes) method handle not reached @ 17 java.lang.invoke.MethodHandle::invokeExact (12 bytes) method handle not reached I think we are good and can close 7086187 as a duplicate of 7071307. -- Christian > > tom > > On Sep 5, 2011, at 4:02 PM, Charles Oliver Nutter wrote: > >> The same case that blew up before doesn't blow up now with >> hotspot-comp tip. Not sure if it's a heisenbug or if other changes >> made the >0 check unnecessary. >> >> - Charlie >> >> On Mon, Sep 5, 2011 at 8:31 AM, Christian Thalinger >> wrote: >>> I'm not able to reproduce it. What JRuby GIT revision fails? >>> >>> -- Christian >>> >>> On Sep 2, 2011, at 2:13 AM, Tom Rodriguez wrote: >>> >>>> I reproduced it. Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. When we try to use that zero as a scale for inlining tests of callees we get a div by zero. The problem has always been there I think but it was masked by the inline size cutoffs. We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. I filed 7086187 for this. If you need a workaround, this should work. >>>> >>>> diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp >>>> --- a/src/share/vm/opto/bytecodeInfo.cpp >>>> +++ b/src/share/vm/opto/bytecodeInfo.cpp >>>> @@ -145,7 +145,7 @@ >>>> } >>>> >>>> assert(invoke_count != 0, "require invocation count greater than zero"); >>>> - int freq = call_site_count / invoke_count; >>>> + int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0; >>>> >>>> // bump the max size if the call is frequent >>>> if ((freq >= InlineFrequencyRatio) || >>>> >>>> You'd need to disable the assert too if you wanted to run fastdebug. >>>> >>>> By the way, after working around it, I get this: >>>> >>>> dbx) c >>>> MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject >>>> from MethodHandles.java:2166:in `misMatchedTypes' >>>> from MethodHandles.java:2150:in `guardWithTest' >>>> from SwitchPoint.java:173:in `guardWithTest' >>>> from InvokeDynamicSupport.java:660:in `updateInvocationTarget' >>>> from InvokeDynamicSupport.java:462:in `invocationFallback' >>>> from ./red_black_tree.rb:68:in `method__11$RUBY$initialize' >>>> from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call' >>>> from CachingCallSite.java:142:in `callBlock' >>>> from CachingCallSite.java:148:in `call' >>>> from RubyClass.java:798:in `newInstance' >>>> from RubyClass$i$newInstance.gen:65535:in `call' >>>> from JavaMethod.java:256:in `call' >>>> from MethodHandle.java:566:in `invokeWithArguments' >>>> from InvokeDynamicSupport.java:464:in `invocationFallback' >>>> from bm1.rb:16:in `method__0$RUBY$rbt_bm' >>>> from bm1$method__0$RUBY$rbt_bm:65535:in `call' >>>> from bm1$method__0$RUBY$rbt_bm:65535:in `call' >>>> from MethodHandle.java:566:in `invokeWithArguments' >>>> from InvokeDynamicSupport.java:464:in `invocationFallback' >>>> from bm1.rb:30:in `block_10$RUBY$__file__' >>>> from bm1$block_10$RUBY$__file__:65535:in `call' >>>> from CompiledBlock.java:112:in `yield' >>>> from CompiledBlock.java:95:in `yield' >>>> from Block.java:130:in `yield' >>>> from RubyFixnum.java:252:in `times' >>>> from MethodHandleImpl.java:1154:in `invoke_L5' >>>> from MethodHandleImpl.java:1154:in `invoke_L5' >>>> from MethodHandle.java:566:in `invokeWithArguments' >>>> from InvokeDynamicSupport.java:538:in `invocationFallback' >>>> from bm1.rb:29:in `__file__' >>>> from bm1.rb:-1:in `load' >>>> from Ruby.java:715:in `runScript' >>>> from Ruby.java:708:in `runScript' >>>> from Ruby.java:615:in `runNormally' >>>> from Ruby.java:464:in `runFromMain' >>>> from Main.java:317:in `doRunFromMain' >>>> from Main.java:237:in `internalRun' >>>> from Main.java:203:in `run' >>>> from Main.java:187:in `run' >>>> from Main.java:167:in `main' >>>> >>>> Anyway, thanks for the report. >>>> >>>> tom >>>> >>>> On Sep 1, 2011, at 3:49 PM, Charles Oliver Nutter wrote: >>>> >>>>> I'm running a build of hotspot-comp from today plus Christian's >>>>> "switchpoint push invalidation" patch. Getting the following crash >>>>> running the "redblack" benchmark (http://github.com/headius/redblack): >>>>> >>>>> headius at headius-vbox-ubuntu:~/projects/redblack$ >>>>> JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby >>>>> -Xinvokedynamic.all=true -X+C bm1.rb 20 >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 >>>>> # >>>>> # JRE version: 7.0_02-b05 >>>>> # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode >>>>> linux-amd64 compressed oops) >>>>> # Problematic frame: >>>>> # V [libjvm.so+0x2719c0] InlineTree::should_inline(ciMethod*, >>>>> ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 >>>>> # >>>>> # Failed to write core dump. Core dumps have been disabled. To enable >>>>> core dumping, try "ulimit -c unlimited" before starting Java again >>>>> # >>>>> # An error report file with more information is saved as: >>>>> # /home/headius/projects/redblack/hs_err_pid14498.log >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>> # >>>>> Aborted >>>>> >>>>> Should be easy to produce, but I can provide any info you need. JRuby >>>>> master, amd64 product build. -Xinvokedynamic.all is the same as >>>>> -Djruby.invokedynamic.all and turns on all current uses of >>>>> invokedynamic (some are off because they're slow in Java 7 GA). >>>>> >>>>> - Charlie >>>> >>> >>> > From roland.westrelin at oracle.com Tue Sep 6 04:54:02 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 6 Sep 2011 13:54:02 +0200 Subject: Review Request (M): 7077312: Provide a CALL effect for instruct declaration in the ad file Message-ID: http://cr.openjdk.java.net/~roland/7077312/webrev.00/ This add the ability to declare an instruct in the ad file as having the effect of a leaf runtime call: instruct divL_reg_reg(R0R1RegL dst, R2R3RegL src1, R0R1RegL src2) %{ match(Set dst (DivL src1 src2)); effect(CALL); This declares this instruct as killing or preserving a set of registers according to the calling convention. Useful for nodes that are implemented with actual runtime call. Roland. From christian.thalinger at oracle.com Tue Sep 6 05:42:13 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Sep 2011 14:42:13 +0200 Subject: Review Request (M): 7077312: Provide a CALL effect for instruct declaration in the ad file In-Reply-To: References: Message-ID: Looks good. -- Christian On Sep 6, 2011, at 1:54 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7077312/webrev.00/ > > This add the ability to declare an instruct in the ad file as having the effect of a leaf runtime call: > > instruct divL_reg_reg(R0R1RegL dst, R2R3RegL src1, R0R1RegL src2) %{ > match(Set dst (DivL src1 src2)); > effect(CALL); > > This declares this instruct as killing or preserving a set of registers according to the calling convention. Useful for nodes that are implemented with actual runtime call. > > Roland. From headius at headius.com Tue Sep 6 07:53:56 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 09:53:56 -0500 Subject: Segfault toward end of hotspot-comp build Message-ID: Perhaps I've got an environmental issue here, but I'd like to be sure I'm building hotspot-comp properly. What's causing this? Linking vm... echo Linking launcher... Linking launcher... gcc -m64 -Xlinker -O1 -Wl,--hash-style=both -Xlinker -z -Xlinker noexecstack -m64 -Xlinker -export-dynamic -L `pwd` -o gamma launcher/java_md.o launcher/jli_util.o launcher/wildcard.o launcher/java.o -ljvm -lm -ldl -lpthread make[4]: Leaving directory `/home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product' All done. make[3]: Leaving directory `/home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product' cd linux_amd64_compiler2/product && ./test_gamma java full version "1.7.0_02-ea-b05" Using java runtime at: /home/headius/java/re/j2se/1.7.0/latest/binaries/linux-amd64/jre # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (globals.cpp:374), pid=14670, tid=47908911146752 # guarantee(faddr != NULL && faddr->is_uintx()) failed: wrong flag type # # JRE version: 7.0_02-b05 # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product/hs_err_pid14670.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Aborted make[2]: *** [product] Error 134 make[2]: Leaving directory `/home/headius/projects/hotspot/build/linux' make[1]: *** [generic_build2] Error 2 make[1]: Leaving directory `/home/headius/projects/hotspot/make' make: *** [product] Error 2 make: Leaving directory `/home/headius/projects/hotspot/make' And the relevant bit of hs_err: --------------- T H R E A D --------------- Current thread is native thread Stack: [0x00002b92a9916000,0x00002b92a9a17000], sp=0x00002b92a9a14930, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x867454] VMError::report_and_die()+0x174 V [libjvm.so+0x3e0b6a] report_vm_error(char const*, int, char const*, char const*)+0x4a V [libjvm.so+0x492000] CommandLineFlagsEx::uintxAtPut(CommandLineFlagWithType, unsigned long, FlagValueOrigin)+0x60 V [libjvm.so+0x21b82a] Arguments::set_heap_size()+0x10a V [libjvm.so+0x22009d] Arguments::parse(JavaVMInitArgs const*)+0x4bd V [libjvm.so+0x81f66d] Threads::create_vm(JavaVMInitArgs*, bool*)+0x8d V [libjvm.so+0x528a0f] JNI_CreateJavaVM+0x6f C [gamma+0x5002] printf@@GLIBC_2.2.5+0x5002 C [gamma+0x3dd8] JavaMain+0xc1 The script I'm using to build: https://gist.github.com/1148321 - Charlie From roland.westrelin at oracle.com Tue Sep 6 08:09:08 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 06 Sep 2011 17:09:08 +0200 Subject: request for review (XS): 7086394: c2/arm: enable UseFPUForSpilling Message-ID: ARM has support for moving 64bit values between a pair of integer registers and a double register. http://cr.openjdk.java.net/~roland/7086394/webrev.00/ Roland. From christian.thalinger at oracle.com Tue Sep 6 08:33:41 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Sep 2011 17:33:41 +0200 Subject: Segfault toward end of hotspot-comp build In-Reply-To: References: Message-ID: <990C9C53-5237-49AD-8E83-D20B645773AD@oracle.com> That's odd. I never saw an error like this. Did you change anything in src/share/vm/runtime/arguments.cpp? Can you try a debug build (make jvmg) so we can see where this happens? -- Christian On Sep 6, 2011, at 4:53 PM, Charles Oliver Nutter wrote: > Perhaps I've got an environmental issue here, but I'd like to be sure > I'm building hotspot-comp properly. What's causing this? > > Linking vm... > echo Linking launcher... > Linking launcher... > gcc -m64 -Xlinker -O1 -Wl,--hash-style=both -Xlinker -z -Xlinker > noexecstack -m64 -Xlinker -export-dynamic -L `pwd` -o gamma > launcher/java_md.o launcher/jli_util.o launcher/wildcard.o > launcher/java.o -ljvm -lm -ldl -lpthread > make[4]: Leaving directory > `/home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product' > All done. > make[3]: Leaving directory > `/home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product' > cd linux_amd64_compiler2/product && ./test_gamma > java full version "1.7.0_02-ea-b05" > Using java runtime at: > /home/headius/java/re/j2se/1.7.0/latest/binaries/linux-amd64/jre > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (globals.cpp:374), pid=14670, tid=47908911146752 > # guarantee(faddr != NULL && faddr->is_uintx()) failed: wrong flag type > # > # JRE version: 7.0_02-b05 > # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode > linux-amd64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product/hs_err_pid14670.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Aborted > make[2]: *** [product] Error 134 > make[2]: Leaving directory `/home/headius/projects/hotspot/build/linux' > make[1]: *** [generic_build2] Error 2 > make[1]: Leaving directory `/home/headius/projects/hotspot/make' > make: *** [product] Error 2 > make: Leaving directory `/home/headius/projects/hotspot/make' > > And the relevant bit of hs_err: > > --------------- T H R E A D --------------- > > Current thread is native thread > > Stack: [0x00002b92a9916000,0x00002b92a9a17000], > sp=0x00002b92a9a14930, free space=1018k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x867454] VMError::report_and_die()+0x174 > V [libjvm.so+0x3e0b6a] report_vm_error(char const*, int, char > const*, char const*)+0x4a > V [libjvm.so+0x492000] > CommandLineFlagsEx::uintxAtPut(CommandLineFlagWithType, unsigned long, > FlagValueOrigin)+0x60 > V [libjvm.so+0x21b82a] Arguments::set_heap_size()+0x10a > V [libjvm.so+0x22009d] Arguments::parse(JavaVMInitArgs const*)+0x4bd > V [libjvm.so+0x81f66d] Threads::create_vm(JavaVMInitArgs*, bool*)+0x8d > V [libjvm.so+0x528a0f] JNI_CreateJavaVM+0x6f > C [gamma+0x5002] printf@@GLIBC_2.2.5+0x5002 > C [gamma+0x3dd8] JavaMain+0xc1 > > The script I'm using to build: > > https://gist.github.com/1148321 > > - Charlie From tom.rodriguez at oracle.com Tue Sep 6 08:39:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Sep 2011 08:39:59 -0700 Subject: Crash on current head + switchpoint patch In-Reply-To: References: <5B31D3D9-6DD2-4415-9AE0-FD2D13FFAAD0@oracle.com> <83A918AE-4161-42CA-93AF-1595BF36B647@oracle.com> Message-ID: On Sep 6, 2011, at 1:40 AM, Christian Thalinger wrote: > > On Sep 6, 2011, at 7:50 AM, Tom Rodriguez wrote: > >> The fix for 7071307 seems to have made it disappear, though I'm not sure why. It may just perturb the inlining such that it doesn't occur in this case. I think it's still a potential problem or at least it needs to be confirmed that it isn't a problem. > > I think it's not a problem. The caller is a method handle adapter and so is the callee: > > (dbx) p caller_method->is_method_handle_adapter() > caller_method->is_method_handle_adapter() = true > (dbx) p callee_method->is_method_handle_adapter() > callee_method->is_method_handle_adapter() = true > > The logic in InlineTree::should_inline tests for caller_method->is_method_handle_adapter() and since the MDO data returns zero as invoke_count we hit the assert. But 7071307 adds this check: > > + if (invoke_count == 0) { > + return "method handle not reached"; > + } Sounds good. Thanks for figuring this out. tom > > resulting in: > > @ 200 java.lang.invoke.MethodHandle::invokeExact (41 bytes) inline (hot) > @ 8 java.lang.invoke.MethodHandle::invokeExact (20 bytes) method handle not reached > @ 17 java.lang.invoke.MethodHandle::invokeExact (12 bytes) method handle not reached > > I think we are good and can close 7086187 as a duplicate of 7071307. > > -- Christian > >> >> tom >> >> On Sep 5, 2011, at 4:02 PM, Charles Oliver Nutter wrote: >> >>> The same case that blew up before doesn't blow up now with >>> hotspot-comp tip. Not sure if it's a heisenbug or if other changes >>> made the >0 check unnecessary. >>> >>> - Charlie >>> >>> On Mon, Sep 5, 2011 at 8:31 AM, Christian Thalinger >>> wrote: >>>> I'm not able to reproduce it. What JRuby GIT revision fails? >>>> >>>> -- Christian >>>> >>>> On Sep 2, 2011, at 2:13 AM, Tom Rodriguez wrote: >>>> >>>>> I reproduced it. Basically we've chosen to inline a method handle because that's what we do but the profile for the call site says it's never been invoked, so the invoke_count is 0. When we try to use that zero as a scale for inlining tests of callees we get a div by zero. The problem has always been there I think but it was masked by the inline size cutoffs. We may want to emit uncommon traps for invokedynamic call sites that haven't been reached according to profiles. I filed 7086187 for this. If you need a workaround, this should work. >>>>> >>>>> diff -r a32de5085326 src/share/vm/opto/bytecodeInfo.cpp >>>>> --- a/src/share/vm/opto/bytecodeInfo.cpp >>>>> +++ b/src/share/vm/opto/bytecodeInfo.cpp >>>>> @@ -145,7 +145,7 @@ >>>>> } >>>>> >>>>> assert(invoke_count != 0, "require invocation count greater than zero"); >>>>> - int freq = call_site_count / invoke_count; >>>>> + int freq = invoke_count > 0 ? (call_site_count / invoke_count) : 0; >>>>> >>>>> // bump the max size if the call is frequent >>>>> if ((freq >= InlineFrequencyRatio) || >>>>> >>>>> You'd need to disable the assert too if you wanted to run fastdebug. >>>>> >>>>> By the way, after working around it, I get this: >>>>> >>>>> dbx) c >>>>> MethodHandleStatics.java:102:in `newIllegalArgumentException': java.lang.IllegalArgumentException: target and fallback types must match: (ThreadContext,IRubyObject,IRubyObject,String)IRubyObject != (JRubyCallSite,ThreadContext,IRubyObject,IRubyObject,String)IRubyObject >>>>> from MethodHandles.java:2166:in `misMatchedTypes' >>>>> from MethodHandles.java:2150:in `guardWithTest' >>>>> from SwitchPoint.java:173:in `guardWithTest' >>>>> from InvokeDynamicSupport.java:660:in `updateInvocationTarget' >>>>> from InvokeDynamicSupport.java:462:in `invocationFallback' >>>>> from ./red_black_tree.rb:68:in `method__11$RUBY$initialize' >>>>> from $_dot_$red_black_tree$method__11$RUBY$initialize:65535:in `call' >>>>> from CachingCallSite.java:142:in `callBlock' >>>>> from CachingCallSite.java:148:in `call' >>>>> from RubyClass.java:798:in `newInstance' >>>>> from RubyClass$i$newInstance.gen:65535:in `call' >>>>> from JavaMethod.java:256:in `call' >>>>> from MethodHandle.java:566:in `invokeWithArguments' >>>>> from InvokeDynamicSupport.java:464:in `invocationFallback' >>>>> from bm1.rb:16:in `method__0$RUBY$rbt_bm' >>>>> from bm1$method__0$RUBY$rbt_bm:65535:in `call' >>>>> from bm1$method__0$RUBY$rbt_bm:65535:in `call' >>>>> from MethodHandle.java:566:in `invokeWithArguments' >>>>> from InvokeDynamicSupport.java:464:in `invocationFallback' >>>>> from bm1.rb:30:in `block_10$RUBY$__file__' >>>>> from bm1$block_10$RUBY$__file__:65535:in `call' >>>>> from CompiledBlock.java:112:in `yield' >>>>> from CompiledBlock.java:95:in `yield' >>>>> from Block.java:130:in `yield' >>>>> from RubyFixnum.java:252:in `times' >>>>> from MethodHandleImpl.java:1154:in `invoke_L5' >>>>> from MethodHandleImpl.java:1154:in `invoke_L5' >>>>> from MethodHandle.java:566:in `invokeWithArguments' >>>>> from InvokeDynamicSupport.java:538:in `invocationFallback' >>>>> from bm1.rb:29:in `__file__' >>>>> from bm1.rb:-1:in `load' >>>>> from Ruby.java:715:in `runScript' >>>>> from Ruby.java:708:in `runScript' >>>>> from Ruby.java:615:in `runNormally' >>>>> from Ruby.java:464:in `runFromMain' >>>>> from Main.java:317:in `doRunFromMain' >>>>> from Main.java:237:in `internalRun' >>>>> from Main.java:203:in `run' >>>>> from Main.java:187:in `run' >>>>> from Main.java:167:in `main' >>>>> >>>>> Anyway, thanks for the report. >>>>> >>>>> tom >>>>> >>>>> On Sep 1, 2011, at 3:49 PM, Charles Oliver Nutter wrote: >>>>> >>>>>> I'm running a build of hotspot-comp from today plus Christian's >>>>>> "switchpoint push invalidation" patch. Getting the following crash >>>>>> running the "redblack" benchmark (http://github.com/headius/redblack): >>>>>> >>>>>> headius at headius-vbox-ubuntu:~/projects/redblack$ >>>>>> JAVA_HOME=../hotspot/build/linux/jdk-linux-amd64/ ../jruby/bin/jruby >>>>>> -Xinvokedynamic.all=true -X+C bm1.rb 20 >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # SIGFPE (0x8) at pc=0x00007fdbad4439c0, pid=14498, tid=140581309708032 >>>>>> # >>>>>> # JRE version: 7.0_02-b05 >>>>>> # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode >>>>>> linux-amd64 compressed oops) >>>>>> # Problematic frame: >>>>>> # V [libjvm.so+0x2719c0] InlineTree::should_inline(ciMethod*, >>>>>> ciMethod*, int, ciCallProfile&, WarmCallInfo*) const+0x100 >>>>>> # >>>>>> # Failed to write core dump. Core dumps have been disabled. To enable >>>>>> core dumping, try "ulimit -c unlimited" before starting Java again >>>>>> # >>>>>> # An error report file with more information is saved as: >>>>>> # /home/headius/projects/redblack/hs_err_pid14498.log >>>>>> # >>>>>> # If you would like to submit a bug report, please visit: >>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>> # >>>>>> Aborted >>>>>> >>>>>> Should be easy to produce, but I can provide any info you need. JRuby >>>>>> master, amd64 product build. -Xinvokedynamic.all is the same as >>>>>> -Djruby.invokedynamic.all and turns on all current uses of >>>>>> invokedynamic (some are off because they're slow in Java 7 GA). >>>>>> >>>>>> - Charlie >>>>> >>>> >>>> >> > From rednaxelafx at gmail.com Tue Sep 6 08:51:53 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 6 Sep 2011 23:51:53 +0800 Subject: Segfault toward end of hotspot-comp build In-Reply-To: References: Message-ID: Hi Charles, It's not a segfault, but rather hitting an assertion when initializing the VM in the test gamma run, during the last part of the build process. The VM is already fully built and linked by then, so it looks like the VM compiled cleanly. A wild guess of what caused this problem would be: something's not right in your HotSpot code, specifically, src/share/vm/runtime/arguments.cpp, in Arguments::set_heap_size(), or in src/share/vm/runtime/globals.hpp. The assertion is indicating that someone is trying to set a flag with the type uintx (in Arguments::set_heap_size(), with either of the two macros, FLAG_SET_CMDLINE or FLAG_SET_ERGO), but the flag was declared to be of another type (in globals.hpp). I'd suggest cleaning the source directory (at least arguments.cpp and globals.hpp) and try building it again. I've just done building the current tip of hotspot-comp (with no other patches applied), and nothing weird happened: cd linux_amd64_compiler2/product && ./test_gamma java full version "1.6.0_25-b06" Using java runtime at: /home/rednaxelafx/sdk/jdk1.6.0_25/jre java version "1.6.0_25" Java(TM) SE Runtime Environment (build 1.6.0_25-b06) OpenJDK 64-Bit Server VM (build 22.0-b02-internal, mixed mode) 1. A1 B5 C8 D6 E3 F7 G2 H4 ... 92. A8 B4 C1 D3 E6 F2 G7 H5 Regards, Kris Mok On Tue, Sep 6, 2011 at 10:53 PM, Charles Oliver Nutter wrote: > Perhaps I've got an environmental issue here, but I'd like to be sure > I'm building hotspot-comp properly. What's causing this? > > Linking vm... > echo Linking launcher... > Linking launcher... > gcc -m64 -Xlinker -O1 -Wl,--hash-style=both -Xlinker -z -Xlinker > noexecstack -m64 -Xlinker -export-dynamic -L `pwd` -o gamma > launcher/java_md.o launcher/jli_util.o launcher/wildcard.o > launcher/java.o -ljvm -lm -ldl -lpthread > make[4]: Leaving directory > `/home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product' > All done. > make[3]: Leaving directory > `/home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product' > cd linux_amd64_compiler2/product && ./test_gamma > java full version "1.7.0_02-ea-b05" > Using java runtime at: > /home/headius/java/re/j2se/1.7.0/latest/binaries/linux-amd64/jre > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (globals.cpp:374), pid=14670, tid=47908911146752 > # guarantee(faddr != NULL && faddr->is_uintx()) failed: wrong flag type > # > # JRE version: 7.0_02-b05 > # Java VM: OpenJDK 64-Bit Server VM (22.0-b02-internal mixed mode > linux-amd64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # > /home/headius/projects/hotspot/build/linux/linux_amd64_compiler2/product/hs_err_pid14670.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Aborted > make[2]: *** [product] Error 134 > make[2]: Leaving directory `/home/headius/projects/hotspot/build/linux' > make[1]: *** [generic_build2] Error 2 > make[1]: Leaving directory `/home/headius/projects/hotspot/make' > make: *** [product] Error 2 > make: Leaving directory `/home/headius/projects/hotspot/make' > > And the relevant bit of hs_err: > > --------------- T H R E A D --------------- > > Current thread is native thread > > Stack: [0x00002b92a9916000,0x00002b92a9a17000], > sp=0x00002b92a9a14930, free space=1018k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0x867454] VMError::report_and_die()+0x174 > V [libjvm.so+0x3e0b6a] report_vm_error(char const*, int, char > const*, char const*)+0x4a > V [libjvm.so+0x492000] > CommandLineFlagsEx::uintxAtPut(CommandLineFlagWithType, unsigned long, > FlagValueOrigin)+0x60 > V [libjvm.so+0x21b82a] Arguments::set_heap_size()+0x10a > V [libjvm.so+0x22009d] Arguments::parse(JavaVMInitArgs const*)+0x4bd > V [libjvm.so+0x81f66d] Threads::create_vm(JavaVMInitArgs*, bool*)+0x8d > V [libjvm.so+0x528a0f] JNI_CreateJavaVM+0x6f > C [gamma+0x5002] printf@@GLIBC_2.2.5+0x5002 > C [gamma+0x3dd8] JavaMain+0xc1 > > The script I'm using to build: > > https://gist.github.com/1148321 > > - Charlie > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110906/f685d7e6/attachment.html From roland.westrelin at oracle.com Tue Sep 6 09:00:17 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 06 Sep 2011 18:00:17 +0200 Subject: review request (S): 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs Message-ID: http://cr.openjdk.java.net/~roland/7087453/webrev.00/ When PhaseChaitin::yank_if_dead() hits a node with MachTemp inputs it crashes the VM with assertion: assert(old->req() <= 2, "can't handle more inputs"); It should be able to handle MachTemps as a special case by yanking them as well. Roland. From bertrand.delsart at oracle.com Tue Sep 6 09:04:36 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 06 Sep 2011 18:04:36 +0200 Subject: Request for Review (XS): 7087445, Improve platform independence of JSR292 shared code Message-ID: <4E664494.3010205@oracle.com> Small shared changes necessary to improve portability of jsr292 on some platforms. http://cr.openjdk.java.net/~bdelsart/7087445/webrev.00/ Should have no impact on the existing ports, as long as you add this backward compatible definition (added to SPARC, x86 and zero): intptr_t *frame::initial_deoptimization_info() { return fp(); } Thanks, Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From headius at headius.com Tue Sep 6 10:08:07 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 12:08:07 -0500 Subject: Segfault toward end of hotspot-comp build In-Reply-To: References: Message-ID: On Tue, Sep 6, 2011 at 10:51 AM, Krystal Mok wrote: > Hi Charles, > It's not a segfault, but rather hitting an assertion when initializing the > VM in the test gamma run, during the last part of the build process. > The VM is already fully built and linked by then, so it looks like the VM > compiled cleanly. I do not have any changes locally, so I'll try a full clean build. I've been doing incrementals for a few days, and perhaps a change came in that made incompatible changes gcc did not pick up. - Charlie From headius at headius.com Tue Sep 6 10:16:03 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 12:16:03 -0500 Subject: Segfault toward end of hotspot-comp build In-Reply-To: References: Message-ID: On Tue, Sep 6, 2011 at 12:08 PM, Charles Oliver Nutter wrote: > I do not have any changes locally, so I'll try a full clean build. > I've been doing incrementals for a few days, and perhaps a change came > in that made incompatible changes gcc did not pick up. Ok, looks like it was a dirty build. It worked ok after a clean. Next up (I'm trying to get my build instructions 100% correct): make[1]: *** No rule to make target `/home/headius/projects/hotspot/build/linux/jdk-linux-amd64/fastdebug/jre/lib/amd64/libjsig.so', needed by `generic_export'. Stop. Not sure what I need to do to eliminate this error. This happens when doing make product update_jdk. Is it simply an artifact of not having done a fastdebug build? - Charlie From vladimir.kozlov at oracle.com Tue Sep 6 10:56:49 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Sep 2011 10:56:49 -0700 Subject: request for review (XS): 7086394: c2/arm: enable UseFPUForSpilling In-Reply-To: References: Message-ID: <4E665EE1.9010404@oracle.com> Good. Vladimir Roland Westrelin wrote: > ARM has support for moving 64bit values between a pair of integer > registers and a double register. > > http://cr.openjdk.java.net/~roland/7086394/webrev.00/ > > Roland. From tom.rodriguez at oracle.com Tue Sep 6 11:18:58 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Sep 2011 11:18:58 -0700 Subject: request for review (XS): 7086394: c2/arm: enable UseFPUForSpilling In-Reply-To: References: Message-ID: <69962F64-9AA8-4F09-89A7-FD5CD572CC5C@oracle.com> Looks good. tom On Sep 6, 2011, at 8:09 AM, Roland Westrelin wrote: > ARM has support for moving 64bit values between a pair of integer registers and a double register. > > http://cr.openjdk.java.net/~roland/7086394/webrev.00/ > > Roland. From tom.rodriguez at oracle.com Tue Sep 6 11:22:17 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Sep 2011 11:22:17 -0700 Subject: Review Request (M): 7077312: Provide a CALL effect for instruct declaration in the ad file In-Reply-To: References: Message-ID: <46A8E1E7-D533-4DFA-B975-E8B5BADB4532@oracle.com> Looks good. tom On Sep 6, 2011, at 4:54 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7077312/webrev.00/ > > This add the ability to declare an instruct in the ad file as having the effect of a leaf runtime call: > > instruct divL_reg_reg(R0R1RegL dst, R2R3RegL src1, R0R1RegL src2) %{ > match(Set dst (DivL src1 src2)); > effect(CALL); > > This declares this instruct as killing or preserving a set of registers according to the calling convention. Useful for nodes that are implemented with actual runtime call. > > Roland. From tom.rodriguez at oracle.com Tue Sep 6 11:23:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Sep 2011 11:23:31 -0700 Subject: review request (S): 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs In-Reply-To: References: Message-ID: That looks good. tom On Sep 6, 2011, at 9:00 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7087453/webrev.00/ > > When PhaseChaitin::yank_if_dead() hits a node with MachTemp inputs it crashes the VM with assertion: > assert(old->req() <= 2, "can't handle more inputs"); > It should be able to handle MachTemps as a special case by yanking them as well. > > Roland. From vladimir.kozlov at oracle.com Tue Sep 6 11:19:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Sep 2011 11:19:32 -0700 Subject: review request (S): 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs In-Reply-To: References: Message-ID: <4E666434.1040608@oracle.com> So why this code can't handle more then one non TEMP inputs? Is it because the 'old' node should have only one non TEMP input (which I doubt) or yank_if_dead() code is not correct - can't process more inputs? If it is later we should fix the code. Thanks, Vladimir Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7087453/webrev.00/ > > When PhaseChaitin::yank_if_dead() hits a node with MachTemp inputs it > crashes the VM with assertion: > assert(old->req() <= 2, "can't handle more inputs"); > It should be able to handle MachTemps as a special case by yanking them > as well. > > Roland. From tom.rodriguez at oracle.com Tue Sep 6 11:45:56 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Sep 2011 11:45:56 -0700 Subject: review request (S): 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs In-Reply-To: <4E666434.1040608@oracle.com> References: <4E666434.1040608@oracle.com> Message-ID: <5B55BC4F-3CAE-4AFB-AD03-9BDDFAA36991@oracle.com> On Sep 6, 2011, at 11:19 AM, Vladimir Kozlov wrote: > So why this code can't handle more then one non TEMP inputs? Is it because the 'old' node should have only one non TEMP input (which I doubt) or yank_if_dead() code is not correct - can't process more inputs? If it is later we should fix the code. In our current world, having a node with more than one non-temp input go dead indicates a bug since it shouldn't happen. It never needed to handle more than one input going dead because it was only ever dealing with MSCs or rematerializable constants. MachTemp inputs to constant were something I hadn't considered but they are easy to deal with. Someday that might change but I don't see any reason to make this code more flexible. tom > > Thanks, > Vladimir > > Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/7087453/webrev.00/ >> When PhaseChaitin::yank_if_dead() hits a node with MachTemp inputs it crashes the VM with assertion: >> assert(old->req() <= 2, "can't handle more inputs"); >> It should be able to handle MachTemps as a special case by yanking them as well. >> Roland. From vladimir.kozlov at oracle.com Tue Sep 6 11:49:49 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Sep 2011 11:49:49 -0700 Subject: review request (S): 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs In-Reply-To: <5B55BC4F-3CAE-4AFB-AD03-9BDDFAA36991@oracle.com> References: <4E666434.1040608@oracle.com> <5B55BC4F-3CAE-4AFB-AD03-9BDDFAA36991@oracle.com> Message-ID: <4E666B4D.2050102@oracle.com> thanks, Tom Vladimir Tom Rodriguez wrote: > On Sep 6, 2011, at 11:19 AM, Vladimir Kozlov wrote: > >> So why this code can't handle more then one non TEMP inputs? Is it because the 'old' node should have only one non TEMP input (which I doubt) or yank_if_dead() code is not correct - can't process more inputs? If it is later we should fix the code. > > In our current world, having a node with more than one non-temp input go dead indicates a bug since it shouldn't happen. It never needed to handle more than one input going dead because it was only ever dealing with MSCs or rematerializable constants. MachTemp inputs to constant were something I hadn't considered but they are easy to deal with. Someday that might change but I don't see any reason to make this code more flexible. > > tom > >> Thanks, >> Vladimir >> >> Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/7087453/webrev.00/ >>> When PhaseChaitin::yank_if_dead() hits a node with MachTemp inputs it crashes the VM with assertion: >>> assert(old->req() <= 2, "can't handle more inputs"); >>> It should be able to handle MachTemps as a special case by yanking them as well. >>> Roland. > From vladimir.kozlov at oracle.com Tue Sep 6 11:50:47 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Sep 2011 11:50:47 -0700 Subject: review request (S): 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs In-Reply-To: References: Message-ID: <4E666B87.4060309@oracle.com> Good. Vladimir Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7087453/webrev.00/ > > When PhaseChaitin::yank_if_dead() hits a node with MachTemp inputs it > crashes the VM with assertion: > assert(old->req() <= 2, "can't handle more inputs"); > It should be able to handle MachTemps as a special case by yanking them > as well. > > Roland. From azeem.jiva at oracle.com Tue Sep 6 13:21:45 2011 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Tue, 06 Sep 2011 15:21:45 -0500 Subject: HotSpot build on SPARC/Solaris Message-ID: <4E6680D9.2040505@oracle.com> Trying to build on SPARC/Solaris I get the following error: "/root/hsx/src/os/solaris/vm/os_solaris.cpp", line 6428: Error: Formal argument 6 of type unsigned* in call to recvfrom(int, void*, unsigned long, int, sockaddr*, unsigned*) is being passed int*. "/root/hsx/src/os/solaris/vm/os_solaris.cpp", line 6428: Error: Formal argument 6 of type unsigned* in call to recvfrom(int, void*, unsigned long, int, sockaddr*, unsigned*) is being passed int*. It seems the method signature changed in Solaris 11 from int pointer to an unsigned pointer. I can get around the issue by casting fromlen to an unsigned pointer, but that's dangerous. I guess I'm looking for ideas for a better solution to this. diff -r 7588156f5cf9 src/os/solaris/vm/os_solaris.cpp --- a/src/os/solaris/vm/os_solaris.cpp Mon Sep 05 17:09:05 2011 -0700 +++ b/src/os/solaris/vm/os_solaris.cpp Tue Sep 06 20:07:09 2011 +0000 @@ -6425,7 +6425,7 @@ sockaddr *from, int *fromlen) { //%%note jvm_r11 INTERRUPTIBLE_RETURN_INT((int)::recvfrom(fd, buf, nBytes,\ - flags, from, fromlen), os::Solaris::clear_interrupted); + flags, from, (unsigned*)fromlen), os::Solaris::clear_interrupted); } int os::sendto(int fd, char *buf, int len, int flags, -- Azeem Jiva @javawithjiva From ahughes at redhat.com Tue Sep 6 14:32:14 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 6 Sep 2011 22:32:14 +0100 Subject: HotSpot build on SPARC/Solaris In-Reply-To: <4E6680D9.2040505@oracle.com> References: <4E6680D9.2040505@oracle.com> Message-ID: <20110906213214.GG19081@rivendell.middle-earth.co.uk> On 15:21 Tue 06 Sep , Azeem Jiva wrote: > Trying to build on SPARC/Solaris I get the following error: > > "/root/hsx/src/os/solaris/vm/os_solaris.cpp", line 6428: Error: Formal > argument 6 of type unsigned* in call to recvfrom(int, void*, unsigned > long, int, sockaddr*, unsigned*) is being passed int*. > "/root/hsx/src/os/solaris/vm/os_solaris.cpp", line 6428: Error: Formal > argument 6 of type unsigned* in call to recvfrom(int, void*, unsigned > long, int, sockaddr*, unsigned*) is being passed int*. > > It seems the method signature changed in Solaris 11 from int pointer to > an unsigned pointer. I can get around the issue by casting fromlen to > an unsigned pointer, but that's dangerous. I guess I'm looking for > ideas for a better solution to this. > > diff -r 7588156f5cf9 src/os/solaris/vm/os_solaris.cpp > --- a/src/os/solaris/vm/os_solaris.cpp Mon Sep 05 17:09:05 2011 -0700 > +++ b/src/os/solaris/vm/os_solaris.cpp Tue Sep 06 20:07:09 2011 +0000 > @@ -6425,7 +6425,7 @@ > sockaddr *from, int *fromlen) { > //%%note jvm_r11 > INTERRUPTIBLE_RETURN_INT((int)::recvfrom(fd, buf, nBytes,\ > - flags, from, fromlen), os::Solaris::clear_interrupted); > + flags, from, (unsigned*)fromlen), os::Solaris::clear_interrupted); > } > > int os::sendto(int fd, char *buf, int len, int flags, > > -- > Azeem Jiva > @javawithjiva > POSIX says it should actually be socklen_t*: http://pubs.opengroup.org/onlinepubs/7908799/xns/recvfrom.html as does both the Linux and OpenSolaris man pages. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From azeem.jiva at oracle.com Tue Sep 6 15:54:36 2011 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Tue, 06 Sep 2011 17:54:36 -0500 Subject: HotSpot build on SPARC/Solaris In-Reply-To: <20110906213214.GG19081@rivendell.middle-earth.co.uk> References: <4E6680D9.2040505@oracle.com> <20110906213214.GG19081@rivendell.middle-earth.co.uk> Message-ID: <4E66A4AC.8010108@oracle.com> I've attached a patch for review. I don't have a openjdk account yet, but I'd like someone to review the changes none the less. Thanks. On 09/06/2011 04:32 PM, Dr Andrew John Hughes wrote: > POSIX says it should actually be socklen_t*: > > http://pubs.opengroup.org/onlinepubs/7908799/xns/recvfrom.html > > as does both the Linux and OpenSolaris man pages. -------------- next part -------------- A non-text attachment was scrubbed... Name: hsx.patch Type: text/x-patch Size: 3215 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110906/01dba931/attachment.bin From David.Holmes at oracle.com Tue Sep 6 16:20:36 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 07 Sep 2011 09:20:36 +1000 Subject: Request for Review (XS): 7087445, Improve platform independence of JSR292 shared code In-Reply-To: <4E664494.3010205@oracle.com> References: <4E664494.3010205@oracle.com> Message-ID: <4E66AAC4.603@oracle.com> Looks good to me. Pity there isn't a direct way to define the default implementation and then have it "overridden" as needed per platform, rather than repeating the same definition. David On 7/09/2011 2:04 AM, Bertrand Delsart wrote: > Small shared changes necessary to improve portability of jsr292 > on some platforms. > > http://cr.openjdk.java.net/~bdelsart/7087445/webrev.00/ > > Should have no impact on the existing ports, as long as > you add this backward compatible definition (added to SPARC, > x86 and zero): > > intptr_t *frame::initial_deoptimization_info() { > return fp(); > } > > Thanks, > > Bertrand. From john.r.rose at oracle.com Tue Sep 6 16:29:45 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2011 16:29:45 -0700 Subject: Segfault toward end of hotspot-comp build In-Reply-To: References: Message-ID: <2EEE517A-CC82-4467-A8F6-8CC2C24655E0@oracle.com> On Sep 6, 2011, at 10:16 AM, Charles Oliver Nutter wrote: > Ok, looks like it was a dirty build. It worked ok after a clean. Yup. The names in globals.hpp are accessed in part via a BHE (big hairy enum). Changing the list in globals.hpp (or systemDictionary.hpp or vmSymbols.hpp) can cause *.o files to contain stale enum values. We used to have automatically-generated *.o -> *hpp dependencies in our makefiles which would cause big painful rebuilds if you updated a key header file. Now, since we went to a cpp-based solution for portability, I don't know how (or if) that stuff is tracked. It probably depends on how clever your toolchain is. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110906/93462c90/attachment.html From john.r.rose at oracle.com Tue Sep 6 16:38:05 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2011 16:38:05 -0700 Subject: Request for Review (XS): 7087445, Improve platform independence of JSR292 shared code In-Reply-To: <4E664494.3010205@oracle.com> References: <4E664494.3010205@oracle.com> Message-ID: It's a little jarring to have initial_deoptimization_info supply the initial_fp of the unroll block. I suggest s/initial_deoptimization_info/initial_fp_for_deoptimization/ to simplify the correspondence. Then platforms which supply fp() for this don't have to apologize so much, and this line looks more normal: info->set_initial_fp((intptr_t) array->sender().initial_fp_for_deoptimization()); -- John On Sep 6, 2011, at 9:04 AM, Bertrand Delsart wrote: > Small shared changes necessary to improve portability of jsr292 > on some platforms. > > http://cr.openjdk.java.net/~bdelsart/7087445/webrev.00/ > > Should have no impact on the existing ports, as long as > you add this backward compatible definition (added to SPARC, > x86 and zero): > > intptr_t *frame::initial_deoptimization_info() { > return fp(); > } > > Thanks, > > Bertrand. > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From ahughes at redhat.com Tue Sep 6 19:32:17 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 7 Sep 2011 03:32:17 +0100 Subject: HotSpot build on SPARC/Solaris In-Reply-To: <4E66A4AC.8010108@oracle.com> References: <4E6680D9.2040505@oracle.com> <20110906213214.GG19081@rivendell.middle-earth.co.uk> <4E66A4AC.8010108@oracle.com> Message-ID: <20110907023217.GH19081@rivendell.middle-earth.co.uk> On 17:54 Tue 06 Sep , Azeem Jiva wrote: > I've attached a patch for review. I don't have a openjdk account yet, > but I'd like someone to review the changes none the less. Thanks. > > On 09/06/2011 04:32 PM, Dr Andrew John Hughes wrote: > > POSIX says it should actually be socklen_t*: > > > > http://pubs.opengroup.org/onlinepubs/7908799/xns/recvfrom.html > > > > as does both the Linux and OpenSolaris man pages. It looks correct to me. Does it compile correctly on both platforms? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From bertrand.delsart at oracle.com Wed Sep 7 00:39:10 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 07 Sep 2011 09:39:10 +0200 Subject: Request for Review (XS): 7087445, Improve platform independence of JSR292 shared code In-Reply-To: References: <4E664494.3010205@oracle.com> Message-ID: <4E671F9E.4000604@oracle.com> Well, this is not an 'fp' an all platforms. In fact, what most platform might need is the unextended_sp of the initial caller frame (which just happens to be stored in FP on x86's compiled frames). Thus, if the conflict between the field name and the method bother you, I would prefer s/initial_fp/initial_info/ for the field and its accessors. I didn't do it before to minimize changes (e.g. not touch the deoptimization code that reads the field in sharedRuntime_x86_[32|64].cpp)) but the idea is really that deoptimization.cpp need not know what this data is (and should not assume it does). Another solution, ti make the platform dependency explicit, is: - s/initial_fp/pd_data/ (for platform dependent field name and accessors). - s/initial_deoptimization_info/deoptimization_pd_data/ (for the platform dependent call filling the field) Do you prefer me to make this changes which will also impact the sharedRuntime_... files ? Any preference on the naming (info|pd_data) ? Bertrand. On 09/ 7/11 01:38 AM, John Rose wrote: > It's a little jarring to have initial_deoptimization_info supply the initial_fp of the unroll block. > > I suggest s/initial_deoptimization_info/initial_fp_for_deoptimization/ to simplify the correspondence. > > Then platforms which supply fp() for this don't have to apologize so much, and this line looks more normal: > > info->set_initial_fp((intptr_t) array->sender().initial_fp_for_deoptimization()); > > > -- John > > On Sep 6, 2011, at 9:04 AM, Bertrand Delsart wrote: > >> Small shared changes necessary to improve portability of jsr292 >> on some platforms. >> >> http://cr.openjdk.java.net/~bdelsart/7087445/webrev.00/ >> >> Should have no impact on the existing ports, as long as >> you add this backward compatible definition (added to SPARC, >> x86 and zero): >> >> intptr_t *frame::initial_deoptimization_info() { >> return fp(); >> } >> >> Thanks, >> >> Bertrand. >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com, >> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From David.Holmes at oracle.com Wed Sep 7 00:57:10 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 07 Sep 2011 17:57:10 +1000 Subject: Request for Review (XS): 7087445, Improve platform independence of JSR292 shared code In-Reply-To: <4E671F9E.4000604@oracle.com> References: <4E664494.3010205@oracle.com> <4E671F9E.4000604@oracle.com> Message-ID: <4E6723D6.5020504@oracle.com> If set_initial_fp is not actually setting a fp at all then it should be renamed. My 2c. David On 7/09/2011 5:39 PM, Bertrand Delsart wrote: > Well, this is not an 'fp' an all platforms. In fact, what most platform > might need is the unextended_sp of the initial caller frame (which just > happens to be stored in FP on x86's compiled frames). > > Thus, if the conflict between the field name and the method bother you, I > would prefer s/initial_fp/initial_info/ for the field and its accessors. > > I didn't do it before to minimize changes (e.g. not touch the > deoptimization code that reads the field in sharedRuntime_x86_[32|64].cpp)) > but the idea is really that deoptimization.cpp need not know what this data > is (and should not assume it does). > > Another solution, ti make the platform dependency explicit, is: > - s/initial_fp/pd_data/ (for platform dependent field name and accessors). > - s/initial_deoptimization_info/deoptimization_pd_data/ (for the platform > dependent call filling the field) > > Do you prefer me to make this changes which will also impact the > sharedRuntime_... files ? Any preference on the naming (info|pd_data) ? > > Bertrand. > > On 09/ 7/11 01:38 AM, John Rose wrote: >> It's a little jarring to have initial_deoptimization_info supply the >> initial_fp of the unroll block. >> >> I suggest s/initial_deoptimization_info/initial_fp_for_deoptimization/ to >> simplify the correspondence. >> >> Then platforms which supply fp() for this don't have to apologize so much, >> and this line looks more normal: >> >> info->set_initial_fp((intptr_t) >> array->sender().initial_fp_for_deoptimization()); >> >> >> -- John >> >> On Sep 6, 2011, at 9:04 AM, Bertrand Delsart wrote: >> >>> Small shared changes necessary to improve portability of jsr292 >>> on some platforms. >>> >>> http://cr.openjdk.java.net/~bdelsart/7087445/webrev.00/ >>> >>> Should have no impact on the existing ports, as long as >>> you add this backward compatible definition (added to SPARC, >>> x86 and zero): >>> >>> intptr_t *frame::initial_deoptimization_info() { >>> return fp(); >>> } >>> >>> Thanks, >>> >>> Bertrand. >>> -- >>> Bertrand Delsart, bertrand.delsart at oracle.com, >>> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >>> 38334 Saint Ismier, FRANCE >> > > From john.r.rose at oracle.com Wed Sep 7 01:02:52 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Sep 2011 01:02:52 -0700 Subject: Request for Review (XS): 7087445, Improve platform independence of JSR292 shared code In-Reply-To: <4E671F9E.4000604@oracle.com> References: <4E664494.3010205@oracle.com> <4E671F9E.4000604@oracle.com> Message-ID: <1AC008C8-9D04-402A-B3E9-A28292257CC4@oracle.com> On Sep 7, 2011, at 12:39 AM, Bertrand Delsart wrote: > Do you prefer me to make this changes which will also impact the sharedRuntime_... files ? Any preference on the naming (info|pd_data) ? I agree that more consistency would be better. When we do ports, sometimes we realize that the shared code contains invalid assumptions, and it is reasonable to clean those assumptions up as we discover them. Therefore, here are my preferences in decreasing order: 1. Rename "fp" to "info" more uniformly, in both new and pre-existing code. 2. Rename new uses of "info" to "fp", accepting that the existing conventions imply that "fp" is not always a frame pointer. 3. (Least preferable:) Keep your changes as they are. Thanks! -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110907/0fc858f1/attachment.html From bertrand.delsart at oracle.com Wed Sep 7 01:12:06 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 07 Sep 2011 10:12:06 +0200 Subject: Request for Review (XS): 7087445, Improve platform independence of JSR292 shared code In-Reply-To: <1AC008C8-9D04-402A-B3E9-A28292257CC4@oracle.com> References: <4E664494.3010205@oracle.com> <4E671F9E.4000604@oracle.com> <1AC008C8-9D04-402A-B3E9-A28292257CC4@oracle.com> Message-ID: <4E672756.7080508@oracle.com> Thanks John and David, I'll update the change, consistently using 'info'. Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From roland.westrelin at oracle.com Wed Sep 7 03:07:14 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 07 Sep 2011 10:07:14 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7086394: c2/arm: enable UseFPUForSpilling Message-ID: <20110907100722.A3EDB47424@hg.openjdk.java.net> Changeset: c2d3caa64b3e Author: roland Date: 2011-09-07 09:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c2d3caa64b3e 7086394: c2/arm: enable UseFPUForSpilling Summary: ARM has instructions to move data directly between the fpu and integer registers. Reviewed-by: kvn, never ! src/share/vm/opto/matcher.cpp From christian.thalinger at oracle.com Wed Sep 7 06:37:05 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 Sep 2011 15:37:05 +0200 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Message-ID: http://cr.openjdk.java.net/~twisti/7085860/ 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: The current push notification of CallSites disallows the compilation of CallSite.setTargetNormal and setTargetVolatile to get correct behavior. It would be much easier and cleaner if these two methods were native methods in the JVM. The obsolete code will be removed after the JDK changes have landed with: 7087357: JSR 292: remove obsolete code after 7085860 src/share/vm/classfile/javaClasses.cpp src/share/vm/classfile/javaClasses.hpp src/share/vm/oops/oop.hpp src/share/vm/oops/oop.inline.hpp src/share/vm/prims/methodHandles.cpp jdk/src/share/classes/java/lang/invoke/CallSite.java jdk/src/share/classes/java/lang/invoke/MethodHandleNatives.java From christian.thalinger at oracle.com Tue Sep 6 23:46:20 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 Sep 2011 08:46:20 +0200 Subject: Fwd: HotSpot build on SPARC/Solaris References: <4E6680D9.2040505@oracle.com> Message-ID: <30B26EEF-0F3A-49C2-BFE9-0B5F686A0E7E@oracle.com> This is more a runtime issue. Forwarding to hotspot-runtime-dev and BCC'ing hotspot-compiler-dev. -- Christian Begin forwarded message: > From: Azeem Jiva > Subject: HotSpot build on SPARC/Solaris > Date: September 6, 2011 10:21:45 PM GMT+02:00 > To: hotspot-compiler-dev at openjdk.java.net > > Trying to build on SPARC/Solaris I get the following error: > > "/root/hsx/src/os/solaris/vm/os_solaris.cpp", line 6428: Error: Formal argument 6 of type unsigned* in call to recvfrom(int, void*, unsigned long, int, sockaddr*, unsigned*) is being passed int*. > "/root/hsx/src/os/solaris/vm/os_solaris.cpp", line 6428: Error: Formal argument 6 of type unsigned* in call to recvfrom(int, void*, unsigned long, int, sockaddr*, unsigned*) is being passed int*. > > It seems the method signature changed in Solaris 11 from int pointer to an unsigned pointer. I can get around the issue by casting fromlen to an unsigned pointer, but that's dangerous. I guess I'm looking for ideas for a better solution to this. > > diff -r 7588156f5cf9 src/os/solaris/vm/os_solaris.cpp > --- a/src/os/solaris/vm/os_solaris.cpp Mon Sep 05 17:09:05 2011 -0700 > +++ b/src/os/solaris/vm/os_solaris.cpp Tue Sep 06 20:07:09 2011 +0000 > @@ -6425,7 +6425,7 @@ > sockaddr *from, int *fromlen) { > //%%note jvm_r11 > INTERRUPTIBLE_RETURN_INT((int)::recvfrom(fd, buf, nBytes,\ > - flags, from, fromlen), os::Solaris::clear_interrupted); > + flags, from, (unsigned*)fromlen), os::Solaris::clear_interrupted); > } > > int os::sendto(int fd, char *buf, int len, int flags, > > -- > Azeem Jiva > @javawithjiva > From vladimir.kozlov at oracle.com Wed Sep 7 09:29:57 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 09:29:57 -0700 Subject: Request for reviews (S): 7054211: No loop unrolling done in jdk7b144 for a test update() while loop Message-ID: <4E679C05.9060903@oracle.com> http://cr.openjdk.java.net/~kvn/7054211/webrev 7054211: No loop unrolling done in jdk7b144 for a test update() while loop It is anti-delta of changes which removed code for CaffeineMark. A perf regression of approximately 13.5% was observed in benchmark with a pure java crc32 implementation which use XORs after that changes. Our refworkload benchmarks are not affected by this fix (and that is why did original changes). Thanks, Vladimir From tom.rodriguez at oracle.com Wed Sep 7 09:40:13 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 09:40:13 -0700 Subject: Request for reviews (S): 7054211: No loop unrolling done in jdk7b144 for a test update() while loop In-Reply-To: <4E679C05.9060903@oracle.com> References: <4E679C05.9060903@oracle.com> Message-ID: Looks good. tom On Sep 7, 2011, at 9:29 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7054211/webrev > > 7054211: No loop unrolling done in jdk7b144 for a test update() while loop > > It is anti-delta of changes which removed code for CaffeineMark. A perf regression of approximately 13.5% was observed in benchmark with a pure java crc32 implementation which use XORs after that changes. > > Our refworkload benchmarks are not affected by this fix (and that is why did original changes). > > Thanks, > Vladimir From tom.rodriguez at oracle.com Wed Sep 7 09:41:18 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 09:41:18 -0700 Subject: Request for reviews (S): 7054211: No loop unrolling done in jdk7b144 for a test update() while loop In-Reply-To: <4E679C05.9060903@oracle.com> References: <4E679C05.9060903@oracle.com> Message-ID: <6EC2BABC-1CEC-46B7-984E-0547AF2FB306@oracle.com> Though it might be nice to correct the comment to say that it helps crc32 and not CaffeineMark. tom On Sep 7, 2011, at 9:29 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7054211/webrev > > 7054211: No loop unrolling done in jdk7b144 for a test update() while loop > > It is anti-delta of changes which removed code for CaffeineMark. A perf regression of approximately 13.5% was observed in benchmark with a pure java crc32 implementation which use XORs after that changes. > > Our refworkload benchmarks are not affected by this fix (and that is why did original changes). > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Sep 7 09:37:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 09:37:33 -0700 Subject: Request for reviews (S): 7054211: No loop unrolling done in jdk7b144 for a test update() while loop In-Reply-To: <6EC2BABC-1CEC-46B7-984E-0547AF2FB306@oracle.com> References: <4E679C05.9060903@oracle.com> <6EC2BABC-1CEC-46B7-984E-0547AF2FB306@oracle.com> Message-ID: <4E679DCD.8090702@oracle.com> Thank you, Tom I will update comments. Vladimir Tom Rodriguez wrote: > Though it might be nice to correct the comment to say that it helps crc32 and not CaffeineMark. > > tom > > On Sep 7, 2011, at 9:29 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7054211/webrev >> >> 7054211: No loop unrolling done in jdk7b144 for a test update() while loop >> >> It is anti-delta of changes which removed code for CaffeineMark. A perf regression of approximately 13.5% was observed in benchmark with a pure java crc32 implementation which use XORs after that changes. >> >> Our refworkload benchmarks are not affected by this fix (and that is why did original changes). >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Wed Sep 7 12:52:29 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 12:52:29 -0700 Subject: Request for reviews (S): 7054211: No loop unrolling done in jdk7b144 for a test update() while loop In-Reply-To: <6EC2BABC-1CEC-46B7-984E-0547AF2FB306@oracle.com> References: <4E679C05.9060903@oracle.com> <6EC2BABC-1CEC-46B7-984E-0547AF2FB306@oracle.com> Message-ID: <4E67CB7D.3000409@oracle.com> Thank you, Tom I updated comments. Vladimir Tom Rodriguez wrote: > Though it might be nice to correct the comment to say that it helps crc32 and not CaffeineMark. > > tom > > On Sep 7, 2011, at 9:29 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7054211/webrev >> >> 7054211: No loop unrolling done in jdk7b144 for a test update() while loop >> >> It is anti-delta of changes which removed code for CaffeineMark. A perf regression of approximately 13.5% was observed in benchmark with a pure java crc32 implementation which use XORs after that changes. >> >> Our refworkload benchmarks are not affected by this fix (and that is why did original changes). >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Wed Sep 7 11:52:30 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 11:52:30 -0700 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: References: Message-ID: <07343E51-99C5-4469-8AD7-650E232F3A9E@oracle.com> On Sep 7, 2011, at 6:37 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7085860/ > > 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods > Reviewed-by: > > The current push notification of CallSites disallows the compilation > of CallSite.setTargetNormal and setTargetVolatile to get correct > behavior. It would be much easier and cleaner if these two methods > were native methods in the JVM. The JVM changes look fine, though the name obj_field_volatile_put doesn't read that well. Maybe obj_field_put_volatile? I know it matches the raw_put name but you could change that too. Anyway, it's a nit, so feel free to ignore it. In CallSite.java you can delete the other Unsafe stuff since it's no longer needed. Otherwise it looks good. tom > > The obsolete code will be removed after the JDK changes have landed > with: > > 7087357: JSR 292: remove obsolete code after 7085860 > > src/share/vm/classfile/javaClasses.cpp > src/share/vm/classfile/javaClasses.hpp > src/share/vm/oops/oop.hpp > src/share/vm/oops/oop.inline.hpp > src/share/vm/prims/methodHandles.cpp > jdk/src/share/classes/java/lang/invoke/CallSite.java > jdk/src/share/classes/java/lang/invoke/MethodHandleNatives.java > From christian.thalinger at oracle.com Wed Sep 7 12:09:27 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 Sep 2011 21:09:27 +0200 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <07343E51-99C5-4469-8AD7-650E232F3A9E@oracle.com> References: <07343E51-99C5-4469-8AD7-650E232F3A9E@oracle.com> Message-ID: <6F20BCBD-B631-4A76-84D9-84CBEDC11DAD@oracle.com> On Sep 7, 2011, at 8:52 PM, Tom Rodriguez wrote: > > On Sep 7, 2011, at 6:37 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7085860/ >> >> 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods >> Reviewed-by: >> >> The current push notification of CallSites disallows the compilation >> of CallSite.setTargetNormal and setTargetVolatile to get correct >> behavior. It would be much easier and cleaner if these two methods >> were native methods in the JVM. > > The JVM changes look fine, though the name obj_field_volatile_put doesn't read that well. Maybe obj_field_put_volatile? I know it matches the raw_put name but you could change that too. Anyway, it's a nit, so feel free to ignore it. I agree. I will change that. > > In CallSite.java you can delete the other Unsafe stuff since it's no longer needed. Otherwise it looks good. Like TARGET_OFFSET? getTargetVolatile still uses it. -- Christian > > tom > >> >> The obsolete code will be removed after the JDK changes have landed >> with: >> >> 7087357: JSR 292: remove obsolete code after 7085860 >> >> src/share/vm/classfile/javaClasses.cpp >> src/share/vm/classfile/javaClasses.hpp >> src/share/vm/oops/oop.hpp >> src/share/vm/oops/oop.inline.hpp >> src/share/vm/prims/methodHandles.cpp >> jdk/src/share/classes/java/lang/invoke/CallSite.java >> jdk/src/share/classes/java/lang/invoke/MethodHandleNatives.java >> > From john.r.rose at oracle.com Wed Sep 7 12:09:49 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Sep 2011 12:09:49 -0700 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: References: Message-ID: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> On Sep 7, 2011, at 6:37 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7085860/ > > 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods > Reviewed-by: Yes, looks good. (I agree with Tom that "volatile_put" is harder to read than "put_volatile". In the latter formulation, "volatile" modifies "put" more clearly.) Will there be a separate bug for throttling megamutable sites, after Tom's field injection stuff goes in? -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110907/80c53f85/attachment.html From tom.rodriguez at oracle.com Wed Sep 7 12:10:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 12:10:49 -0700 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <6F20BCBD-B631-4A76-84D9-84CBEDC11DAD@oracle.com> References: <07343E51-99C5-4469-8AD7-650E232F3A9E@oracle.com> <6F20BCBD-B631-4A76-84D9-84CBEDC11DAD@oracle.com> Message-ID: <2DFCA00F-A2CA-4238-820A-B4FC039C56F1@oracle.com> On Sep 7, 2011, at 12:09 PM, Christian Thalinger wrote: > > On Sep 7, 2011, at 8:52 PM, Tom Rodriguez wrote: > >> >> On Sep 7, 2011, at 6:37 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7085860/ >>> >>> 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods >>> Reviewed-by: >>> >>> The current push notification of CallSites disallows the compilation >>> of CallSite.setTargetNormal and setTargetVolatile to get correct >>> behavior. It would be much easier and cleaner if these two methods >>> were native methods in the JVM. >> >> The JVM changes look fine, though the name obj_field_volatile_put doesn't read that well. Maybe obj_field_put_volatile? I know it matches the raw_put name but you could change that too. Anyway, it's a nit, so feel free to ignore it. > > I agree. I will change that. > >> >> In CallSite.java you can delete the other Unsafe stuff since it's no longer needed. Otherwise it looks good. > > Like TARGET_OFFSET? getTargetVolatile still uses it. Right. I was thinking they both went away but they didn't. OK. tom > > -- Christian > >> >> tom >> >>> >>> The obsolete code will be removed after the JDK changes have landed >>> with: >>> >>> 7087357: JSR 292: remove obsolete code after 7085860 >>> >>> src/share/vm/classfile/javaClasses.cpp >>> src/share/vm/classfile/javaClasses.hpp >>> src/share/vm/oops/oop.hpp >>> src/share/vm/oops/oop.inline.hpp >>> src/share/vm/prims/methodHandles.cpp >>> jdk/src/share/classes/java/lang/invoke/CallSite.java >>> jdk/src/share/classes/java/lang/invoke/MethodHandleNatives.java >>> >> > From christian.thalinger at oracle.com Wed Sep 7 12:28:08 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 Sep 2011 21:28:08 +0200 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> Message-ID: <5D1CD2B8-7E2C-45D2-90C7-C8EC311FD11F@oracle.com> On Sep 7, 2011, at 9:09 PM, John Rose wrote: > On Sep 7, 2011, at 6:37 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7085860/ >> >> 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods >> Reviewed-by: > > Yes, looks good. (I agree with Tom that "volatile_put" is harder to read than "put_volatile". In the latter formulation, "volatile" modifies "put" more clearly.) > > Will there be a separate bug for throttling megamutable sites, after Tom's field injection stuff goes in? Yes. I filed: 7087838: JSR 292: add throttling logic for optimistic call site optimizations Thanks for the reviews. -- Christian > > -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110907/d5d26ed6/attachment.html From tom.rodriguez at oracle.com Wed Sep 7 14:08:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 14:08:27 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block Message-ID: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> http://cr.openjdk.java.net/~never/7088020 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg 7088020: SEGV in JNIHandleBlock::release_block Reviewed-by: The throw_WrongMethodTypeException stub on x64 needs to align the stack before calling into the runtime or it might crash. I also noticed that two stubs were dead which made an extra argument dead so I cleaned that up at the same time. Tested on linux-amd64 with new regression test and failing tests from report. From vladimir.kozlov at oracle.com Wed Sep 7 14:24:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 14:24:38 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> Message-ID: <4E67E116.3030604@oracle.com> Where r12 is restored? It contains coop base. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7088020 > 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg > > 7088020: SEGV in JNIHandleBlock::release_block > Reviewed-by: > > The throw_WrongMethodTypeException stub on x64 needs to align the > stack before calling into the runtime or it might crash. I also > noticed that two stubs were dead which made an extra argument dead so > I cleaned that up at the same time. Tested on linux-amd64 with new > regression test and failing tests from report. > From vladimir.kozlov at oracle.com Wed Sep 7 14:29:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 14:29:24 -0700 Subject: Request for reviews (S): 7087947: Add regression test for 7068051 Message-ID: <4E67E234.7080200@oracle.com> http://cr.openjdk.java.net/~kvn/7087947/webrev 7087947: Add regression test for 7068051 Thanks, Vladimir From vladimir.kozlov at oracle.com Wed Sep 7 14:56:33 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 07 Sep 2011 21:56:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7054211: No loop unrolling done in jdk7b144 for a test update() while loop Message-ID: <20110907215635.0916047452@hg.openjdk.java.net> Changeset: da6a29fb0da5 Author: kvn Date: 2011-09-07 12:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/da6a29fb0da5 7054211: No loop unrolling done in jdk7b144 for a test update() while loop Summary: restore unrolling code for CaffeineMark. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp From tom.rodriguez at oracle.com Wed Sep 7 15:44:56 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 15:44:56 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <4E67E116.3030604@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> Message-ID: On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: > Where r12 is restored? It contains coop base. I forgot to add the reinit_heapbase call. I've updated the webrev. Surprisingly my tests didn't crash. I ran some more tests and found a problem with stack walking for throw_NullPointerException_at_call. I'm looking into it. tom > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7088020 >> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >> 7088020: SEGV in JNIHandleBlock::release_block >> Reviewed-by: >> The throw_WrongMethodTypeException stub on x64 needs to align the >> stack before calling into the runtime or it might crash. I also >> noticed that two stubs were dead which made an extra argument dead so >> I cleaned that up at the same time. Tested on linux-amd64 with new >> regression test and failing tests from report. From tom.rodriguez at oracle.com Wed Sep 7 17:32:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 17:32:54 -0700 Subject: Request for reviews (S): 7087947: Add regression test for 7068051 In-Reply-To: <4E67E234.7080200@oracle.com> References: <4E67E234.7080200@oracle.com> Message-ID: Looks good. tom On Sep 7, 2011, at 2:29 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7087947/webrev > > 7087947: Add regression test for 7068051 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Sep 7 18:04:07 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 18:04:07 -0700 Subject: Request for reviews (S): 7087947: Add regression test for 7068051 In-Reply-To: References: <4E67E234.7080200@oracle.com> Message-ID: <4E681487.5020801@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 7, 2011, at 2:29 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7087947/webrev >> >> 7087947: Add regression test for 7068051 >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Wed Sep 7 20:40:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Sep 2011 20:40:19 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <4E67E116.3030604@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> Message-ID: <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. tom On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: > Where r12 is restored? It contains coop base. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7088020 >> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >> 7088020: SEGV in JNIHandleBlock::release_block >> Reviewed-by: >> The throw_WrongMethodTypeException stub on x64 needs to align the >> stack before calling into the runtime or it might crash. I also >> noticed that two stubs were dead which made an extra argument dead so >> I cleaned that up at the same time. Tested on linux-amd64 with new >> regression test and failing tests from report. From vladimir.kozlov at oracle.com Wed Sep 7 21:12:06 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 21:12:06 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> Message-ID: <4E684096.8000404@oracle.com> Looks good. Vladimir On 9/7/11 8:40 PM, Tom Rodriguez wrote: > Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. > > tom > > On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: > >> Where r12 is restored? It contains coop base. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7088020 >>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>> 7088020: SEGV in JNIHandleBlock::release_block >>> Reviewed-by: >>> The throw_WrongMethodTypeException stub on x64 needs to align the >>> stack before calling into the runtime or it might crash. I also >>> noticed that two stubs were dead which made an extra argument dead so >>> I cleaned that up at the same time. Tested on linux-amd64 with new >>> regression test and failing tests from report. > From vladimir.kozlov at oracle.com Wed Sep 7 21:35:22 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Sep 2011 21:35:22 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <4E684096.8000404@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> <4E684096.8000404@oracle.com> Message-ID: <4E68460A.7030606@oracle.com> Can we use pushptr(Address(r12, 0)) instead of using RDI in next code?: + __ mov(r12, rsp); + __ movptr(rdi, Address(rsp, 0)); // Pick up the return address + __ andptr(rsp, -StackAlignmentInBytes); // Align the stack for the ABI + __ push(rdi); Vladimir On 9/7/11 9:12 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 9/7/11 8:40 PM, Tom Rodriguez wrote: >> Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that >> I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. >> >> tom >> >> On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: >> >>> Where r12 is restored? It contains coop base. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7088020 >>>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>>> 7088020: SEGV in JNIHandleBlock::release_block >>>> Reviewed-by: >>>> The throw_WrongMethodTypeException stub on x64 needs to align the >>>> stack before calling into the runtime or it might crash. I also >>>> noticed that two stubs were dead which made an extra argument dead so >>>> I cleaned that up at the same time. Tested on linux-amd64 with new >>>> regression test and failing tests from report. >> From christian.thalinger at oracle.com Thu Sep 8 03:03:49 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Sep 2011 12:03:49 +0200 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> Message-ID: On Sep 7, 2011, at 9:09 PM, John Rose wrote: > On Sep 7, 2011, at 6:37 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7085860/ >> >> 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods >> Reviewed-by: > > Yes, looks good. (I agree with Tom that "volatile_put" is harder to read than "put_volatile". In the latter formulation, "volatile" modifies "put" more clearly.) I renamed the two methods (raw and volatile) and added the new methods to klassOop too (it looks like that is required). The webrev is updated. -- Christian > > Will there be a separate bug for throttling megamutable sites, after Tom's field injection stuff goes in? > > -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110908/88bde146/attachment.html From christian.thalinger at oracle.com Thu Sep 8 03:09:41 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Sep 2011 12:09:41 +0200 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> Message-ID: <136F14CF-1A90-465C-95F9-70F8FE515887@oracle.com> I don't understand that comment: + // FIXME: this probably needs to alignment logic -- Christian On Sep 8, 2011, at 5:40 AM, Tom Rodriguez wrote: > Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. > > tom > > On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: > >> Where r12 is restored? It contains coop base. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7088020 >>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>> 7088020: SEGV in JNIHandleBlock::release_block >>> Reviewed-by: >>> The throw_WrongMethodTypeException stub on x64 needs to align the >>> stack before calling into the runtime or it might crash. I also >>> noticed that two stubs were dead which made an extra argument dead so >>> I cleaned that up at the same time. Tested on linux-amd64 with new >>> regression test and failing tests from report. > From bertrand.delsart at oracle.com Thu Sep 8 04:39:32 2011 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Thu, 08 Sep 2011 11:39:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7087445: Improve platform independence of JSR292 shared code Message-ID: <20110908113939.A98DF47478@hg.openjdk.java.net> Changeset: 5432047c7db7 Author: bdelsart Date: 2011-09-08 10:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5432047c7db7 7087445: Improve platform independence of JSR292 shared code Summary: changes necessary for some JSR292 ports Reviewed-by: jrose, dholmes ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/frame.hpp From tom.rodriguez at oracle.com Thu Sep 8 09:03:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Sep 2011 09:03:41 -0700 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> Message-ID: <127D2E6D-2616-4BD4-AA74-F94BB781F839@oracle.com> On Sep 8, 2011, at 3:03 AM, Christian Thalinger wrote: > > On Sep 7, 2011, at 9:09 PM, John Rose wrote: > >> On Sep 7, 2011, at 6:37 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7085860/ >>> >>> 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods >>> Reviewed-by: >> >> Yes, looks good. (I agree with Tom that "volatile_put" is harder to read than "put_volatile". In the latter formulation, "volatile" modifies "put" more clearly.) > > I renamed the two methods (raw and volatile) and added the new methods to klassOop too (it looks like that is required). The webrev is updated. That looks good. One thing that occurred to me is that reading of the target field within the JVM must be done as if it were volatile, since we don't actually know what type of call site we're reading from. You could put a check in CallSite::target but I think you just always read it as volatile. I suspect the invokedynamic call site assembly also needs to do any required barriers. tom > > -- Christian > >> >> Will there be a separate bug for throttling megamutable sites, after Tom's field injection stuff goes in? >> >> -- John > From christian.thalinger at oracle.com Thu Sep 8 09:12:31 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 08 Sep 2011 16:12:31 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Message-ID: <20110908161233.3830C47485@hg.openjdk.java.net> Changeset: b0efc7ee3b31 Author: twisti Date: 2011-09-08 05:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b0efc7ee3b31 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/methodHandles.cpp From tom.rodriguez at oracle.com Thu Sep 8 09:29:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Sep 2011 09:29:02 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <136F14CF-1A90-465C-95F9-70F8FE515887@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> <136F14CF-1A90-465C-95F9-70F8FE515887@oracle.com> Message-ID: <3F8A237B-661F-4BB9-AAC1-72B46D8ED779@oracle.com> On Sep 8, 2011, at 3:09 AM, Christian Thalinger wrote: > I don't understand that comment: > > + // FIXME: this probably needs to alignment logic It's a typo in a comment John asked me to add. The unsafe handler also needs alignment but I wasn't sure how to reproduce a failure so I didn't want to touch it. To be honest my whole change make me a little nervous. The current stubs all apparently work ok which suggests they are always called from contexts that are properly aligned. The only way to do alignment is to extend the caller frame, which is really only safe in some contexts. It should always be safe to adjust SP in the method handle code calls so I think I should just do some stack alignment just before jumping to the throw_WMTE_entry. Part of the problem is that we don't have any strict alignment checks when calling into the runtime. We just happen to die because the part of the JNI code was using movdqa against rbp. Anyway, I'm going to play with this a bit more. tom > > -- Christian > > On Sep 8, 2011, at 5:40 AM, Tom Rodriguez wrote: > >> Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. >> >> tom >> >> On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: >> >>> Where r12 is restored? It contains coop base. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7088020 >>>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>>> 7088020: SEGV in JNIHandleBlock::release_block >>>> Reviewed-by: >>>> The throw_WrongMethodTypeException stub on x64 needs to align the >>>> stack before calling into the runtime or it might crash. I also >>>> noticed that two stubs were dead which made an extra argument dead so >>>> I cleaned that up at the same time. Tested on linux-amd64 with new >>>> regression test and failing tests from report. >> > From john.r.rose at oracle.com Thu Sep 8 12:39:09 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Sep 2011 12:39:09 -0700 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <127D2E6D-2616-4BD4-AA74-F94BB781F839@oracle.com> References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> <127D2E6D-2616-4BD4-AA74-F94BB781F839@oracle.com> Message-ID: <057D94D2-C037-4EF9-92E6-E399F1DCC47D@oracle.com> On Sep 8, 2011, at 9:03 AM, Tom Rodriguez wrote: > That looks good. One thing that occurred to me is that reading of the target field within the JVM must be done as if it were volatile, since we don't actually know what type of call site we're reading from. You could put a check in CallSite::target but I think you just always read it as volatile. I suspect the invokedynamic call site assembly also needs to do any required barriers. Nice catch. Maybe change "target" to "target_non_volatile", to emphasize the different uses of the target field. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110908/49ffdc95/attachment.html From headius at headius.com Thu Sep 8 13:13:03 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 8 Sep 2011 15:13:03 -0500 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> Message-ID: On Wed, Sep 7, 2011 at 2:09 PM, John Rose wrote: > Yes, looks good. ?(I agree with Tom that "volatile_put" is harder to read > than "put_volatile". ?In the latter formulation, "volatile" modifies "put" > more clearly.) "volatile put" says to me "it may or may not happen...it's volatile like that!" :) - Charlie From tom.rodriguez at oracle.com Thu Sep 8 13:38:12 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Sep 2011 13:38:12 -0700 Subject: review for 7086585: make Java field injection more flexible Message-ID: http://cr.openjdk.java.net/~never/7086585 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg 7086585: make Java field injection more flexible Reviewed-by: Classes which are special to the JVM often need fields for the VM's use. Currently the mechanism for this is adhoc or relies on the Java code declaring the needed fields. We need a mechanism for flexibly injecting needed fields. The basic idea is to built a standard mechanism for declaring injected fields and to inject them during class file parsing so that they get laid out and tracked like normal fields. This is also means that they can simply be looked up when CDS is used so we don't have to rely on hardcoding them. To do this I hide the encoding of the fields array and replaced all existing iteration with a new set of *FieldStream classes. JavaFieldStream only iterates true Java fields so the behavious of existing code is completely unchanged. The new fields use a special access flag JVM_ACC_INTERNAL to describe themselves and instead of having the name_index and signature_index refer to the constant pool they are vmSymbols::SID so they are looked up directly from the vmSymbols. All of this is hidden inside the RawFieldDescriptor class which is responsible for decoding fields from the field array. I also cleaned up the field layout code a bit. I eliminated the _ALIGNED_ AllocationType since there's no longer any difference in how we align double word types. I turned FieldAllocationCount into a real class and moved some of the layout code into it. I deleted the nonexistent MethodHandle::vmslot field. I moved ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted some dead field injection like the Reference.discovered field which has existed since 1.5, and the existing logic for java.lang.Class fields since it now uses the field injection machinery. Tested with runthese, the sajdi tests, the tmtools suite, the nsk regression, jdb, jdi, jvmti, hprof and jit subsuites along with vm/mlvm, but with and without the JDK changes that remove these fields and rely on injection to introduce them. They will be removed under 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. From john.r.rose at oracle.com Thu Sep 8 15:47:53 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Sep 2011 15:47:53 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: References: Message-ID: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7086585 > 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg > > 7086585: make Java field injection more flexible > Reviewed-by: From vladimir.kozlov at oracle.com Thu Sep 8 17:05:12 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 09 Sep 2011 00:05:12 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7087947: Add regression test for 7068051 Message-ID: <20110909000520.B7F25474A7@hg.openjdk.java.net> Changeset: fdcb1e828d53 Author: kvn Date: 2011-09-08 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fdcb1e828d53 7087947: Add regression test for 7068051 Summary: Add regression test. Reviewed-by: never + test/compiler/7068051/Test7068051.java + test/compiler/7068051/Test7068051.sh From vladimir.kozlov at oracle.com Thu Sep 8 18:56:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Sep 2011 18:56:09 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: References: Message-ID: <4E697239.3010908@oracle.com> Thank you, Tom Very nice cleanup. classFileParser.cpp: Can we use an arrays instead of switch to map type to allocation type in FieldAllocationCount::update()? Can we factor out next sequence since it is used in two places?: + RawFieldDescriptor* field = RawFieldDescriptor::from_field_array(fields(), n); + field->set_access_flags(access_flags.as_short()); + field->set_name_index(name_index); + field->set_signature_index(signature_index); + field->set_initval_index(constantvalue_index); + field->set_generic_signature_index(generic_signature_index); Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7086585 > 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg > > 7086585: make Java field injection more flexible > Reviewed-by: > > Classes which are special to the JVM often need fields for the VM's > use. Currently the mechanism for this is adhoc or relies on the Java > code declaring the needed fields. We need a mechanism for flexibly > injecting needed fields. The basic idea is to built a standard > mechanism for declaring injected fields and to inject them during > class file parsing so that they get laid out and tracked like normal > fields. This is also means that they can simply be looked up when CDS > is used so we don't have to rely on hardcoding them. To do this I > hide the encoding of the fields array and replaced all existing > iteration with a new set of *FieldStream classes. JavaFieldStream > only iterates true Java fields so the behavious of existing code is > completely unchanged. > > The new fields use a special access flag JVM_ACC_INTERNAL to describe > themselves and instead of having the name_index and signature_index > refer to the constant pool they are vmSymbols::SID so they are looked > up directly from the vmSymbols. All of this is hidden inside the > RawFieldDescriptor class which is responsible for decoding fields from > the field array. > > I also cleaned up the field layout code a bit. I eliminated the > _ALIGNED_ AllocationType since there's no longer any difference in how > we align double word types. I turned FieldAllocationCount into a real > class and moved some of the layout code into it. > > I deleted the nonexistent MethodHandle::vmslot field. I moved > ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted > some dead field injection like the Reference.discovered field which > has existed since 1.5, and the existing logic for java.lang.Class > fields since it now uses the field injection machinery. > > Tested with runthese, the sajdi tests, the tmtools suite, the nsk > regression, jdb, jdi, jvmti, hprof and jit subsuites along with > vm/mlvm, but with and without the JDK changes that remove these fields > and rely on injection to introduce them. They will be removed under > 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. > From christian.thalinger at oracle.com Fri Sep 9 02:05:36 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 9 Sep 2011 11:05:36 +0200 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: References: Message-ID: <9FE059D8-97EB-4248-941D-8A9677DE9C8C@oracle.com> On Sep 8, 2011, at 10:38 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7086585 > 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java: 1120 // TypeArray klfields = kls.getFields(); You want to keep this line? Otherwise this looks good. > > 7086585: make Java field injection more flexible > Reviewed-by: > > Classes which are special to the JVM often need fields for the VM's > use. Currently the mechanism for this is adhoc or relies on the Java > code declaring the needed fields. We need a mechanism for flexibly > injecting needed fields. The basic idea is to built a standard > mechanism for declaring injected fields and to inject them during > class file parsing so that they get laid out and tracked like normal > fields. This is also means that they can simply be looked up when CDS > is used so we don't have to rely on hardcoding them. To do this I > hide the encoding of the fields array and replaced all existing > iteration with a new set of *FieldStream classes. JavaFieldStream > only iterates true Java fields so the behavious of existing code is > completely unchanged. > > The new fields use a special access flag JVM_ACC_INTERNAL to describe > themselves and instead of having the name_index and signature_index > refer to the constant pool they are vmSymbols::SID so they are looked > up directly from the vmSymbols. All of this is hidden inside the > RawFieldDescriptor class which is responsible for decoding fields from > the field array. > > I also cleaned up the field layout code a bit. I eliminated the > _ALIGNED_ AllocationType since there's no longer any difference in how > we align double word types. I turned FieldAllocationCount into a real > class and moved some of the layout code into it. > > I deleted the nonexistent MethodHandle::vmslot field. I moved > ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted > some dead field injection like the Reference.discovered field which > has existed since 1.5, and the existing logic for java.lang.Class > fields since it now uses the field injection machinery. > > Tested with runthese, the sajdi tests, the tmtools suite, the nsk > regression, jdb, jdi, jvmti, hprof and jit subsuites along with > vm/mlvm, but with and without the JDK changes that remove these fields > and rely on injection to introduce them. They will be removed under > 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. > That looks good too. -- Christian From roland.westrelin at oracle.com Fri Sep 9 03:31:27 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Fri, 09 Sep 2011 10:31:27 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs Message-ID: <20110909103133.60DBB474D4@hg.openjdk.java.net> Changeset: 8f47d8870d9a Author: roland Date: 2011-09-08 09:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f47d8870d9a 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs Summary: PhaseChaitin::yank_if_dead() should be able to handle MachTemp inputs as a special case and yank them. Reviewed-by: never, kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp From tom.rodriguez at oracle.com Fri Sep 9 09:28:09 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 09:28:09 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <9FE059D8-97EB-4248-941D-8A9677DE9C8C@oracle.com> References: <9FE059D8-97EB-4248-941D-8A9677DE9C8C@oracle.com> Message-ID: <1EEDC07B-996C-4F65-8C6F-8FA5CB682978@oracle.com> On Sep 9, 2011, at 2:05 AM, Christian Thalinger wrote: > > On Sep 8, 2011, at 10:38 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7086585 >> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg > > agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java: > > 1120 // TypeArray klfields = kls.getFields(); > > You want to keep this line? Nope. I deleted it. > > Otherwise this looks good. Thanks! tom > >> >> 7086585: make Java field injection more flexible >> Reviewed-by: >> >> Classes which are special to the JVM often need fields for the VM's >> use. Currently the mechanism for this is adhoc or relies on the Java >> code declaring the needed fields. We need a mechanism for flexibly >> injecting needed fields. The basic idea is to built a standard >> mechanism for declaring injected fields and to inject them during >> class file parsing so that they get laid out and tracked like normal >> fields. This is also means that they can simply be looked up when CDS >> is used so we don't have to rely on hardcoding them. To do this I >> hide the encoding of the fields array and replaced all existing >> iteration with a new set of *FieldStream classes. JavaFieldStream >> only iterates true Java fields so the behavious of existing code is >> completely unchanged. >> >> The new fields use a special access flag JVM_ACC_INTERNAL to describe >> themselves and instead of having the name_index and signature_index >> refer to the constant pool they are vmSymbols::SID so they are looked >> up directly from the vmSymbols. All of this is hidden inside the >> RawFieldDescriptor class which is responsible for decoding fields from >> the field array. >> >> I also cleaned up the field layout code a bit. I eliminated the >> _ALIGNED_ AllocationType since there's no longer any difference in how >> we align double word types. I turned FieldAllocationCount into a real >> class and moved some of the layout code into it. >> >> I deleted the nonexistent MethodHandle::vmslot field. I moved >> ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted >> some dead field injection like the Reference.discovered field which >> has existed since 1.5, and the existing logic for java.lang.Class >> fields since it now uses the field injection machinery. >> >> Tested with runthese, the sajdi tests, the tmtools suite, the nsk >> regression, jdb, jdi, jvmti, hprof and jit subsuites along with >> vm/mlvm, but with and without the JDK changes that remove these fields >> and rely on injection to introduce them. They will be removed under >> 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. >> > > That looks good too. > > -- Christian From tom.rodriguez at oracle.com Fri Sep 9 09:31:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 09:31:28 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <4E697239.3010908@oracle.com> References: <4E697239.3010908@oracle.com> Message-ID: <3B2B8A72-0DF5-4E83-A1D4-3485EC1BB4F2@oracle.com> On Sep 8, 2011, at 6:56 PM, Vladimir Kozlov wrote: > Thank you, Tom > > Very nice cleanup. Thanks. I think there's another possible round of this to simplify the field layout and javaClasses some more but I didn't want to tangle it up with the injection changes. > > classFileParser.cpp: > > Can we use an arrays instead of switch to map type to allocation type in FieldAllocationCount::update()? I considered doing that. I'll go ahead and add it. > > Can we factor out next sequence since it is used in two places?: > > + RawFieldDescriptor* field = RawFieldDescriptor::from_field_array(fields(), n); > + field->set_access_flags(access_flags.as_short()); > + field->set_name_index(name_index); > + field->set_signature_index(signature_index); > + field->set_initval_index(constantvalue_index); > + field->set_generic_signature_index(generic_signature_index); I'm not sure how to factor that in a way that would improve it much. Any suggestions? tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7086585 >> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >> 7086585: make Java field injection more flexible >> Reviewed-by: >> Classes which are special to the JVM often need fields for the VM's >> use. Currently the mechanism for this is adhoc or relies on the Java >> code declaring the needed fields. We need a mechanism for flexibly >> injecting needed fields. The basic idea is to built a standard >> mechanism for declaring injected fields and to inject them during >> class file parsing so that they get laid out and tracked like normal >> fields. This is also means that they can simply be looked up when CDS >> is used so we don't have to rely on hardcoding them. To do this I >> hide the encoding of the fields array and replaced all existing >> iteration with a new set of *FieldStream classes. JavaFieldStream >> only iterates true Java fields so the behavious of existing code is >> completely unchanged. >> The new fields use a special access flag JVM_ACC_INTERNAL to describe >> themselves and instead of having the name_index and signature_index >> refer to the constant pool they are vmSymbols::SID so they are looked >> up directly from the vmSymbols. All of this is hidden inside the >> RawFieldDescriptor class which is responsible for decoding fields from >> the field array. >> I also cleaned up the field layout code a bit. I eliminated the >> _ALIGNED_ AllocationType since there's no longer any difference in how >> we align double word types. I turned FieldAllocationCount into a real >> class and moved some of the layout code into it. >> I deleted the nonexistent MethodHandle::vmslot field. I moved >> ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted >> some dead field injection like the Reference.discovered field which >> has existed since 1.5, and the existing logic for java.lang.Class >> fields since it now uses the field injection machinery. >> Tested with runthese, the sajdi tests, the tmtools suite, the nsk >> regression, jdb, jdi, jvmti, hprof and jit subsuites along with >> vm/mlvm, but with and without the JDK changes that remove these fields >> and rely on injection to introduce them. They will be removed under >> 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. From tom.rodriguez at oracle.com Fri Sep 9 09:45:14 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 09:45:14 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> Message-ID: <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. tom On Sep 8, 2011, at 3:47 PM, John Rose wrote: > I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John > > On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7086585 >> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >> >> 7086585: make Java field injection more flexible >> Reviewed-by: > From vladimir.kozlov at oracle.com Fri Sep 9 09:54:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 09:54:24 -0700 Subject: Request for reviews (S): 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 Message-ID: <4E6A44C0.9080108@oracle.com> http://cr.openjdk.java.net/~kvn/7035946/webrev 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 It is almost exact anti-delta of my changes in 7008866. I kept replace_parallel_iv() as separate method and added new TraceLoopOpts output. I traced down the most of regression to my changes for "replace parallel induction variables" optimization in 7008866 fix. I replaced new nodes IGVN registration with immediate Ideal transformation. As result Split_If optimization reversed it back by doing spit through Phi and it prevents loop predicates (which follow Split_If) execute RCE. If local transformation in replace_parallel_iv() is not executed the created new code matches RCE shape: iv*ratio+(init2-init*ratio) where (init2-init*ratio) is loop invariant. And Split_If optimization does not execute spit through Phi for AddI nodes in Counted loops. Yes, a lot of hidden dependences. An other part of regression came from always creation of new loop iteration Phi node. I was not able to find why it has regression affect. I returned code back to keep original Phi. I do not see affect on refworkload benchmark after this fix. Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Sep 9 10:06:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 10:06:21 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <3B2B8A72-0DF5-4E83-A1D4-3485EC1BB4F2@oracle.com> References: <4E697239.3010908@oracle.com> <3B2B8A72-0DF5-4E83-A1D4-3485EC1BB4F2@oracle.com> Message-ID: <4E6A478D.7040707@oracle.com> > I'm not sure how to factor that in a way that would improve it much. Any suggestions? I mostly worry if later we try to do the same initialization in an other place we will forgot to update some values. So it would be nice to do it by just calling one method: RawFieldDescriptor::init(u2 access_flags, u2 name_index, u2 signature_index, u2 initval_index, u2 generic_signature_index, u4 offset) { _shorts[access_flags_offset] = access_flags; _shorts[name_index_offset] = name_index; _shorts[signature_index_offset] = signature_index; _shorts[initval_index_offset] = initval_index; _shorts[generic_signature_offset] = generic_signature_index; set_offset(offset); } Vladimir Tom Rodriguez wrote: > On Sep 8, 2011, at 6:56 PM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Very nice cleanup. > > Thanks. I think there's another possible round of this to simplify the field layout and javaClasses some more but I didn't want to tangle it up with the injection changes. > >> classFileParser.cpp: >> >> Can we use an arrays instead of switch to map type to allocation type in FieldAllocationCount::update()? > > I considered doing that. I'll go ahead and add it. > >> Can we factor out next sequence since it is used in two places?: >> >> + RawFieldDescriptor* field = RawFieldDescriptor::from_field_array(fields(), n); >> + field->set_access_flags(access_flags.as_short()); >> + field->set_name_index(name_index); >> + field->set_signature_index(signature_index); >> + field->set_initval_index(constantvalue_index); >> + field->set_generic_signature_index(generic_signature_index); > > I'm not sure how to factor that in a way that would improve it much. Any suggestions? > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7086585 >>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>> 7086585: make Java field injection more flexible >>> Reviewed-by: >>> Classes which are special to the JVM often need fields for the VM's >>> use. Currently the mechanism for this is adhoc or relies on the Java >>> code declaring the needed fields. We need a mechanism for flexibly >>> injecting needed fields. The basic idea is to built a standard >>> mechanism for declaring injected fields and to inject them during >>> class file parsing so that they get laid out and tracked like normal >>> fields. This is also means that they can simply be looked up when CDS >>> is used so we don't have to rely on hardcoding them. To do this I >>> hide the encoding of the fields array and replaced all existing >>> iteration with a new set of *FieldStream classes. JavaFieldStream >>> only iterates true Java fields so the behavious of existing code is >>> completely unchanged. >>> The new fields use a special access flag JVM_ACC_INTERNAL to describe >>> themselves and instead of having the name_index and signature_index >>> refer to the constant pool they are vmSymbols::SID so they are looked >>> up directly from the vmSymbols. All of this is hidden inside the >>> RawFieldDescriptor class which is responsible for decoding fields from >>> the field array. >>> I also cleaned up the field layout code a bit. I eliminated the >>> _ALIGNED_ AllocationType since there's no longer any difference in how >>> we align double word types. I turned FieldAllocationCount into a real >>> class and moved some of the layout code into it. >>> I deleted the nonexistent MethodHandle::vmslot field. I moved >>> ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted >>> some dead field injection like the Reference.discovered field which >>> has existed since 1.5, and the existing logic for java.lang.Class >>> fields since it now uses the field injection machinery. >>> Tested with runthese, the sajdi tests, the tmtools suite, the nsk >>> regression, jdb, jdi, jvmti, hprof and jit subsuites along with >>> vm/mlvm, but with and without the JDK changes that remove these fields >>> and rely on injection to introduce them. They will be removed under >>> 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. > From vladimir.kozlov at oracle.com Fri Sep 9 10:21:06 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 10:21:06 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> Message-ID: <4E6A4B02.7040407@oracle.com> Can we just have one class FieldDescriptor. Methods and fields are almost the same. Vladimir Tom Rodriguez wrote: > I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. > > tom > > On Sep 8, 2011, at 3:47 PM, John Rose wrote: > >> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John >> >> On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: >> >>> http://cr.openjdk.java.net/~never/7086585 >>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>> >>> 7086585: make Java field injection more flexible >>> Reviewed-by: > From tom.rodriguez at oracle.com Fri Sep 9 10:26:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 10:26:38 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <4E6A4B02.7040407@oracle.com> References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> <4E6A4B02.7040407@oracle.com> Message-ID: <239AEC15-C70A-400D-8670-CA164E4736A6@oracle.com> On Sep 9, 2011, at 10:21 AM, Vladimir Kozlov wrote: > Can we just have one class FieldDescriptor. Methods and fields are almost the same. They serve different functions. RawFieldDescriptor hides and describes the layout of the fields array itself. fieldDescriptor serves as a self contained object for talking about a field. Think of it as a field handle. So they have to be separate types but they could be more closely related. Much of fieldDescriptor could be replaced by subclassing RawFieldDescriptor. tom > > Vladimir > > Tom Rodriguez wrote: >> I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. >> tom >> On Sep 8, 2011, at 3:47 PM, John Rose wrote: >>> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John >>> >>> On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: >>> >>>> http://cr.openjdk.java.net/~never/7086585 >>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>> >>>> 7086585: make Java field injection more flexible >>>> Reviewed-by: From tom.rodriguez at oracle.com Fri Sep 9 10:32:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 10:32:29 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <4E6A478D.7040707@oracle.com> References: <4E697239.3010908@oracle.com> <3B2B8A72-0DF5-4E83-A1D4-3485EC1BB4F2@oracle.com> <4E6A478D.7040707@oracle.com> Message-ID: <13A575A6-4C4A-4321-9335-8317555AD4F4@oracle.com> On Sep 9, 2011, at 10:06 AM, Vladimir Kozlov wrote: > > I'm not sure how to factor that in a way that would improve it much. Any suggestions? > > I mostly worry if later we try to do the same initialization in an other place we will forgot to update some values. So it would be nice to do it by just calling one method: Good point. I dropped the offset argument since that is always filled in later. void initialize(u2 access_flags, u2 name_index, u2 signature_index, u2 initval_index, u2 generic_signature_index) { _shorts[access_flags_offset] = access_flags; _shorts[name_index_offset] = name_index; _shorts[signature_index_offset] = signature_index; _shorts[initval_index_offset] = initval_index; _shorts[generic_signature_offset] = generic_signature_index; set_offset(0); // The offset gets filled in later } tom > > RawFieldDescriptor::init(u2 access_flags, > u2 name_index, > u2 signature_index, > u2 initval_index, > u2 generic_signature_index, > u4 offset) { > _shorts[access_flags_offset] = access_flags; > _shorts[name_index_offset] = name_index; > _shorts[signature_index_offset] = signature_index; > _shorts[initval_index_offset] = initval_index; > _shorts[generic_signature_offset] = generic_signature_index; > set_offset(offset); > } > > Vladimir > > Tom Rodriguez wrote: >> On Sep 8, 2011, at 6:56 PM, Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> Very nice cleanup. >> Thanks. I think there's another possible round of this to simplify the field layout and javaClasses some more but I didn't want to tangle it up with the injection changes. >>> classFileParser.cpp: >>> >>> Can we use an arrays instead of switch to map type to allocation type in FieldAllocationCount::update()? >> I considered doing that. I'll go ahead and add it. >>> Can we factor out next sequence since it is used in two places?: >>> >>> + RawFieldDescriptor* field = RawFieldDescriptor::from_field_array(fields(), n); >>> + field->set_access_flags(access_flags.as_short()); >>> + field->set_name_index(name_index); >>> + field->set_signature_index(signature_index); >>> + field->set_initval_index(constantvalue_index); >>> + field->set_generic_signature_index(generic_signature_index); >> I'm not sure how to factor that in a way that would improve it much. Any suggestions? >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7086585 >>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>> 7086585: make Java field injection more flexible >>>> Reviewed-by: >>>> Classes which are special to the JVM often need fields for the VM's >>>> use. Currently the mechanism for this is adhoc or relies on the Java >>>> code declaring the needed fields. We need a mechanism for flexibly >>>> injecting needed fields. The basic idea is to built a standard >>>> mechanism for declaring injected fields and to inject them during >>>> class file parsing so that they get laid out and tracked like normal >>>> fields. This is also means that they can simply be looked up when CDS >>>> is used so we don't have to rely on hardcoding them. To do this I >>>> hide the encoding of the fields array and replaced all existing >>>> iteration with a new set of *FieldStream classes. JavaFieldStream >>>> only iterates true Java fields so the behavious of existing code is >>>> completely unchanged. >>>> The new fields use a special access flag JVM_ACC_INTERNAL to describe >>>> themselves and instead of having the name_index and signature_index >>>> refer to the constant pool they are vmSymbols::SID so they are looked >>>> up directly from the vmSymbols. All of this is hidden inside the >>>> RawFieldDescriptor class which is responsible for decoding fields from >>>> the field array. >>>> I also cleaned up the field layout code a bit. I eliminated the >>>> _ALIGNED_ AllocationType since there's no longer any difference in how >>>> we align double word types. I turned FieldAllocationCount into a real >>>> class and moved some of the layout code into it. >>>> I deleted the nonexistent MethodHandle::vmslot field. I moved >>>> ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted >>>> some dead field injection like the Reference.discovered field which >>>> has existed since 1.5, and the existing logic for java.lang.Class >>>> fields since it now uses the field injection machinery. >>>> Tested with runthese, the sajdi tests, the tmtools suite, the nsk >>>> regression, jdb, jdi, jvmti, hprof and jit subsuites along with >>>> vm/mlvm, but with and without the JDK changes that remove these fields >>>> and rely on injection to introduce them. They will be removed under >>>> 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. From vladimir.kozlov at oracle.com Fri Sep 9 10:39:56 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 10:39:56 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <13A575A6-4C4A-4321-9335-8317555AD4F4@oracle.com> References: <4E697239.3010908@oracle.com> <3B2B8A72-0DF5-4E83-A1D4-3485EC1BB4F2@oracle.com> <4E6A478D.7040707@oracle.com> <13A575A6-4C4A-4321-9335-8317555AD4F4@oracle.com> Message-ID: <4E6A4F6C.8060508@oracle.com> I don't see why you can't calculate offset before calling initialize(). Vladimir Tom Rodriguez wrote: > On Sep 9, 2011, at 10:06 AM, Vladimir Kozlov wrote: > >>> I'm not sure how to factor that in a way that would improve it much. Any suggestions? >> I mostly worry if later we try to do the same initialization in an other place we will forgot to update some values. So it would be nice to do it by just calling one method: > > Good point. I dropped the offset argument since that is always filled in later. > > void initialize(u2 access_flags, > u2 name_index, > u2 signature_index, > u2 initval_index, > u2 generic_signature_index) { > _shorts[access_flags_offset] = access_flags; > _shorts[name_index_offset] = name_index; > _shorts[signature_index_offset] = signature_index; > _shorts[initval_index_offset] = initval_index; > _shorts[generic_signature_offset] = generic_signature_index; > set_offset(0); // The offset gets filled in later > } > > tom > >> RawFieldDescriptor::init(u2 access_flags, >> u2 name_index, >> u2 signature_index, >> u2 initval_index, >> u2 generic_signature_index, >> u4 offset) { >> _shorts[access_flags_offset] = access_flags; >> _shorts[name_index_offset] = name_index; >> _shorts[signature_index_offset] = signature_index; >> _shorts[initval_index_offset] = initval_index; >> _shorts[generic_signature_offset] = generic_signature_index; >> set_offset(offset); >> } >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Sep 8, 2011, at 6:56 PM, Vladimir Kozlov wrote: >>>> Thank you, Tom >>>> >>>> Very nice cleanup. >>> Thanks. I think there's another possible round of this to simplify the field layout and javaClasses some more but I didn't want to tangle it up with the injection changes. >>>> classFileParser.cpp: >>>> >>>> Can we use an arrays instead of switch to map type to allocation type in FieldAllocationCount::update()? >>> I considered doing that. I'll go ahead and add it. >>>> Can we factor out next sequence since it is used in two places?: >>>> >>>> + RawFieldDescriptor* field = RawFieldDescriptor::from_field_array(fields(), n); >>>> + field->set_access_flags(access_flags.as_short()); >>>> + field->set_name_index(name_index); >>>> + field->set_signature_index(signature_index); >>>> + field->set_initval_index(constantvalue_index); >>>> + field->set_generic_signature_index(generic_signature_index); >>> I'm not sure how to factor that in a way that would improve it much. Any suggestions? >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7086585 >>>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>>> 7086585: make Java field injection more flexible >>>>> Reviewed-by: >>>>> Classes which are special to the JVM often need fields for the VM's >>>>> use. Currently the mechanism for this is adhoc or relies on the Java >>>>> code declaring the needed fields. We need a mechanism for flexibly >>>>> injecting needed fields. The basic idea is to built a standard >>>>> mechanism for declaring injected fields and to inject them during >>>>> class file parsing so that they get laid out and tracked like normal >>>>> fields. This is also means that they can simply be looked up when CDS >>>>> is used so we don't have to rely on hardcoding them. To do this I >>>>> hide the encoding of the fields array and replaced all existing >>>>> iteration with a new set of *FieldStream classes. JavaFieldStream >>>>> only iterates true Java fields so the behavious of existing code is >>>>> completely unchanged. >>>>> The new fields use a special access flag JVM_ACC_INTERNAL to describe >>>>> themselves and instead of having the name_index and signature_index >>>>> refer to the constant pool they are vmSymbols::SID so they are looked >>>>> up directly from the vmSymbols. All of this is hidden inside the >>>>> RawFieldDescriptor class which is responsible for decoding fields from >>>>> the field array. >>>>> I also cleaned up the field layout code a bit. I eliminated the >>>>> _ALIGNED_ AllocationType since there's no longer any difference in how >>>>> we align double word types. I turned FieldAllocationCount into a real >>>>> class and moved some of the layout code into it. >>>>> I deleted the nonexistent MethodHandle::vmslot field. I moved >>>>> ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted >>>>> some dead field injection like the Reference.discovered field which >>>>> has existed since 1.5, and the existing logic for java.lang.Class >>>>> fields since it now uses the field injection machinery. >>>>> Tested with runthese, the sajdi tests, the tmtools suite, the nsk >>>>> regression, jdb, jdi, jvmti, hprof and jit subsuites along with >>>>> vm/mlvm, but with and without the JDK changes that remove these fields >>>>> and rely on injection to introduce them. They will be removed under >>>>> 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. > From tom.rodriguez at oracle.com Fri Sep 9 10:41:40 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 10:41:40 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <4E6A4F6C.8060508@oracle.com> References: <4E697239.3010908@oracle.com> <3B2B8A72-0DF5-4E83-A1D4-3485EC1BB4F2@oracle.com> <4E6A478D.7040707@oracle.com> <13A575A6-4C4A-4321-9335-8317555AD4F4@oracle.com> <4E6A4F6C.8060508@oracle.com> Message-ID: On Sep 9, 2011, at 10:39 AM, Vladimir Kozlov wrote: > I don't see why you can't calculate offset before calling initialize(). We certainly don't right now so it just seemed silly to require passing 0. I can pass it explicitly if you want. tom > > Vladimir > > Tom Rodriguez wrote: >> On Sep 9, 2011, at 10:06 AM, Vladimir Kozlov wrote: >>>> I'm not sure how to factor that in a way that would improve it much. Any suggestions? >>> I mostly worry if later we try to do the same initialization in an other place we will forgot to update some values. So it would be nice to do it by just calling one method: >> Good point. I dropped the offset argument since that is always filled in later. >> void initialize(u2 access_flags, >> u2 name_index, >> u2 signature_index, >> u2 initval_index, >> u2 generic_signature_index) { >> _shorts[access_flags_offset] = access_flags; >> _shorts[name_index_offset] = name_index; >> _shorts[signature_index_offset] = signature_index; >> _shorts[initval_index_offset] = initval_index; >> _shorts[generic_signature_offset] = generic_signature_index; >> set_offset(0); // The offset gets filled in later } >> tom >>> RawFieldDescriptor::init(u2 access_flags, >>> u2 name_index, >>> u2 signature_index, >>> u2 initval_index, >>> u2 generic_signature_index, >>> u4 offset) { >>> _shorts[access_flags_offset] = access_flags; >>> _shorts[name_index_offset] = name_index; >>> _shorts[signature_index_offset] = signature_index; >>> _shorts[initval_index_offset] = initval_index; >>> _shorts[generic_signature_offset] = generic_signature_index; >>> set_offset(offset); >>> } >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> On Sep 8, 2011, at 6:56 PM, Vladimir Kozlov wrote: >>>>> Thank you, Tom >>>>> >>>>> Very nice cleanup. >>>> Thanks. I think there's another possible round of this to simplify the field layout and javaClasses some more but I didn't want to tangle it up with the injection changes. >>>>> classFileParser.cpp: >>>>> >>>>> Can we use an arrays instead of switch to map type to allocation type in FieldAllocationCount::update()? >>>> I considered doing that. I'll go ahead and add it. >>>>> Can we factor out next sequence since it is used in two places?: >>>>> >>>>> + RawFieldDescriptor* field = RawFieldDescriptor::from_field_array(fields(), n); >>>>> + field->set_access_flags(access_flags.as_short()); >>>>> + field->set_name_index(name_index); >>>>> + field->set_signature_index(signature_index); >>>>> + field->set_initval_index(constantvalue_index); >>>>> + field->set_generic_signature_index(generic_signature_index); >>>> I'm not sure how to factor that in a way that would improve it much. Any suggestions? >>>> tom >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/7086585 >>>>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>>>> 7086585: make Java field injection more flexible >>>>>> Reviewed-by: >>>>>> Classes which are special to the JVM often need fields for the VM's >>>>>> use. Currently the mechanism for this is adhoc or relies on the Java >>>>>> code declaring the needed fields. We need a mechanism for flexibly >>>>>> injecting needed fields. The basic idea is to built a standard >>>>>> mechanism for declaring injected fields and to inject them during >>>>>> class file parsing so that they get laid out and tracked like normal >>>>>> fields. This is also means that they can simply be looked up when CDS >>>>>> is used so we don't have to rely on hardcoding them. To do this I >>>>>> hide the encoding of the fields array and replaced all existing >>>>>> iteration with a new set of *FieldStream classes. JavaFieldStream >>>>>> only iterates true Java fields so the behavious of existing code is >>>>>> completely unchanged. >>>>>> The new fields use a special access flag JVM_ACC_INTERNAL to describe >>>>>> themselves and instead of having the name_index and signature_index >>>>>> refer to the constant pool they are vmSymbols::SID so they are looked >>>>>> up directly from the vmSymbols. All of this is hidden inside the >>>>>> RawFieldDescriptor class which is responsible for decoding fields from >>>>>> the field array. >>>>>> I also cleaned up the field layout code a bit. I eliminated the >>>>>> _ALIGNED_ AllocationType since there's no longer any difference in how >>>>>> we align double word types. I turned FieldAllocationCount into a real >>>>>> class and moved some of the layout code into it. >>>>>> I deleted the nonexistent MethodHandle::vmslot field. I moved >>>>>> ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted >>>>>> some dead field injection like the Reference.discovered field which >>>>>> has existed since 1.5, and the existing logic for java.lang.Class >>>>>> fields since it now uses the field injection machinery. >>>>>> Tested with runthese, the sajdi tests, the tmtools suite, the nsk >>>>>> regression, jdb, jdi, jvmti, hprof and jit subsuites along with >>>>>> vm/mlvm, but with and without the JDK changes that remove these fields >>>>>> and rely on injection to introduce them. They will be removed under >>>>>> 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481. From tom.rodriguez at oracle.com Fri Sep 9 10:45:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 10:45:54 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <3F8A237B-661F-4BB9-AAC1-72B46D8ED779@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> <136F14CF-1A90-465C-95F9-70F8FE515887@oracle.com> <3F8A237B-661F-4BB9-AAC1-72B46D8ED779@oracle.com> Message-ID: So I've backed off from changing generate_exception_throw to perform the alignment. Given that we've seen no problems with alignment in the existing callees I have to assume they are already being called properly aligned. So instead I've added alignment code in code that throws it. I'll file a separate bug for the general issue that we should have more explicitly code for checking the alignment of calls into the runtime on x64. I've updated the webrev. I kept the stubgenerator deletions since they seemed like a good thing. tom On Sep 8, 2011, at 9:29 AM, Tom Rodriguez wrote: > > On Sep 8, 2011, at 3:09 AM, Christian Thalinger wrote: > >> I don't understand that comment: >> >> + // FIXME: this probably needs to alignment logic > > It's a typo in a comment John asked me to add. The unsafe handler also needs alignment but I wasn't sure how to reproduce a failure so I didn't want to touch it. > > To be honest my whole change make me a little nervous. The current stubs all apparently work ok which suggests they are always called from contexts that are properly aligned. The only way to do alignment is to extend the caller frame, which is really only safe in some contexts. It should always be safe to adjust SP in the method handle code calls so I think I should just do some stack alignment just before jumping to the throw_WMTE_entry. Part of the problem is that we don't have any strict alignment checks when calling into the runtime. We just happen to die because the part of the JNI code was using movdqa against rbp. Anyway, I'm going to play with this a bit more. > > tom > >> >> -- Christian >> >> On Sep 8, 2011, at 5:40 AM, Tom Rodriguez wrote: >> >>> Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. >>> >>> tom >>> >>> On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: >>> >>>> Where r12 is restored? It contains coop base. >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7088020 >>>>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>>>> 7088020: SEGV in JNIHandleBlock::release_block >>>>> Reviewed-by: >>>>> The throw_WrongMethodTypeException stub on x64 needs to align the >>>>> stack before calling into the runtime or it might crash. I also >>>>> noticed that two stubs were dead which made an extra argument dead so >>>>> I cleaned that up at the same time. Tested on linux-amd64 with new >>>>> regression test and failing tests from report. >>> >> > From vladimir.kozlov at oracle.com Fri Sep 9 11:15:29 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 11:15:29 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <239AEC15-C70A-400D-8670-CA164E4736A6@oracle.com> References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> <4E6A4B02.7040407@oracle.com> <239AEC15-C70A-400D-8670-CA164E4736A6@oracle.com> Message-ID: <4E6A57C1.2080503@oracle.com> OK. FieldInfo, FieldDesc, FieldLayoutDesc? Vladimir Tom Rodriguez wrote: > On Sep 9, 2011, at 10:21 AM, Vladimir Kozlov wrote: > >> Can we just have one class FieldDescriptor. Methods and fields are almost the same. > > They serve different functions. RawFieldDescriptor hides and describes the layout of the fields array itself. fieldDescriptor serves as a self contained object for talking about a field. Think of it as a field handle. So they have to be separate types but they could be more closely related. Much of fieldDescriptor could be replaced by subclassing RawFieldDescriptor. > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. >>> tom >>> On Sep 8, 2011, at 3:47 PM, John Rose wrote: >>>> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John >>>> >>>> On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: >>>> >>>>> http://cr.openjdk.java.net/~never/7086585 >>>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>>> >>>>> 7086585: make Java field injection more flexible >>>>> Reviewed-by: > From tom.rodriguez at oracle.com Fri Sep 9 11:25:06 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 11:25:06 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <4E6A57C1.2080503@oracle.com> References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> <4E6A4B02.7040407@oracle.com> <239AEC15-C70A-400D-8670-CA164E4736A6@oracle.com> <4E6A57C1.2080503@oracle.com> Message-ID: FieldInfo sounds pretty good to me. I reworked fieldDescriptor to use the RawFieldDescriptor by reference similarly to the other classes and I think that helps. I'm going to rename RawFieldDescriptor to FieldInfo and move it to its own file but I've updated the webrev with all the changes we've talked about so far. Here's the summary. added RawFieldDescriptor::initialize use an array to produce the FieldAllocationType renamed RawFieldStream to FieldStreamBase and updated the comment for it. eliminated the extra SystemDictionary aliases and simply fixed the few places that need to change their names. tom On Sep 9, 2011, at 11:15 AM, Vladimir Kozlov wrote: > OK. FieldInfo, FieldDesc, FieldLayoutDesc? > > Vladimir > > Tom Rodriguez wrote: >> On Sep 9, 2011, at 10:21 AM, Vladimir Kozlov wrote: >>> Can we just have one class FieldDescriptor. Methods and fields are almost the same. >> They serve different functions. RawFieldDescriptor hides and describes the layout of the fields array itself. fieldDescriptor serves as a self contained object for talking about a field. Think of it as a field handle. So they have to be separate types but they could be more closely related. Much of fieldDescriptor could be replaced by subclassing RawFieldDescriptor. >> tom >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. >>>> tom >>>> On Sep 8, 2011, at 3:47 PM, John Rose wrote: >>>>> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John >>>>> >>>>> On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~never/7086585 >>>>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>>>> >>>>>> 7086585: make Java field injection more flexible >>>>>> Reviewed-by: From vladimir.kozlov at oracle.com Fri Sep 9 11:28:41 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 11:28:41 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> <136F14CF-1A90-465C-95F9-70F8FE515887@oracle.com> <3F8A237B-661F-4BB9-AAC1-72B46D8ED779@oracle.com> Message-ID: <4E6A5AD9.6090205@oracle.com> In stubGenerator_sparc.cpp last ,false parameter is not removed. Vladimir Tom Rodriguez wrote: > So I've backed off from changing generate_exception_throw to perform the alignment. Given that we've seen no problems with alignment in the existing callees I have to assume they are already being called properly aligned. So instead I've added alignment code in code that throws it. I'll file a separate bug for the general issue that we should have more explicitly code for checking the alignment of calls into the runtime on x64. I've updated the webrev. I kept the stubgenerator deletions since they seemed like a good thing. > > tom > > On Sep 8, 2011, at 9:29 AM, Tom Rodriguez wrote: > >> On Sep 8, 2011, at 3:09 AM, Christian Thalinger wrote: >> >>> I don't understand that comment: >>> >>> + // FIXME: this probably needs to alignment logic >> It's a typo in a comment John asked me to add. The unsafe handler also needs alignment but I wasn't sure how to reproduce a failure so I didn't want to touch it. >> >> To be honest my whole change make me a little nervous. The current stubs all apparently work ok which suggests they are always called from contexts that are properly aligned. The only way to do alignment is to extend the caller frame, which is really only safe in some contexts. It should always be safe to adjust SP in the method handle code calls so I think I should just do some stack alignment just before jumping to the throw_WMTE_entry. Part of the problem is that we don't have any strict alignment checks when calling into the runtime. We just happen to die because the part of the JNI code was using movdqa against rbp. Anyway, I'm going to play with this a bit more. >> >> tom >> >>> -- Christian >>> >>> On Sep 8, 2011, at 5:40 AM, Tom Rodriguez wrote: >>> >>>> Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. >>>> >>>> tom >>>> >>>> On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: >>>> >>>>> Where r12 is restored? It contains coop base. >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/7088020 >>>>>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>>>>> 7088020: SEGV in JNIHandleBlock::release_block >>>>>> Reviewed-by: >>>>>> The throw_WrongMethodTypeException stub on x64 needs to align the >>>>>> stack before calling into the runtime or it might crash. I also >>>>>> noticed that two stubs were dead which made an extra argument dead so >>>>>> I cleaned that up at the same time. Tested on linux-amd64 with new >>>>>> regression test and failing tests from report. > From vladimir.kozlov at oracle.com Fri Sep 9 11:43:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 11:43:38 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> <4E6A4B02.7040407@oracle.com> <239AEC15-C70A-400D-8670-CA164E4736A6@oracle.com> <4E6A57C1.2080503@oracle.com> Message-ID: <4E6A5E5A.2070702@oracle.com> Looks good. Don't forget update next comment in vmStructs.cpp: + /* instanceKlass FieldOffset enum */ Vladimir Tom Rodriguez wrote: > FieldInfo sounds pretty good to me. I reworked fieldDescriptor to use the RawFieldDescriptor by reference similarly to the other classes and I think that helps. I'm going to rename RawFieldDescriptor to FieldInfo and move it to its own file but I've updated the webrev with all the changes we've talked about so far. Here's the summary. > > added RawFieldDescriptor::initialize > use an array to produce the FieldAllocationType > renamed RawFieldStream to FieldStreamBase and updated the comment for it. > eliminated the extra SystemDictionary aliases and simply fixed the few places that need to change their names. > > tom > > On Sep 9, 2011, at 11:15 AM, Vladimir Kozlov wrote: > >> OK. FieldInfo, FieldDesc, FieldLayoutDesc? >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Sep 9, 2011, at 10:21 AM, Vladimir Kozlov wrote: >>>> Can we just have one class FieldDescriptor. Methods and fields are almost the same. >>> They serve different functions. RawFieldDescriptor hides and describes the layout of the fields array itself. fieldDescriptor serves as a self contained object for talking about a field. Think of it as a field handle. So they have to be separate types but they could be more closely related. Much of fieldDescriptor could be replaced by subclassing RawFieldDescriptor. >>> tom >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. >>>>> tom >>>>> On Sep 8, 2011, at 3:47 PM, John Rose wrote: >>>>>> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John >>>>>> >>>>>> On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~never/7086585 >>>>>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>>>>> >>>>>>> 7086585: make Java field injection more flexible >>>>>>> Reviewed-by: > From tom.rodriguez at oracle.com Fri Sep 9 11:58:01 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 11:58:01 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: <4E6A5E5A.2070702@oracle.com> References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> <4E6A4B02.7040407@oracle.com> <239AEC15-C70A-400D-8670-CA164E4736A6@oracle.com> <4E6A57C1.2080503@oracle.com> <4E6A5E5A.2070702@oracle.com> Message-ID: On Sep 9, 2011, at 11:43 AM, Vladimir Kozlov wrote: > Looks good. > > Don't forget update next comment in vmStructs.cpp: > > + /* instanceKlass FieldOffset enum */ Fixed. I turned RawFieldDescriptor into FieldInfo and moved it into oops/fieldInfo.hpp. I also split out the field streams into oops/fieldStreams.hpp. I think at a later point the streams in reflectionUtils.hpp could be moved here but that's a bigger change because of their complex semantics. tom > > Vladimir > > Tom Rodriguez wrote: >> FieldInfo sounds pretty good to me. I reworked fieldDescriptor to use the RawFieldDescriptor by reference similarly to the other classes and I think that helps. I'm going to rename RawFieldDescriptor to FieldInfo and move it to its own file but I've updated the webrev with all the changes we've talked about so far. Here's the summary. >> added RawFieldDescriptor::initialize >> use an array to produce the FieldAllocationType >> renamed RawFieldStream to FieldStreamBase and updated the comment for it. >> eliminated the extra SystemDictionary aliases and simply fixed the few places that need to change their names. >> tom >> On Sep 9, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>> OK. FieldInfo, FieldDesc, FieldLayoutDesc? >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> On Sep 9, 2011, at 10:21 AM, Vladimir Kozlov wrote: >>>>> Can we just have one class FieldDescriptor. Methods and fields are almost the same. >>>> They serve different functions. RawFieldDescriptor hides and describes the layout of the fields array itself. fieldDescriptor serves as a self contained object for talking about a field. Think of it as a field handle. So they have to be separate types but they could be more closely related. Much of fieldDescriptor could be replaced by subclassing RawFieldDescriptor. >>>> tom >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. >>>>>> tom >>>>>> On Sep 8, 2011, at 3:47 PM, John Rose wrote: >>>>>>> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John >>>>>>> >>>>>>> On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~never/7086585 >>>>>>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>>>>>> >>>>>>>> 7086585: make Java field injection more flexible >>>>>>>> Reviewed-by: From tom.rodriguez at oracle.com Fri Sep 9 11:58:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 11:58:28 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <4E6A5AD9.6090205@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> <136F14CF-1A90-465C-95F9-70F8FE515887@oracle.com> <3F8A237B-661F-4BB9-AAC1-72B46D8ED779@oracle.com> <4E6A5AD9.6090205@oracle.com> Message-ID: <077E2B89-DED2-4E60-AEFE-C4FB2EFA6E06@oracle.com> Thanks. Fixed. tom On Sep 9, 2011, at 11:28 AM, Vladimir Kozlov wrote: > In stubGenerator_sparc.cpp last ,false parameter is not removed. > > Vladimir > > Tom Rodriguez wrote: >> So I've backed off from changing generate_exception_throw to perform the alignment. Given that we've seen no problems with alignment in the existing callees I have to assume they are already being called properly aligned. So instead I've added alignment code in code that throws it. I'll file a separate bug for the general issue that we should have more explicitly code for checking the alignment of calls into the runtime on x64. I've updated the webrev. I kept the stubgenerator deletions since they seemed like a good thing. >> tom >> On Sep 8, 2011, at 9:29 AM, Tom Rodriguez wrote: >>> On Sep 8, 2011, at 3:09 AM, Christian Thalinger wrote: >>> >>>> I don't understand that comment: >>>> >>>> + // FIXME: this probably needs to alignment logic >>> It's a typo in a comment John asked me to add. The unsafe handler also needs alignment but I wasn't sure how to reproduce a failure so I didn't want to touch it. >>> >>> To be honest my whole change make me a little nervous. The current stubs all apparently work ok which suggests they are always called from contexts that are properly aligned. The only way to do alignment is to extend the caller frame, which is really only safe in some contexts. It should always be safe to adjust SP in the method handle code calls so I think I should just do some stack alignment just before jumping to the throw_WMTE_entry. Part of the problem is that we don't have any strict alignment checks when calling into the runtime. We just happen to die because the part of the JNI code was using movdqa against rbp. Anyway, I'm going to play with this a bit more. >>> >>> tom >>> >>>> -- Christian >>>> >>>> On Sep 8, 2011, at 5:40 AM, Tom Rodriguez wrote: >>>> >>>>> Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. >>>>> >>>>> tom >>>>> >>>>> On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Where r12 is restored? It contains coop base. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/7088020 >>>>>>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>>>>>> 7088020: SEGV in JNIHandleBlock::release_block >>>>>>> Reviewed-by: >>>>>>> The throw_WrongMethodTypeException stub on x64 needs to align the >>>>>>> stack before calling into the runtime or it might crash. I also >>>>>>> noticed that two stubs were dead which made an extra argument dead so >>>>>>> I cleaned that up at the same time. Tested on linux-amd64 with new >>>>>>> regression test and failing tests from report. From vladimir.kozlov at oracle.com Fri Sep 9 12:01:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 12:01:05 -0700 Subject: review for 7088020: SEGV in JNIHandleBlock::release_block In-Reply-To: <077E2B89-DED2-4E60-AEFE-C4FB2EFA6E06@oracle.com> References: <2F986A13-DBBD-4544-894C-0AC1E4BF2B75@oracle.com> <4E67E116.3030604@oracle.com> <92B35FA4-8C1C-46AB-A75E-B628D12204E3@oracle.com> <136F14CF-1A90-465C-95F9-70F8FE515887@oracle.com> <3F8A237B-661F-4BB9-AAC1-72B46D8ED779@oracle.com> <4E6A5AD9.6090205@oracle.com> <077E2B89-DED2-4E60-AEFE-C4FB2EFA6E06@oracle.com> Message-ID: <4E6A6271.9010600@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > Thanks. Fixed. > > tom > > On Sep 9, 2011, at 11:28 AM, Vladimir Kozlov wrote: > >> In stubGenerator_sparc.cpp last ,false parameter is not removed. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> So I've backed off from changing generate_exception_throw to perform the alignment. Given that we've seen no problems with alignment in the existing callees I have to assume they are already being called properly aligned. So instead I've added alignment code in code that throws it. I'll file a separate bug for the general issue that we should have more explicitly code for checking the alignment of calls into the runtime on x64. I've updated the webrev. I kept the stubgenerator deletions since they seemed like a good thing. >>> tom >>> On Sep 8, 2011, at 9:29 AM, Tom Rodriguez wrote: >>>> On Sep 8, 2011, at 3:09 AM, Christian Thalinger wrote: >>>> >>>>> I don't understand that comment: >>>>> >>>>> + // FIXME: this probably needs to alignment logic >>>> It's a typo in a comment John asked me to add. The unsafe handler also needs alignment but I wasn't sure how to reproduce a failure so I didn't want to touch it. >>>> >>>> To be honest my whole change make me a little nervous. The current stubs all apparently work ok which suggests they are always called from contexts that are properly aligned. The only way to do alignment is to extend the caller frame, which is really only safe in some contexts. It should always be safe to adjust SP in the method handle code calls so I think I should just do some stack alignment just before jumping to the throw_WMTE_entry. Part of the problem is that we don't have any strict alignment checks when calling into the runtime. We just happen to die because the part of the JNI code was using movdqa against rbp. Anyway, I'm going to play with this a bit more. >>>> >>>> tom >>>> >>>>> -- Christian >>>>> >>>>> On Sep 8, 2011, at 5:40 AM, Tom Rodriguez wrote: >>>>> >>>>>> Strangely the WMT cases all seemed to work fine but another test was failing. Running with +WalkStackALot showed that I wasn't moving the return address so I propagated the frame adjustment outside the enter/leave. >>>>>> >>>>>> tom >>>>>> >>>>>> On Sep 7, 2011, at 2:24 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Where r12 is restored? It contains coop base. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> http://cr.openjdk.java.net/~never/7088020 >>>>>>>> 150 lines changed: 88 ins; 50 del; 12 mod; 10143 unchg >>>>>>>> 7088020: SEGV in JNIHandleBlock::release_block >>>>>>>> Reviewed-by: >>>>>>>> The throw_WrongMethodTypeException stub on x64 needs to align the >>>>>>>> stack before calling into the runtime or it might crash. I also >>>>>>>> noticed that two stubs were dead which made an extra argument dead so >>>>>>>> I cleaned that up at the same time. Tested on linux-amd64 with new >>>>>>>> regression test and failing tests from report. > From vladimir.kozlov at oracle.com Fri Sep 9 12:04:47 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 12:04:47 -0700 Subject: review for 7086585: make Java field injection more flexible In-Reply-To: References: <33EB44BB-6439-4C0E-8DB2-52A393DD0CA9@oracle.com> <833F389D-3A1A-44DD-9FDA-6DBFF4C20870@oracle.com> <4E6A4B02.7040407@oracle.com> <239AEC15-C70A-400D-8670-CA164E4736A6@oracle.com> <4E6A57C1.2080503@oracle.com> <4E6A5E5A.2070702@oracle.com> Message-ID: <4E6A634F.4050702@oracle.com> Very good. Thanks, Vladimir Tom Rodriguez wrote: > On Sep 9, 2011, at 11:43 AM, Vladimir Kozlov wrote: > >> Looks good. >> >> Don't forget update next comment in vmStructs.cpp: >> >> + /* instanceKlass FieldOffset enum */ > > Fixed. I turned RawFieldDescriptor into FieldInfo and moved it into oops/fieldInfo.hpp. I also split out the field streams into oops/fieldStreams.hpp. I think at a later point the streams in reflectionUtils.hpp could be moved here but that's a bigger change because of their complex semantics. > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> FieldInfo sounds pretty good to me. I reworked fieldDescriptor to use the RawFieldDescriptor by reference similarly to the other classes and I think that helps. I'm going to rename RawFieldDescriptor to FieldInfo and move it to its own file but I've updated the webrev with all the changes we've talked about so far. Here's the summary. >>> added RawFieldDescriptor::initialize >>> use an array to produce the FieldAllocationType >>> renamed RawFieldStream to FieldStreamBase and updated the comment for it. >>> eliminated the extra SystemDictionary aliases and simply fixed the few places that need to change their names. >>> tom >>> On Sep 9, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>>> OK. FieldInfo, FieldDesc, FieldLayoutDesc? >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> On Sep 9, 2011, at 10:21 AM, Vladimir Kozlov wrote: >>>>>> Can we just have one class FieldDescriptor. Methods and fields are almost the same. >>>>> They serve different functions. RawFieldDescriptor hides and describes the layout of the fields array itself. fieldDescriptor serves as a self contained object for talking about a field. Think of it as a field handle. So they have to be separate types but they could be more closely related. Much of fieldDescriptor could be replaced by subclassing RawFieldDescriptor. >>>>> tom >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I had a side conversion with Coleen about this and she suggested moving RawFieldDescriptor into it's own file, which I think is a good idea. She also commented on the confusion between RawFieldDescriptor and fieldDescriptor because of the name similarity. I had looked at making fieldDescriptor a subclass of RawField at one point and I think I might be able to make that work. I also think the RawFieldDescriptor name is bad. How about FieldLayout? Any opinions? I had also considered fixing the capitalization of fieldDescriptor. >>>>>>> tom >>>>>>> On Sep 8, 2011, at 3:47 PM, John Rose wrote: >>>>>>>> I've reviewed it. It's excellent. Extra thanks for getting rid of instanceKlass::next_offset. -- John >>>>>>>> >>>>>>>> On Sep 8, 2011, at 1:38 PM, Tom Rodriguez wrote: >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~never/7086585 >>>>>>>>> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg >>>>>>>>> >>>>>>>>> 7086585: make Java field injection more flexible >>>>>>>>> Reviewed-by: > From tom.rodriguez at oracle.com Fri Sep 9 12:11:11 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 12:11:11 -0700 Subject: Request for reviews (S): 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 In-Reply-To: <4E6A44C0.9080108@oracle.com> References: <4E6A44C0.9080108@oracle.com> Message-ID: Looks good. tom On Sep 9, 2011, at 9:54 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7035946/webrev > > 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 > > It is almost exact anti-delta of my changes in 7008866. I kept replace_parallel_iv() as separate method and added new TraceLoopOpts output. > > I traced down the most of regression to my changes for "replace parallel induction variables" optimization in 7008866 fix. I replaced new nodes IGVN registration with immediate Ideal transformation. As result Split_If optimization reversed it back by doing spit through Phi and it prevents loop predicates (which follow Split_If) execute RCE. If local transformation in replace_parallel_iv() is not executed the created new code matches RCE shape: iv*ratio+(init2-init*ratio) where (init2-init*ratio) is loop invariant. And Split_If optimization does not execute spit through Phi for AddI nodes in Counted loops. Yes, a lot of hidden dependences. > > An other part of regression came from always creation of new loop iteration Phi node. I was not able to find why it has regression affect. I returned code back to keep original Phi. > > I do not see affect on refworkload benchmark after this fix. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Sep 9 12:13:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 12:13:33 -0700 Subject: Request for reviews (S): 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 In-Reply-To: References: <4E6A44C0.9080108@oracle.com> Message-ID: <4E6A655D.8040301@oracle.com> Thank you, Tom Vlaidmir Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 9, 2011, at 9:54 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7035946/webrev >> >> 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 >> >> It is almost exact anti-delta of my changes in 7008866. I kept replace_parallel_iv() as separate method and added new TraceLoopOpts output. >> >> I traced down the most of regression to my changes for "replace parallel induction variables" optimization in 7008866 fix. I replaced new nodes IGVN registration with immediate Ideal transformation. As result Split_If optimization reversed it back by doing spit through Phi and it prevents loop predicates (which follow Split_If) execute RCE. If local transformation in replace_parallel_iv() is not executed the created new code matches RCE shape: iv*ratio+(init2-init*ratio) where (init2-init*ratio) is loop invariant. And Split_If optimization does not execute spit through Phi for AddI nodes in Counted loops. Yes, a lot of hidden dependences. >> >> An other part of regression came from always creation of new loop iteration Phi node. I was not able to find why it has regression affect. I returned code back to keep original Phi. >> >> I do not see affect on refworkload benchmark after this fix. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Fri Sep 9 14:24:50 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 14:24:50 -0700 Subject: review for 7088955: add C2 IR support to the SA Message-ID: http://cr.openjdk.java.net/~never/7088955 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg 7088955: add C2 IR support to the SA Reviewed-by: These are bunch of SA improvements I collected as part of the replay support. It includes support for C2 types and dumping of the graph, the PhaseCFG, the InlineTree and MDOs. There are a bunch of new classes to support this but for the most part they are simple mirrors for their corresponding C++ classes and could be generated directly from the vmStructs declarations. About half of the new lines are copyright notices and Java boilerplate. The C++ changes consist only of friend declarations and moving nmethodBucket to the header so it can be described by vmStructs. This also includes support in the SA for augmenting the type database of a JVM during reading of a core file and dumping the type database with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will read after parsing the vmStructs from the child and add any new definitions to the type database. The saenv scripts recognize the environment variable SA_TYPEDB and pass the value in the property to the invoked VM. I also augmented the type database logic so that it can create const and pointer variants of types on the fly so they no longer need to be declared in vmStructs.cpp. Additionally I added support for GrowableArray templating to support reading various data structures. I also deleted the win32 and dbx debugger backends since those were supplanted by the windbg and proc backends. The webrev itself is quite large but most of the newly added classes were generated from the vmStructs.cpp declarations or by simple transliteration of C++ code. The meaningful bits are all at the beginning of the webrev. The replay stuff will be laid on top of these changes. Tested with sajdi tests. From igor.veresov at oracle.com Fri Sep 9 15:58:45 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 09 Sep 2011 22:58:45 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 36 new changesets Message-ID: <20110909225950.0F38347500@hg.openjdk.java.net> Changeset: ff53346271fe Author: brutisso Date: 2011-08-19 09:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ff53346271fe 6814390: G1: remove the concept of non-generational G1 Summary: Removed the possibility to turn off generational mode for G1. Reviewed-by: johnc, ysr, tonyp ! 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/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/g1_globals.hpp Changeset: ae73da50be4b Author: tonyp Date: 2011-08-22 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ae73da50be4b 7081064: G1: remove develop params G1FixedSurvivorSpaceSize, G1FixedTenuringThreshold, and G1FixedEdenSize Summary: Remove three develop parameters we don't use. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7f776886a215 Author: ysr Date: 2011-08-22 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7f776886a215 6810861: G1: support -XX:+{PrintClassHistogram,HeapDump}{Before,After}FullGC Summary: Call {pre,post}_full_gc_dump() before and after a STW full gc of G1CollectedHeap. Also adjusted the prefix message, including the addition of missing whitespace. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: be05e987ba07 Author: ysr Date: 2011-08-22 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be05e987ba07 Merge Changeset: 2f27ed2a98fa Author: brutisso Date: 2011-08-23 11:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2f27ed2a98fa 7082220: Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls and new Summary: Add the psapi.lib library to Visual Studio projects Reviewed-by: jwilhelm, poonam, kamg ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: a70c2acb8f52 Author: kvn Date: 2011-08-25 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a70c2acb8f52 Merge Changeset: 1520340a7f35 Author: kvn Date: 2011-08-26 16:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1520340a7f35 7083916: Bump the hs22 build number to 03 Reviewed-by: jcoomes Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 31e253c1da42 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/31e253c1da42 Added tag jdk8-b01 for changeset 0cc8a70952c3 ! .hgtags Changeset: a3592789b47c Author: schien Date: 2011-08-25 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a3592789b47c Added tag jdk8-b02 for changeset 31e253c1da42 ! .hgtags Changeset: 3a2fb61165df Author: jcoomes Date: 2011-08-31 13:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3a2fb61165df Merge - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java Changeset: 0fa3ace511fe Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0fa3ace511fe Added tag jdk8-b03 for changeset 3a2fb61165df ! .hgtags Changeset: 5755e84e970f Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5755e84e970f Added tag hs22-b01 for changeset 0cc8a70952c3 ! .hgtags Changeset: 40c5e268d399 Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/40c5e268d399 Added tag hs22-b02 for changeset 7c29742c41b4 ! .hgtags Changeset: 52220701f19f Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/52220701f19f Added tag hs22-b03 for changeset 3a2fb61165df ! .hgtags Changeset: ce9bde819dcb Author: jcoomes Date: 2011-09-02 03:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ce9bde819dcb 7086589: bump the hs22 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5c123cbeebbe Author: jcoomes Date: 2011-09-02 15:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5c123cbeebbe Added tag hs22-b04 for changeset ce9bde819dcb ! .hgtags Changeset: 3cd0157e1d4d Author: iveresov Date: 2011-08-25 02:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3cd0157e1d4d 7082969: NUMA interleaving Summary: Support interleaving on NUMA systems for collectors that don't have NUMA-awareness. Reviewed-by: iveresov, ysr Contributed-by: Tom Deneau ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: eeae91c9baba Author: johnc Date: 2011-08-29 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eeae91c9baba 7080389: G1: refactor marking code in evacuation pause copy closures Summary: Refactor code marking code in the evacuation pause copy closures so that an evacuated object is only marked by the thread that successfully copies it. Reviewed-by: stefank, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp Changeset: 9447b2fb6fcf Author: iveresov Date: 2011-08-29 17:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9447b2fb6fcf 7082645: Hotspot doesn't compile on old linuxes after 7060836 Summary: Move syscall ids definitions into os_linux.cpp Reviewed-by: johnc ! src/os/linux/vm/os_linux.cpp Changeset: 4fe626cbf0bf Author: johnc Date: 2011-08-31 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4fe626cbf0bf 7066841: remove MacroAssembler::br_on_reg_cond() on sparc Summary: Remove the macro assembler routine br_on_reg_cond() and replace the remaining calls to that routine with an equivalent. Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ae1b1788f63f Author: ysr Date: 2011-08-31 23:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ae1b1788f63f Merge Changeset: 4668545121b8 Author: jcoomes Date: 2011-09-02 21:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4668545121b8 Merge Changeset: d968f546734e Author: iveresov Date: 2011-09-07 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d968f546734e Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/runtime/globals.hpp - src/share/vm/runtime/reflectionCompat.hpp Changeset: 2fecca53a2c6 Author: roland Date: 2011-09-07 14:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2fecca53a2c6 7085012: ARM: com/sun/jdi/PopSynchronousTest.java still fails Summary: InterpreterRuntime::popframe_move_outgoing_args() is required for the ARM interpreter. Reviewed-by: kvn, twisti ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: 5596e125fe4f Author: rottenha Date: 2011-09-08 06:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5596e125fe4f Merge ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 27702f012017 Author: iveresov Date: 2011-09-06 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/27702f012017 7087583: Hotspot fails to allocate heap with mmap(MAP_HUGETLB) Summary: Try using small pages when transparent huge pages allocation fails Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 20213c8a3c40 Author: tonyp Date: 2011-09-07 12:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/20213c8a3c40 7050392: G1: Introduce flag to generate a log of the G1 ergonomic decisions Summary: It introduces ergonomic decision logging in G1 for the following heuristics: heap sizing, collection set construction, concurrent cycle initiation, and partially-young GC start/end. The code has a bit of refactoring in a few places to make the decision logging possible. It also replaces alternative ad-hoc logging that we have under different parameters and switches (G1_DEBUG, G1PolicyVerbose). Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1ErgoVerbose.cpp + src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c2bf0120ee5d Author: stefank Date: 2011-09-01 16:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c2bf0120ee5d 7085906: Replace the permgen allocated sentinelRef with a self-looped end Summary: Remove the sentinelRef and let the last Reference in a discovered chain point back to itself. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: 05550041d664 Author: ysr Date: 2011-09-07 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/05550041d664 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: eca1193ca245 Author: ysr Date: 2011-09-07 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eca1193ca245 4965777: GC changes to support use of discovered field for pending references Summary: If and when the reference handler thread is able to use the discovered field to link reference objects in its pending list, so will GC. In that case, GC will scan through this field once a reference object has been placed on the pending list, but not scan that field before that stage, as the field is used by the concurrent GC thread to link discovered objects. When ReferenceHandleR thread does not use the discovered field for the purpose of linking the elements in the pending list, as would be the case in older JDKs, the JVM will fall back to the old behaviour of using the next field for that purpose. Reviewed-by: jcoomes, mchung, stefank ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp Changeset: a6128a8ed624 Author: iveresov Date: 2011-09-07 18:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a6128a8ed624 7086226: UseNUMA fails on old versions of windows Summary: Return correct answers from os::numa_*() for UMA machines or if NUMA API is not supported Reviewed-by: johnc ! src/os/windows/vm/os_windows.cpp Changeset: 4f41766176cf Author: tonyp Date: 2011-09-08 05:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4f41766176cf 7084509: G1: fix inconsistencies and mistakes in the young list target length calculations Summary: Fixed inconsistencies and mistakes in the young list target length calculations so that a) the calculated target length is optimal (before, it was not), b) other parameters like max survivor size and max gc locker eden expansion are always consistent with the calculated target length (before, they were not always), and c) the resulting target length was always bound by desired min and max values (before, it was not). Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: af2ab04e0038 Author: brutisso Date: 2011-09-08 16:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/af2ab04e0038 6929868: G1: introduce min / max young gen size bounds Summary: Make G1 handle young gen size command line flags more consistently Reviewed-by: tonyp, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 3bddbf0f57d6 Author: tonyp Date: 2011-09-09 05:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3bddbf0f57d6 7087717: G1: make the G1PrintRegionLivenessInfo parameter diagnostic Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: e984655be425 Author: stefank Date: 2011-09-09 14:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e984655be425 Merge ! src/share/vm/prims/jvm.h Changeset: 5257f8e66b40 Author: iveresov Date: 2011-09-09 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5257f8e66b40 Merge ! src/share/vm/runtime/arguments.cpp From vladimir.kozlov at oracle.com Fri Sep 9 16:16:23 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 16:16:23 -0700 Subject: review for 7088955: add C2 IR support to the SA In-Reply-To: References: Message-ID: <4E6A9E47.30001@oracle.com> Push it :) What criteria you used to map only some C2 node classes? I don't see next fields in Node.java (may be not needed) jushort _class_id; jushort _flags; and no C2 types. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7088955 > 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg > > 7088955: add C2 IR support to the SA > Reviewed-by: > > These are bunch of SA improvements I collected as part of the replay > support. It includes support for C2 types and dumping of the graph, > the PhaseCFG, the InlineTree and MDOs. There are a bunch of new > classes to support this but for the most part they are simple mirrors > for their corresponding C++ classes and could be generated directly > from the vmStructs declarations. About half of the new lines are > copyright notices and Java boilerplate. > > The C++ changes consist only of friend declarations and moving > nmethodBucket to the header so it can be described by vmStructs. > > This also includes support in the SA for augmenting the type database > of a JVM during reading of a core file and dumping the type database > with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will > read after parsing the vmStructs from the child and add any new > definitions to the type database. The saenv scripts recognize the > environment variable SA_TYPEDB and pass the value in the property to > the invoked VM. I also augmented the type database logic so that it > can create const and pointer variants of types on the fly so they no > longer need to be declared in vmStructs.cpp. Additionally I added > support for GrowableArray templating to support reading various data > structures. > > I also deleted the win32 and dbx debugger backends since those were > supplanted by the windbg and proc backends. > > The webrev itself is quite large but most of the newly added classes > were generated from the vmStructs.cpp declarations or by simple > transliteration of C++ code. The meaningful bits are all at the > beginning of the webrev. > > The replay stuff will be laid on top of these changes. > > Tested with sajdi tests. > From tom.rodriguez at oracle.com Fri Sep 9 16:24:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 16:24:46 -0700 Subject: review for 7088955: add C2 IR support to the SA In-Reply-To: <4E6A9E47.30001@oracle.com> References: <4E6A9E47.30001@oracle.com> Message-ID: <7611EEB2-9388-4EFE-A23E-27C7F284B156@oracle.com> On Sep 9, 2011, at 4:16 PM, Vladimir Kozlov wrote: > Push it :) > > What criteria you used to map only some C2 node classes? I mapped the ones that seemed important and didn't require extensive work. We can always add more. Any in particular you want? > > I don't see next fields in Node.java (may be not needed) > > jushort _class_id; > jushort _flags; The information in the class_id should match the inheritance so it didn't seem that necessary. I can at least add the declaration to vmStructs.cpp. > > and no C2 types. Do you mean type.hpp? I just ran out of stream at that point I think. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7088955 >> 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg >> 7088955: add C2 IR support to the SA >> Reviewed-by: >> These are bunch of SA improvements I collected as part of the replay >> support. It includes support for C2 types and dumping of the graph, >> the PhaseCFG, the InlineTree and MDOs. There are a bunch of new >> classes to support this but for the most part they are simple mirrors >> for their corresponding C++ classes and could be generated directly >> from the vmStructs declarations. About half of the new lines are >> copyright notices and Java boilerplate. >> The C++ changes consist only of friend declarations and moving >> nmethodBucket to the header so it can be described by vmStructs. >> This also includes support in the SA for augmenting the type database >> of a JVM during reading of a core file and dumping the type database >> with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will >> read after parsing the vmStructs from the child and add any new >> definitions to the type database. The saenv scripts recognize the >> environment variable SA_TYPEDB and pass the value in the property to >> the invoked VM. I also augmented the type database logic so that it >> can create const and pointer variants of types on the fly so they no >> longer need to be declared in vmStructs.cpp. Additionally I added >> support for GrowableArray templating to support reading various data >> structures. >> I also deleted the win32 and dbx debugger backends since those were >> supplanted by the windbg and proc backends. >> The webrev itself is quite large but most of the newly added classes >> were generated from the vmStructs.cpp declarations or by simple >> transliteration of C++ code. The meaningful bits are all at the >> beginning of the webrev. >> The replay stuff will be laid on top of these changes. >> Tested with sajdi tests. From vladimir.kozlov at oracle.com Fri Sep 9 16:30:52 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 16:30:52 -0700 Subject: review for 7088955: add C2 IR support to the SA In-Reply-To: <7611EEB2-9388-4EFE-A23E-27C7F284B156@oracle.com> References: <4E6A9E47.30001@oracle.com> <7611EEB2-9388-4EFE-A23E-27C7F284B156@oracle.com> Message-ID: <4E6AA1AC.3020306@oracle.com> Tom Rodriguez wrote: > On Sep 9, 2011, at 4:16 PM, Vladimir Kozlov wrote: > >> Push it :) >> >> What criteria you used to map only some C2 node classes? > > I mapped the ones that seemed important and didn't require extensive work. We can always add more. Any in particular you want? No, for initial push I think it is enough. Do I understand correctly that we don't need them for Replay? It is only for debugging compiler threads. > >> I don't see next fields in Node.java (may be not needed) >> >> jushort _class_id; >> jushort _flags; > > The information in the class_id should match the inheritance so it didn't seem that necessary. I can at least add the declaration to vmStructs.cpp. OK. > >> and no C2 types. > > Do you mean type.hpp? I just ran out of stream at that point I think. Yes, and it is fine to not have it now. Thanks, Vladimir > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7088955 >>> 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg >>> 7088955: add C2 IR support to the SA >>> Reviewed-by: >>> These are bunch of SA improvements I collected as part of the replay >>> support. It includes support for C2 types and dumping of the graph, >>> the PhaseCFG, the InlineTree and MDOs. There are a bunch of new >>> classes to support this but for the most part they are simple mirrors >>> for their corresponding C++ classes and could be generated directly >>> from the vmStructs declarations. About half of the new lines are >>> copyright notices and Java boilerplate. >>> The C++ changes consist only of friend declarations and moving >>> nmethodBucket to the header so it can be described by vmStructs. >>> This also includes support in the SA for augmenting the type database >>> of a JVM during reading of a core file and dumping the type database >>> with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will >>> read after parsing the vmStructs from the child and add any new >>> definitions to the type database. The saenv scripts recognize the >>> environment variable SA_TYPEDB and pass the value in the property to >>> the invoked VM. I also augmented the type database logic so that it >>> can create const and pointer variants of types on the fly so they no >>> longer need to be declared in vmStructs.cpp. Additionally I added >>> support for GrowableArray templating to support reading various data >>> structures. >>> I also deleted the win32 and dbx debugger backends since those were >>> supplanted by the windbg and proc backends. >>> The webrev itself is quite large but most of the newly added classes >>> were generated from the vmStructs.cpp declarations or by simple >>> transliteration of C++ code. The meaningful bits are all at the >>> beginning of the webrev. >>> The replay stuff will be laid on top of these changes. >>> Tested with sajdi tests. > From tom.rodriguez at oracle.com Fri Sep 9 17:08:16 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Sep 2011 17:08:16 -0700 Subject: review for 7088955: add C2 IR support to the SA In-Reply-To: <4E6AA1AC.3020306@oracle.com> References: <4E6A9E47.30001@oracle.com> <7611EEB2-9388-4EFE-A23E-27C7F284B156@oracle.com> <4E6AA1AC.3020306@oracle.com> Message-ID: <96A7BF55-DDA6-4ECC-9F0D-E60AAFBAD60E@oracle.com> On Sep 9, 2011, at 4:30 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Sep 9, 2011, at 4:16 PM, Vladimir Kozlov wrote: >>> Push it :) >>> >>> What criteria you used to map only some C2 node classes? >> I mapped the ones that seemed important and didn't require extensive work. We can always add more. Any in particular you want? > > No, for initial push I think it is enough. Do I understand correctly that we don't need them for Replay? It is only for debugging compiler threads. The post mortem replay stuff uses the SA's support for the CI to build replay but these changes are all just targeted at debugging the compiler. tom > >>> I don't see next fields in Node.java (may be not needed) >>> >>> jushort _class_id; >>> jushort _flags; >> The information in the class_id should match the inheritance so it didn't seem that necessary. I can at least add the declaration to vmStructs.cpp. > > OK. > >>> and no C2 types. >> Do you mean type.hpp? I just ran out of stream at that point I think. > > Yes, and it is fine to not have it now. > > Thanks, > Vladimir > >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7088955 >>>> 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg >>>> 7088955: add C2 IR support to the SA >>>> Reviewed-by: >>>> These are bunch of SA improvements I collected as part of the replay >>>> support. It includes support for C2 types and dumping of the graph, >>>> the PhaseCFG, the InlineTree and MDOs. There are a bunch of new >>>> classes to support this but for the most part they are simple mirrors >>>> for their corresponding C++ classes and could be generated directly >>>> from the vmStructs declarations. About half of the new lines are >>>> copyright notices and Java boilerplate. >>>> The C++ changes consist only of friend declarations and moving >>>> nmethodBucket to the header so it can be described by vmStructs. >>>> This also includes support in the SA for augmenting the type database >>>> of a JVM during reading of a core file and dumping the type database >>>> with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will >>>> read after parsing the vmStructs from the child and add any new >>>> definitions to the type database. The saenv scripts recognize the >>>> environment variable SA_TYPEDB and pass the value in the property to >>>> the invoked VM. I also augmented the type database logic so that it >>>> can create const and pointer variants of types on the fly so they no >>>> longer need to be declared in vmStructs.cpp. Additionally I added >>>> support for GrowableArray templating to support reading various data >>>> structures. >>>> I also deleted the win32 and dbx debugger backends since those were >>>> supplanted by the windbg and proc backends. >>>> The webrev itself is quite large but most of the newly added classes >>>> were generated from the vmStructs.cpp declarations or by simple >>>> transliteration of C++ code. The meaningful bits are all at the >>>> beginning of the webrev. >>>> The replay stuff will be laid on top of these changes. >>>> Tested with sajdi tests. From vladimir.kozlov at oracle.com Fri Sep 9 17:10:27 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Sep 2011 17:10:27 -0700 Subject: review for 7088955: add C2 IR support to the SA In-Reply-To: <96A7BF55-DDA6-4ECC-9F0D-E60AAFBAD60E@oracle.com> References: <4E6A9E47.30001@oracle.com> <7611EEB2-9388-4EFE-A23E-27C7F284B156@oracle.com> <4E6AA1AC.3020306@oracle.com> <96A7BF55-DDA6-4ECC-9F0D-E60AAFBAD60E@oracle.com> Message-ID: <4E6AAAF3.9080404@oracle.com> Than you, Tom. This looks good. Vladimir Tom Rodriguez wrote: > On Sep 9, 2011, at 4:30 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> On Sep 9, 2011, at 4:16 PM, Vladimir Kozlov wrote: >>>> Push it :) >>>> >>>> What criteria you used to map only some C2 node classes? >>> I mapped the ones that seemed important and didn't require extensive work. We can always add more. Any in particular you want? >> No, for initial push I think it is enough. Do I understand correctly that we don't need them for Replay? It is only for debugging compiler threads. > > The post mortem replay stuff uses the SA's support for the CI to build replay but these changes are all just targeted at debugging the compiler. > > tom > >>>> I don't see next fields in Node.java (may be not needed) >>>> >>>> jushort _class_id; >>>> jushort _flags; >>> The information in the class_id should match the inheritance so it didn't seem that necessary. I can at least add the declaration to vmStructs.cpp. >> OK. >> >>>> and no C2 types. >>> Do you mean type.hpp? I just ran out of stream at that point I think. >> Yes, and it is fine to not have it now. >> >> Thanks, >> Vladimir >> >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7088955 >>>>> 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg >>>>> 7088955: add C2 IR support to the SA >>>>> Reviewed-by: >>>>> These are bunch of SA improvements I collected as part of the replay >>>>> support. It includes support for C2 types and dumping of the graph, >>>>> the PhaseCFG, the InlineTree and MDOs. There are a bunch of new >>>>> classes to support this but for the most part they are simple mirrors >>>>> for their corresponding C++ classes and could be generated directly >>>>> from the vmStructs declarations. About half of the new lines are >>>>> copyright notices and Java boilerplate. >>>>> The C++ changes consist only of friend declarations and moving >>>>> nmethodBucket to the header so it can be described by vmStructs. >>>>> This also includes support in the SA for augmenting the type database >>>>> of a JVM during reading of a core file and dumping the type database >>>>> with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will >>>>> read after parsing the vmStructs from the child and add any new >>>>> definitions to the type database. The saenv scripts recognize the >>>>> environment variable SA_TYPEDB and pass the value in the property to >>>>> the invoked VM. I also augmented the type database logic so that it >>>>> can create const and pointer variants of types on the fly so they no >>>>> longer need to be declared in vmStructs.cpp. Additionally I added >>>>> support for GrowableArray templating to support reading various data >>>>> structures. >>>>> I also deleted the win32 and dbx debugger backends since those were >>>>> supplanted by the windbg and proc backends. >>>>> The webrev itself is quite large but most of the newly added classes >>>>> were generated from the vmStructs.cpp declarations or by simple >>>>> transliteration of C++ code. The meaningful bits are all at the >>>>> beginning of the webrev. >>>>> The replay stuff will be laid on top of these changes. >>>>> Tested with sajdi tests. > From vladimir.kozlov at oracle.com Fri Sep 9 18:11:39 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 10 Sep 2011 01:11:39 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 Message-ID: <20110910011144.E0A6B4750A@hg.openjdk.java.net> Changeset: 2c24ef16533d Author: kvn Date: 2011-09-09 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2c24ef16533d 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 Summary: Revert changes which caused regression. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp From tom.rodriguez at oracle.com Sat Sep 10 03:22:44 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 10 Sep 2011 10:22:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7088020: SEGV in JNIHandleBlock::release_block Message-ID: <20110910102249.235D647521@hg.openjdk.java.net> Changeset: c565834fb592 Author: never Date: 2011-09-10 00:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c565834fb592 7088020: SEGV in JNIHandleBlock::release_block Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088020/Test7088020.java From tom.rodriguez at oracle.com Sat Sep 10 19:42:04 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sun, 11 Sep 2011 02:42:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7086585: make Java field injection more flexible Message-ID: <20110911024208.5CDD947544@hg.openjdk.java.net> Changeset: e6b1331a51d2 Author: never Date: 2011-09-10 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e6b1331a51d2 7086585: make Java field injection more flexible Reviewed-by: jrose, twisti, kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/test/jdi/sasanity.sh ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCacheOop.cpp + src/share/vm/oops/fieldInfo.hpp + src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/accessFlags.hpp From tom.rodriguez at oracle.com Sun Sep 11 18:13:05 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 12 Sep 2011 01:13:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7088955: add C2 IR support to the SA Message-ID: <20110912011307.C32C84758B@hg.openjdk.java.net> Changeset: f6f3bb0ee072 Author: never Date: 2011-09-11 14:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f6f3bb0ee072 7088955: add C2 IR support to the SA Reviewed-by: kvn ! agent/make/Makefile ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/Makefile - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/DebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java + agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/AddressException.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/SADebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java + agent/src/share/classes/sun/jvm/hotspot/oops/ArrayData.java + agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java + agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CIntField.java + agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java + agent/src/share/classes/sun/jvm/hotspot/oops/DataLayout.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/FieldType.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java + agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java + agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java + agent/src/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java + agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java + agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java + agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java + agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java + agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java + agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java + agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompilerThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/InstanceConstructor.java + agent/src/share/classes/sun/jvm/hotspot/runtime/StaticBaseConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java + agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualBaseConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualConstructor.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 ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/types/TypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/CommandProcessorPanel.java + agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java + agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! make/sa.files ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/growableArray.hpp From christian.thalinger at oracle.com Mon Sep 12 02:34:42 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Sep 2011 11:34:42 +0200 Subject: review for 7088955: add C2 IR support to the SA In-Reply-To: <4E6AAAF3.9080404@oracle.com> References: <4E6A9E47.30001@oracle.com> <7611EEB2-9388-4EFE-A23E-27C7F284B156@oracle.com> <4E6AA1AC.3020306@oracle.com> <96A7BF55-DDA6-4ECC-9F0D-E60AAFBAD60E@oracle.com> <4E6AAAF3.9080404@oracle.com> Message-ID: <114188D6-8251-4B82-8DB2-A52E7138D0F8@oracle.com> I get these two lines printed by vmStructs.cpp when running a debug VM: type "jushort" not found type "jushort" not found Seems like it's coming from: c2_nonstatic_field(Node, _class_id, jushort) \ c2_nonstatic_field(Node, _flags, jushort) \ -- Christian On Sep 10, 2011, at 2:10 AM, Vladimir Kozlov wrote: > Than you, Tom. > > This looks good. > > Vladimir > > Tom Rodriguez wrote: >> On Sep 9, 2011, at 4:30 PM, Vladimir Kozlov wrote: >>> Tom Rodriguez wrote: >>>> On Sep 9, 2011, at 4:16 PM, Vladimir Kozlov wrote: >>>>> Push it :) >>>>> >>>>> What criteria you used to map only some C2 node classes? >>>> I mapped the ones that seemed important and didn't require extensive work. We can always add more. Any in particular you want? >>> No, for initial push I think it is enough. Do I understand correctly that we don't need them for Replay? It is only for debugging compiler threads. >> The post mortem replay stuff uses the SA's support for the CI to build replay but these changes are all just targeted at debugging the compiler. >> tom >>>>> I don't see next fields in Node.java (may be not needed) >>>>> >>>>> jushort _class_id; >>>>> jushort _flags; >>>> The information in the class_id should match the inheritance so it didn't seem that necessary. I can at least add the declaration to vmStructs.cpp. >>> OK. >>> >>>>> and no C2 types. >>>> Do you mean type.hpp? I just ran out of stream at that point I think. >>> Yes, and it is fine to not have it now. >>> >>> Thanks, >>> Vladimir >>> >>>> tom >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/7088955 >>>>>> 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg >>>>>> 7088955: add C2 IR support to the SA >>>>>> Reviewed-by: >>>>>> These are bunch of SA improvements I collected as part of the replay >>>>>> support. It includes support for C2 types and dumping of the graph, >>>>>> the PhaseCFG, the InlineTree and MDOs. There are a bunch of new >>>>>> classes to support this but for the most part they are simple mirrors >>>>>> for their corresponding C++ classes and could be generated directly >>>>>> from the vmStructs declarations. About half of the new lines are >>>>>> copyright notices and Java boilerplate. >>>>>> The C++ changes consist only of friend declarations and moving >>>>>> nmethodBucket to the header so it can be described by vmStructs. >>>>>> This also includes support in the SA for augmenting the type database >>>>>> of a JVM during reading of a core file and dumping the type database >>>>>> with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will >>>>>> read after parsing the vmStructs from the child and add any new >>>>>> definitions to the type database. The saenv scripts recognize the >>>>>> environment variable SA_TYPEDB and pass the value in the property to >>>>>> the invoked VM. I also augmented the type database logic so that it >>>>>> can create const and pointer variants of types on the fly so they no >>>>>> longer need to be declared in vmStructs.cpp. Additionally I added >>>>>> support for GrowableArray templating to support reading various data >>>>>> structures. >>>>>> I also deleted the win32 and dbx debugger backends since those were >>>>>> supplanted by the windbg and proc backends. >>>>>> The webrev itself is quite large but most of the newly added classes >>>>>> were generated from the vmStructs.cpp declarations or by simple >>>>>> transliteration of C++ code. The meaningful bits are all at the >>>>>> beginning of the webrev. >>>>>> The replay stuff will be laid on top of these changes. >>>>>> Tested with sajdi tests. From tom.rodriguez at oracle.com Mon Sep 12 12:56:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Sep 2011 12:56:32 -0700 Subject: review for 7088955: add C2 IR support to the SA In-Reply-To: <114188D6-8251-4B82-8DB2-A52E7138D0F8@oracle.com> References: <4E6A9E47.30001@oracle.com> <7611EEB2-9388-4EFE-A23E-27C7F284B156@oracle.com> <4E6AA1AC.3020306@oracle.com> <96A7BF55-DDA6-4ECC-9F0D-E60AAFBAD60E@oracle.com> <4E6AAAF3.9080404@oracle.com> <114188D6-8251-4B82-8DB2-A52E7138D0F8@oracle.com> Message-ID: <8CD53FBF-CDC5-48CC-A046-6CD2D27AD338@oracle.com> That should have caused the JVM to abort, but the changes I gave to Coleen as part of the Symbol changes broke the assertion checking. I filed 7089709. tom On Sep 12, 2011, at 2:34 AM, Christian Thalinger wrote: > I get these two lines printed by vmStructs.cpp when running a debug VM: > > type "jushort" not found > type "jushort" not found > > Seems like it's coming from: > > c2_nonstatic_field(Node, _class_id, jushort) \ > c2_nonstatic_field(Node, _flags, jushort) \ > > -- Christian > > On Sep 10, 2011, at 2:10 AM, Vladimir Kozlov wrote: > >> Than you, Tom. >> >> This looks good. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Sep 9, 2011, at 4:30 PM, Vladimir Kozlov wrote: >>>> Tom Rodriguez wrote: >>>>> On Sep 9, 2011, at 4:16 PM, Vladimir Kozlov wrote: >>>>>> Push it :) >>>>>> >>>>>> What criteria you used to map only some C2 node classes? >>>>> I mapped the ones that seemed important and didn't require extensive work. We can always add more. Any in particular you want? >>>> No, for initial push I think it is enough. Do I understand correctly that we don't need them for Replay? It is only for debugging compiler threads. >>> The post mortem replay stuff uses the SA's support for the CI to build replay but these changes are all just targeted at debugging the compiler. >>> tom >>>>>> I don't see next fields in Node.java (may be not needed) >>>>>> >>>>>> jushort _class_id; >>>>>> jushort _flags; >>>>> The information in the class_id should match the inheritance so it didn't seem that necessary. I can at least add the declaration to vmStructs.cpp. >>>> OK. >>>> >>>>>> and no C2 types. >>>>> Do you mean type.hpp? I just ran out of stream at that point I think. >>>> Yes, and it is fine to not have it now. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> tom >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/7088955 >>>>>>> 21066 lines changed: 7246 ins; 13673 del; 147 mod; 29134 unchg >>>>>>> 7088955: add C2 IR support to the SA >>>>>>> Reviewed-by: >>>>>>> These are bunch of SA improvements I collected as part of the replay >>>>>>> support. It includes support for C2 types and dumping of the graph, >>>>>>> the PhaseCFG, the InlineTree and MDOs. There are a bunch of new >>>>>>> classes to support this but for the most part they are simple mirrors >>>>>>> for their corresponding C++ classes and could be generated directly >>>>>>> from the vmStructs declarations. About half of the new lines are >>>>>>> copyright notices and Java boilerplate. >>>>>>> The C++ changes consist only of friend declarations and moving >>>>>>> nmethodBucket to the header so it can be described by vmStructs. >>>>>>> This also includes support in the SA for augmenting the type database >>>>>>> of a JVM during reading of a core file and dumping the type database >>>>>>> with a new vmstructdump command. -Dsun.jvm.hotspot.typedb= will >>>>>>> read after parsing the vmStructs from the child and add any new >>>>>>> definitions to the type database. The saenv scripts recognize the >>>>>>> environment variable SA_TYPEDB and pass the value in the property to >>>>>>> the invoked VM. I also augmented the type database logic so that it >>>>>>> can create const and pointer variants of types on the fly so they no >>>>>>> longer need to be declared in vmStructs.cpp. Additionally I added >>>>>>> support for GrowableArray templating to support reading various data >>>>>>> structures. >>>>>>> I also deleted the win32 and dbx debugger backends since those were >>>>>>> supplanted by the windbg and proc backends. >>>>>>> The webrev itself is quite large but most of the newly added classes >>>>>>> were generated from the vmStructs.cpp declarations or by simple >>>>>>> transliteration of C++ code. The meaningful bits are all at the >>>>>>> beginning of the webrev. >>>>>>> The replay stuff will be laid on top of these changes. >>>>>>> Tested with sajdi tests. > From tom.rodriguez at oracle.com Mon Sep 12 12:57:20 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Sep 2011 12:57:20 -0700 Subject: review for 7089709: type "jushort" not found Message-ID: <65039AAC-5070-4085-B694-24CF0D01AB10@oracle.com> http://cr.openjdk.java.net/~never/7089709 2 lines changed: 1 ins; 0 del; 1 mod; 3232 unchg 7089709: type "jushort" not found Reviewed-by: The changes for 7088955 added usages of jushort but forgot to define it. I also fixed the broken assertion checking that would have caught this during the JPRT submit. Tested by running the JVM. From vladimir.kozlov at oracle.com Mon Sep 12 13:36:46 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Sep 2011 13:36:46 -0700 Subject: review for 7089709: type "jushort" not found In-Reply-To: <65039AAC-5070-4085-B694-24CF0D01AB10@oracle.com> References: <65039AAC-5070-4085-B694-24CF0D01AB10@oracle.com> Message-ID: <4E6E6D5E.2040508@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7089709 > 2 lines changed: 1 ins; 0 del; 1 mod; 3232 unchg > > 7089709: type "jushort" not found > Reviewed-by: > > The changes for 7088955 added usages of jushort but forgot to define > it. I also fixed the broken assertion checking that would have caught > this during the JPRT submit. Tested by running the JVM. > From tom.rodriguez at oracle.com Mon Sep 12 13:42:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Sep 2011 13:42:46 -0700 Subject: review for 7089709: type "jushort" not found In-Reply-To: <4E6E6D5E.2040508@oracle.com> References: <65039AAC-5070-4085-B694-24CF0D01AB10@oracle.com> <4E6E6D5E.2040508@oracle.com> Message-ID: Thanks. tom On Sep 12, 2011, at 1:36 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7089709 >> 2 lines changed: 1 ins; 0 del; 1 mod; 3232 unchg >> 7089709: type "jushort" not found >> Reviewed-by: >> The changes for 7088955 added usages of jushort but forgot to define >> it. I also fixed the broken assertion checking that would have caught >> this during the JPRT submit. Tested by running the JVM. From christian.thalinger at oracle.com Mon Sep 12 13:50:31 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Sep 2011 22:50:31 +0200 Subject: review for 7089709: type "jushort" not found In-Reply-To: <65039AAC-5070-4085-B694-24CF0D01AB10@oracle.com> References: <65039AAC-5070-4085-B694-24CF0D01AB10@oracle.com> Message-ID: <3AC7ECF7-78AA-4F87-A64E-85D6383D2F0C@oracle.com> Looks good. -- Christian On Sep 12, 2011, at 9:57 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7089709 > 2 lines changed: 1 ins; 0 del; 1 mod; 3232 unchg > > 7089709: type "jushort" not found > Reviewed-by: > > The changes for 7088955 added usages of jushort but forgot to define > it. I also fixed the broken assertion checking that would have caught > this during the JPRT submit. Tested by running the JVM. > From vladimir.kozlov at oracle.com Mon Sep 12 16:14:51 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Sep 2011 16:14:51 -0700 Subject: Request for reviews (S): 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp Message-ID: <4E6E926B.3000304@oracle.com> http://cr.openjdk.java.net/~kvn/7089632/webrev 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp The problem is spilling MachTemp and then removing intermediate MSC during postallocation in use_prior_register() so that MachTemp has additional use. Replace assert with check to delete MachTemp nodes only when they are really dead. Thanks, Vladimir From tom.rodriguez at oracle.com Mon Sep 12 16:58:34 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Sep 2011 16:58:34 -0700 Subject: Request for reviews (S): 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp In-Reply-To: <4E6E926B.3000304@oracle.com> References: <4E6E926B.3000304@oracle.com> Message-ID: <174C6775-F81C-412C-82A1-7DDE9EDC2056@oracle.com> Looks good. tom On Sep 12, 2011, at 4:14 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7089632/webrev > > 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp > > The problem is spilling MachTemp and then removing intermediate MSC during postallocation in use_prior_register() so that MachTemp has additional use. > > Replace assert with check to delete MachTemp nodes only when they are really dead. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Mon Sep 12 17:02:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Sep 2011 17:02:21 -0700 Subject: Request for reviews (S): 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp In-Reply-To: <174C6775-F81C-412C-82A1-7DDE9EDC2056@oracle.com> References: <4E6E926B.3000304@oracle.com> <174C6775-F81C-412C-82A1-7DDE9EDC2056@oracle.com> Message-ID: <4E6E9D8D.50402@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 12, 2011, at 4:14 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7089632/webrev >> >> 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp >> >> The problem is spilling MachTemp and then removing intermediate MSC during postallocation in use_prior_register() so that MachTemp has additional use. >> >> Replace assert with check to delete MachTemp nodes only when they are really dead. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Mon Sep 12 17:39:06 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 13 Sep 2011 00:39:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7089709: type "jushort" not found Message-ID: <20110913003910.DEA0A475C0@hg.openjdk.java.net> Changeset: ab577c97a5f3 Author: never Date: 2011-09-12 13:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ab577c97a5f3 7089709: type "jushort" not found Reviewed-by: kvn, twisti ! src/share/vm/runtime/vmStructs.cpp From bertrand.delsart at oracle.com Tue Sep 13 09:57:54 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 13 Sep 2011 18:57:54 +0200 Subject: Request for Review (XS): 7057978, remove ARM-only assertion in shared code Message-ID: <4E6F8B92.5050801@oracle.com> http://cr.openjdk.java.net/~bdelsart/7057978/webrev/ Removing ARM-only assertions in LIR_Address::verify(). These were causing failures in a JSR292 stress test because the shared code was generating offsets too big for the ARM instruction set. Assertions should be replaced by better handling of huge offsets in the ARM back-end or by compiler bailouts to avoid generating illegal instructions. Similar fixes might be worthwhile for other platforms but are more important on ARM, on which the encodable offsets are highly constrained. Thanks, Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vladimir.kozlov at oracle.com Tue Sep 13 17:55:43 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 14 Sep 2011 00:55:43 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp Message-ID: <20110914005550.63B4E4765B@hg.openjdk.java.net> Changeset: 2209834ccb59 Author: kvn Date: 2011-09-13 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2209834ccb59 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp Summary: Replace assert with check to delete MachTemp nodes only when they are really dead. Reviewed-by: never ! src/share/vm/opto/postaloc.cpp From bertrand.delsart at oracle.com Wed Sep 14 04:02:15 2011 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Wed, 14 Sep 2011 11:02:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7057978: improve robustness of c1 ARM back-end wrt non encodable constants Message-ID: <20110914110220.3C42C47681@hg.openjdk.java.net> Changeset: 10ee2b297ccd Author: bdelsart Date: 2011-09-14 10:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/10ee2b297ccd 7057978: improve robustness of c1 ARM back-end wrt non encodable constants Summary: ARM only, avoid assertion failures for huge constants generated by C1 shared code Reviewed-by: never, vladidan ! src/share/vm/c1/c1_LIR.cpp From bertrand.delsart at oracle.com Wed Sep 14 04:13:35 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 14 Sep 2011 13:13:35 +0200 Subject: Request For Review (XS), 7077806, ARM: java.lang.InternalError: bound subword value does not fit into the subword type Message-ID: <4E708C5F.8070704@oracle.com> Small shared fix for a bug in JSR292 ports: http://cr.openjdk.java.net/~bdelsart/7077806/webrev.00/ Error comes form the fact that shifting by values higher than the number of bits is undefined in standard C and C++: "The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." On SPARC and x86, the high bits were ignored and the code was behaving as expected. On ARM, this is not the case. The shifts were actually resulting in 0. Ensuring that the shift is a legal C value solves the problem. Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From christian.thalinger at oracle.com Wed Sep 14 04:34:05 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Sep 2011 13:34:05 +0200 Subject: Request For Review (XS), 7077806, ARM: java.lang.InternalError: bound subword value does not fit into the subword type In-Reply-To: <4E708C5F.8070704@oracle.com> References: <4E708C5F.8070704@oracle.com> Message-ID: <7ED3FEB0-2448-4AA3-BE06-1C7F77B32DD7@oracle.com> Looks good. -- Christian On Sep 14, 2011, at 1:13 PM, Bertrand Delsart wrote: > Small shared fix for a bug in JSR292 ports: > > http://cr.openjdk.java.net/~bdelsart/7077806/webrev.00/ > > Error comes form the fact that shifting by values higher than the number of bits is undefined in standard C and C++: > "The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." > > On SPARC and x86, the high bits were ignored and the code was behaving as expected. > > On ARM, this is not the case. The shifts were actually resulting in 0. > > Ensuring that the shift is a legal C value solves the problem. > > Bertrand. > > > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From christian.thalinger at oracle.com Wed Sep 14 07:00:18 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Sep 2011 16:00:18 +0200 Subject: Request for reviews (S): 7087357: JSR 292: remove obsolete code after 7085860 Message-ID: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> This fix will NOT be pushed before the changes of 7085860 have been propagated to all repositories! But I want to do the review now so I can push as soon as the propagation is finished. http://cr.openjdk.java.net/~twisti/7087357/ 7087357: JSR 292: remove obsolete code after 7085860 Reviewed-by: These changes: 7071653: JSR 292: call site change notification should be pushed not pulled 7079673: JSR 292: C1 should inline bytecoded method handle adapters 7085404: JSR 292: VolatileCallSites should have push notification too added code which can be removed if the JDK changes of 7085860 have landed. src/share/vm/classfile/javaClasses.cpp src/share/vm/interpreter/interpreterRuntime.cpp src/share/vm/prims/unsafe.cpp From roland.westrelin at oracle.com Wed Sep 14 07:21:19 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 14 Sep 2011 16:21:19 +0200 Subject: Request For Review (XS), 7077806, ARM: java.lang.InternalError: bound subword value does not fit into the subword type In-Reply-To: <4E708C5F.8070704@oracle.com> References: <4E708C5F.8070704@oracle.com> Message-ID: > Small shared fix for a bug in JSR292 ports: > > http://cr.openjdk.java.net/~bdelsart/7077806/webrev.00/ It looks ok to me. Roland. From bertrand.delsart at oracle.com Wed Sep 14 07:27:50 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 14 Sep 2011 16:27:50 +0200 Subject: Request For Review (XS), 7077806, ARM: java.lang.InternalError: bound subword value does not fit into the subword type In-Reply-To: References: <4E708C5F.8070704@oracle.com> Message-ID: <4E70B9E6.40001@oracle.com> Thanks Christian and Roland. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vladimir.kozlov at oracle.com Wed Sep 14 09:40:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Sep 2011 09:40:37 -0700 Subject: Request for reviews (S): 7087357: JSR 292: remove obsolete code after 7085860 In-Reply-To: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> References: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> Message-ID: <4E70D905.3060105@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > This fix will NOT be pushed before the changes of 7085860 have been propagated to all repositories! But I want to do the review now so I can push as soon as the propagation is finished. > > http://cr.openjdk.java.net/~twisti/7087357/ > > 7087357: JSR 292: remove obsolete code after 7085860 > Reviewed-by: > > These changes: > > 7071653: JSR 292: call site change notification should be pushed not pulled > 7079673: JSR 292: C1 should inline bytecoded method handle adapters > 7085404: JSR 292: VolatileCallSites should have push notification too > > added code which can be removed if the JDK changes of 7085860 have > landed. > > src/share/vm/classfile/javaClasses.cpp > src/share/vm/interpreter/interpreterRuntime.cpp > src/share/vm/prims/unsafe.cpp > From christian.thalinger at oracle.com Wed Sep 14 10:12:33 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Sep 2011 19:12:33 +0200 Subject: Request for reviews (S): 7087357: JSR 292: remove obsolete code after 7085860 In-Reply-To: <4E70D905.3060105@oracle.com> References: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> <4E70D905.3060105@oracle.com> Message-ID: <621DAFC4-7F3B-4A94-BD23-5395D6C6786A@oracle.com> Thank you, Vladimir. -- Christian On Sep 14, 2011, at 6:40 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Christian Thalinger wrote: >> This fix will NOT be pushed before the changes of 7085860 have been propagated to all repositories! But I want to do the review now so I can push as soon as the propagation is finished. >> http://cr.openjdk.java.net/~twisti/7087357/ >> 7087357: JSR 292: remove obsolete code after 7085860 >> Reviewed-by: >> These changes: >> 7071653: JSR 292: call site change notification should be pushed not pulled >> 7079673: JSR 292: C1 should inline bytecoded method handle adapters >> 7085404: JSR 292: VolatileCallSites should have push notification too >> added code which can be removed if the JDK changes of 7085860 have >> landed. >> src/share/vm/classfile/javaClasses.cpp >> src/share/vm/interpreter/interpreterRuntime.cpp >> src/share/vm/prims/unsafe.cpp From tom.rodriguez at oracle.com Wed Sep 14 10:17:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Sep 2011 10:17:23 -0700 Subject: Request for reviews (S): 7087357: JSR 292: remove obsolete code after 7085860 In-Reply-To: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> References: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> Message-ID: Looks good. tom On Sep 14, 2011, at 7:00 AM, Christian Thalinger wrote: > This fix will NOT be pushed before the changes of 7085860 have been propagated to all repositories! But I want to do the review now so I can push as soon as the propagation is finished. > > http://cr.openjdk.java.net/~twisti/7087357/ > > 7087357: JSR 292: remove obsolete code after 7085860 > Reviewed-by: > > These changes: > > 7071653: JSR 292: call site change notification should be pushed not pulled > 7079673: JSR 292: C1 should inline bytecoded method handle adapters > 7085404: JSR 292: VolatileCallSites should have push notification too > > added code which can be removed if the JDK changes of 7085860 have > landed. > > src/share/vm/classfile/javaClasses.cpp > src/share/vm/interpreter/interpreterRuntime.cpp > src/share/vm/prims/unsafe.cpp > From bertrand.delsart at oracle.com Wed Sep 14 10:20:07 2011 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Wed, 14 Sep 2011 17:20:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7077806: ARM: java.lang.InternalError: bound subword value does not fit into the subword type Message-ID: <20110914172012.0E0B147694@hg.openjdk.java.net> Changeset: 393f4b789fd0 Author: bdelsart Date: 2011-09-14 16:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/393f4b789fd0 7077806: ARM: java.lang.InternalError: bound subword value does not fit into the subword type Summary: shared fix necessary for ARM/PPC Reviewed-by: twisti, roland ! src/share/vm/prims/methodHandles.hpp From tom.rodriguez at oracle.com Wed Sep 14 12:42:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Sep 2011 12:42:32 -0700 Subject: review for 7090654: nightly failures after 7086585 Message-ID: <21627615-141C-4FB6-9BBC-E62CBC2CB4CA@oracle.com> http://cr.openjdk.java.net/~never/7090654 21 lines changed: 0 ins; 6 del; 15 mod; 2496 unchg 7090654: nightly failures after 7086585 Reviewed-by: I had made late changes to accessing of fields in InstanceKlass and didn't rerun my tests so I create a mismatch between the indexing. Some code was using i * 7 and others was using i. I've corrected it so it's using i consistently everything. Tested with sajdi. I screwed up the new of fields when we recreate a .class file from our internal representation. It should be unscaled. Tested with java/lang/instrument regression tests. I had thought the tests I originally ran exercised this path but I was wrong. From vladimir.kozlov at oracle.com Wed Sep 14 13:31:36 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Sep 2011 13:31:36 -0700 Subject: review for 7090654: nightly failures after 7086585 In-Reply-To: <21627615-141C-4FB6-9BBC-E62CBC2CB4CA@oracle.com> References: <21627615-141C-4FB6-9BBC-E62CBC2CB4CA@oracle.com> Message-ID: <4E710F28.3040102@oracle.com> Looks good. We should also fix error message to print actual index and class name: fatal error: Invalid constant pool index %u for field name in class file %s But it could wait. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7090654 > 21 lines changed: 0 ins; 6 del; 15 mod; 2496 unchg > > 7090654: nightly failures after 7086585 > Reviewed-by: > > I had made late changes to accessing of fields in InstanceKlass and > didn't rerun my tests so I create a mismatch between the indexing. > Some code was using i * 7 and others was using i. I've corrected it > so it's using i consistently everything. Tested with sajdi. > > I screwed up the new of fields when we recreate a .class file from our > internal representation. It should be unscaled. Tested with > java/lang/instrument regression tests. I had thought the tests I > originally ran exercised this path but I was wrong. > From tom.rodriguez at oracle.com Wed Sep 14 13:36:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Sep 2011 13:36:21 -0700 Subject: review for 7090654: nightly failures after 7086585 In-Reply-To: <4E710F28.3040102@oracle.com> References: <21627615-141C-4FB6-9BBC-E62CBC2CB4CA@oracle.com> <4E710F28.3040102@oracle.com> Message-ID: <511F3E0D-B8D4-4798-AF29-4FBAFDB67E66@oracle.com> On Sep 14, 2011, at 1:31 PM, Vladimir Kozlov wrote: > Looks good. Thanks. > We should also fix error message to print actual index and class name: > > fatal error: Invalid constant pool index %u for field name in class file %s > > But it could wait. Yes, I noticed that too. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7090654 >> 21 lines changed: 0 ins; 6 del; 15 mod; 2496 unchg >> 7090654: nightly failures after 7086585 >> Reviewed-by: >> I had made late changes to accessing of fields in InstanceKlass and >> didn't rerun my tests so I create a mismatch between the indexing. >> Some code was using i * 7 and others was using i. I've corrected it >> so it's using i consistently everything. Tested with sajdi. >> I screwed up the new of fields when we recreate a .class file from our >> internal representation. It should be unscaled. Tested with >> java/lang/instrument regression tests. I had thought the tests I >> originally ran exercised this path but I was wrong. From tom.rodriguez at oracle.com Wed Sep 14 17:09:00 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 15 Sep 2011 00:09:00 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7090654: nightly failures after 7086585 Message-ID: <20110915000906.03234476B6@hg.openjdk.java.net> Changeset: 35c656d0b685 Author: never Date: 2011-09-14 13:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/35c656d0b685 7090654: nightly failures after 7086585 Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp From christian.thalinger at oracle.com Thu Sep 15 01:12:30 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 Sep 2011 10:12:30 +0200 Subject: Request for reviews (S): 7087357: JSR 292: remove obsolete code after 7085860 In-Reply-To: References: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> Message-ID: <92956E60-9E78-4C77-9435-FE1EA1A046C8@oracle.com> Thank you, Tom. -- Christian On Sep 14, 2011, at 7:17 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 14, 2011, at 7:00 AM, Christian Thalinger wrote: > >> This fix will NOT be pushed before the changes of 7085860 have been propagated to all repositories! But I want to do the review now so I can push as soon as the propagation is finished. >> >> http://cr.openjdk.java.net/~twisti/7087357/ >> >> 7087357: JSR 292: remove obsolete code after 7085860 >> Reviewed-by: >> >> These changes: >> >> 7071653: JSR 292: call site change notification should be pushed not pulled >> 7079673: JSR 292: C1 should inline bytecoded method handle adapters >> 7085404: JSR 292: VolatileCallSites should have push notification too >> >> added code which can be removed if the JDK changes of 7085860 have >> landed. >> >> src/share/vm/classfile/javaClasses.cpp >> src/share/vm/interpreter/interpreterRuntime.cpp >> src/share/vm/prims/unsafe.cpp >> > From roland.westrelin at oracle.com Thu Sep 15 07:21:26 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 15 Sep 2011 16:21:26 +0200 Subject: review request (M): 7090968 Allow adlc register class to depend on runtime conditions Message-ID: <42649009-50F9-4328-A9B2-6E843BC9B384@oracle.com> http://cr.openjdk.java.net/~roland/7090968/webrev.00/ This adds the ability to define reg_class'es in the ad file that, rather than being static, depend on runtime conditions. For the current XXX reg_class, the generated XXX_mask const RegMask declarations are renamed _XXX_mask. XXX_mask inline function definitions are introduced that return _XXX_mask. A new form of reg_class definitions such as: reg_class some_reg_class %{ // some C code %} is introduced. In this case, the body of the generated inline SOME_REG_CLASS_mask function is defined with the C code present between %{ and %} above. Tom suggested I used this opportunity to get rid of inline_cache_reg_mask(), interpreter_method_oop_reg_mask(), interpreter_frame_pointer_reg_mask() that are unused. Roland. From christian.thalinger at oracle.com Fri Sep 16 05:02:43 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 16 Sep 2011 14:02:43 +0200 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations Message-ID: [This change will be pushed after 7087357. So ignore the code removal in src/share/vm/classfile/javaClasses.cpp.] http://cr.openjdk.java.net/~twisti/7087838/ 7087838: JSR 292: add throttling logic for optimistic call site optimizations Reviewed-by: The optimistic optimization for MutableCallSite and VolatileCallSite invalidate compiled methods on every setTarget. This possibly results in a recompile. For ever-changing call sites this is a performance hit. The fix is to add some throttling logic that prevents the optimistic optimization after a specified amount of invalidations per CallSite object. This change also moves the flush_dependents_on methods from Universe to CodeCache. src/share/vm/c1/c1_GraphBuilder.cpp src/share/vm/ci/ciCallSite.cpp src/share/vm/ci/ciCallSite.hpp src/share/vm/classfile/javaClasses.cpp src/share/vm/classfile/javaClasses.hpp src/share/vm/classfile/systemDictionary.cpp src/share/vm/classfile/vmSymbols.hpp src/share/vm/code/codeCache.cpp src/share/vm/code/codeCache.hpp src/share/vm/code/dependencies.cpp src/share/vm/code/dependencies.hpp src/share/vm/memory/universe.cpp src/share/vm/memory/universe.hpp src/share/vm/oops/methodOop.cpp src/share/vm/opto/callGenerator.cpp src/share/vm/opto/memnode.cpp src/share/vm/prims/jvmtiRedefineClasses.cpp src/share/vm/prims/methodHandles.cpp src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Fri Sep 16 10:50:29 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Sep 2011 10:50:29 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: Message-ID: <4E738C65.6060609@oracle.com> Looks fine to me. Vladimir Christian Thalinger wrote: > [This change will be pushed after 7087357. So ignore the code removal in src/share/vm/classfile/javaClasses.cpp.] > > http://cr.openjdk.java.net/~twisti/7087838/ > > 7087838: JSR 292: add throttling logic for optimistic call site optimizations > Reviewed-by: > > The optimistic optimization for MutableCallSite and VolatileCallSite > invalidate compiled methods on every setTarget. This possibly results > in a recompile. For ever-changing call sites this is a performance > hit. > > The fix is to add some throttling logic that prevents the optimistic > optimization after a specified amount of invalidations per CallSite > object. > > This change also moves the flush_dependents_on methods from Universe > to CodeCache. > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/ci/ciCallSite.cpp > src/share/vm/ci/ciCallSite.hpp > src/share/vm/classfile/javaClasses.cpp > src/share/vm/classfile/javaClasses.hpp > src/share/vm/classfile/systemDictionary.cpp > src/share/vm/classfile/vmSymbols.hpp > src/share/vm/code/codeCache.cpp > src/share/vm/code/codeCache.hpp > src/share/vm/code/dependencies.cpp > src/share/vm/code/dependencies.hpp > src/share/vm/memory/universe.cpp > src/share/vm/memory/universe.hpp > src/share/vm/oops/methodOop.cpp > src/share/vm/opto/callGenerator.cpp > src/share/vm/opto/memnode.cpp > src/share/vm/prims/jvmtiRedefineClasses.cpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/runtime/globals.hpp > From john.r.rose at oracle.com Fri Sep 16 11:39:58 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 16 Sep 2011 11:39:58 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: Message-ID: <839BEEF9-69EF-4D7D-9A79-4E1115B65636@oracle.com> Good work; reviewed! This assert in dependencies is puzzling to read, since it depends on an undocumented invariant: assert(target == changes->method_handle(), "must be"); I suggest adding an assert on Compile_lock (like many of the other methods of that kind), or at least a comment to the effect that the CS is stable under the Compile_lock. Note: We may eventually have scaling problems if there are lots of CS's bound into code, *and* lots of new CS's being created. This may require marking a CS with a bit which guarantees (under Compile_lock) there are no dependencies on that particular CS, so that the code cache does not need to be searched when a new CS is reconfigured. This is not an immediate problem, because CallSite. does not use the native method; it just initializes the field. -- John On Sep 16, 2011, at 5:02 AM, Christian Thalinger wrote: > [This change will be pushed after 7087357. So ignore the code removal in src/share/vm/classfile/javaClasses.cpp.] > > http://cr.openjdk.java.net/~twisti/7087838/ > > 7087838: JSR 292: add throttling logic for optimistic call site optimizations > Reviewed-by: From tom.rodriguez at oracle.com Fri Sep 16 12:03:55 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 16 Sep 2011 12:03:55 -0700 Subject: review request (M): 7090968 Allow adlc register class to depend on runtime conditions In-Reply-To: <42649009-50F9-4328-A9B2-6E843BC9B384@oracle.com> References: <42649009-50F9-4328-A9B2-6E843BC9B384@oracle.com> Message-ID: <32E31961-1525-4310-B5A1-E5747E1D9386@oracle.com> Looks good to me. tom On Sep 15, 2011, at 7:21 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7090968/webrev.00/ > > This adds the ability to define reg_class'es in the ad file that, rather than being static, depend on runtime conditions. For the current XXX reg_class, the generated XXX_mask const RegMask declarations are renamed _XXX_mask. XXX_mask inline function definitions are introduced that return _XXX_mask. A new form of reg_class definitions such as: > > reg_class some_reg_class %{ > // some C code > %} > > is introduced. In this case, the body of the generated inline SOME_REG_CLASS_mask function is defined with the C code present between %{ and %} above. > > Tom suggested I used this opportunity to get rid of inline_cache_reg_mask(), interpreter_method_oop_reg_mask(), interpreter_frame_pointer_reg_mask() that are unused. > > Roland. From vladimir.kozlov at oracle.com Fri Sep 16 12:19:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Sep 2011 12:19:32 -0700 Subject: review request (M): 7090968 Allow adlc register class to depend on runtime conditions In-Reply-To: <32E31961-1525-4310-B5A1-E5747E1D9386@oracle.com> References: <42649009-50F9-4328-A9B2-6E843BC9B384@oracle.com> <32E31961-1525-4310-B5A1-E5747E1D9386@oracle.com> Message-ID: <4E73A144.8000007@oracle.com> Roland, Both parts look fine. If you not done it already I would suggest to do full round of testing on all platforms and bitness with usual set: CTW, nsk, jtreg. Vladimir Tom Rodriguez wrote: > Looks good to me. > > tom > > On Sep 15, 2011, at 7:21 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~roland/7090968/webrev.00/ >> >> This adds the ability to define reg_class'es in the ad file that, rather than being static, depend on runtime conditions. For the current XXX reg_class, the generated XXX_mask const RegMask declarations are renamed _XXX_mask. XXX_mask inline function definitions are introduced that return _XXX_mask. A new form of reg_class definitions such as: >> >> reg_class some_reg_class %{ >> // some C code >> %} >> >> is introduced. In this case, the body of the generated inline SOME_REG_CLASS_mask function is defined with the C code present between %{ and %} above. >> >> Tom suggested I used this opportunity to get rid of inline_cache_reg_mask(), interpreter_method_oop_reg_mask(), interpreter_frame_pointer_reg_mask() that are unused. >> >> Roland. > From vladimir.kozlov at oracle.com Fri Sep 16 12:42:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Sep 2011 12:42:48 -0700 Subject: Request for reviews (S): 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded Message-ID: <4E73A6B8.8010305@oracle.com> http://cr.openjdk.java.net/~kvn/7081842/webrev 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded URLHammerThread::run (2785 bytes) method's code looks like spaghetti. It has loops, recursive and deep inplining. I see in LogCompilation that up to 70K ideal nodes are created during compilation. And the test passed with -XX:MaxNodeLimit=100000. So we simply missing node limit check in IGVN optimizer which is added. I also did some changes to LogCompilation parser which helped me: - added time stamp and nodes count (from parse_done event) to inlining output: @ 147 java.util.ArrayList::get (11 bytes) (end time: 7.1010 nodes: 1127) - stat output for phases prints starting and added nodes counts: optimizer 0.0030 545 497 matcher 0.0000 1042 -335 regalloc 0.0060 965 225 - ignore jvms for eliminate_allocation and eliminate_lock events instead of printing error. And I fixed linux/build.sh (which only I use, it seems) to build on x64 linux machines. Thanks, Vladimir From tom.rodriguez at oracle.com Fri Sep 16 13:48:45 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 16 Sep 2011 13:48:45 -0700 Subject: Request for reviews (S): 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded In-Reply-To: <4E73A6B8.8010305@oracle.com> References: <4E73A6B8.8010305@oracle.com> Message-ID: <6BA8611B-B5BF-4DFE-9D4C-152F6DF97EAA@oracle.com> On Sep 16, 2011, at 12:42 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7081842/webrev > > 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded > > URLHammerThread::run (2785 bytes) method's code looks like spaghetti. It has loops, recursive and deep inplining. I see in LogCompilation that up to 70K ideal nodes are created during compilation. And the test passed with -XX:MaxNodeLimit=100000. So we simply missing node limit check in IGVN optimizer which is added. That looks ok to me. We may want to reconsider some of these C->unique bailouts since they don't address the number of nodes that are actually live which is the problematic number. Some things we do generate a lot of garbage nodes that don't contribute to the final code size. This is good for now though. tom > > I also did some changes to LogCompilation parser which helped me: > - added time stamp and nodes count (from parse_done event) to inlining output: > @ 147 java.util.ArrayList::get (11 bytes) (end time: 7.1010 nodes: 1127) > > - stat output for phases prints starting and added nodes counts: > optimizer 0.0030 545 497 > matcher 0.0000 1042 -335 > regalloc 0.0060 965 225 > > - ignore jvms for eliminate_allocation and eliminate_lock events instead of printing error. > > And I fixed linux/build.sh (which only I use, it seems) to build on x64 linux machines. > > Thanks, > Vladimir From igor.veresov at oracle.com Fri Sep 16 14:13:17 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 16 Sep 2011 21:13:17 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 13 new changesets Message-ID: <20110916211344.570B447746@hg.openjdk.java.net> Changeset: dce7d24674f4 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dce7d24674f4 Added tag jdk8-b04 for changeset 0fa3ace511fe ! .hgtags Changeset: 79f9a3ed607a Author: jcoomes Date: 2011-09-09 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/79f9a3ed607a Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 513a84dd0f8b Author: jcoomes Date: 2011-09-09 16:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/513a84dd0f8b 7088991: Bump ths hs22 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 140317da459a Author: jcoomes Date: 2011-09-09 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/140317da459a Added tag hs22-b05 for changeset 513a84dd0f8b ! .hgtags Changeset: f1b4e0e0bdad Author: tonyp Date: 2011-09-13 12:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f1b4e0e0bdad 7089625: G1: policy for how many old regions to add to the CSet (when young gen is fixed) is broken Summary: When refactoring the code for a previous fix, a condition was not correctly negated which prevents the G1 policy from adding the correct number of old regions to the CSet when the young gen size is fixed. The changeset also fixes a small syntactical issue in g1ErgoVerbose.hpp which is causing compiler warnings. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp Changeset: 0a63380c8ac8 Author: iveresov Date: 2011-09-13 16:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0a63380c8ac8 7090069: Java launcher hangs in infinite loop on windows when UseNUMA[Interleaving] is specified Summary: Fix _numa_used_node_list array size specification Reviewed-by: kvn, johnc, jmasa, ysr ! src/os/windows/vm/os_windows.cpp Changeset: f94227b6117b Author: kvn Date: 2011-09-13 20:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f94227b6117b 7090259: Fix hotspot sources to build with old compilers Summary: Fixed warnings which prevent building VM with old compilers. Reviewed-by: never ! make/solaris/makefiles/sparcWorks.make ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/block.cpp Changeset: 8ed53447f690 Author: iveresov Date: 2011-09-15 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8ed53447f690 Merge - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java ! src/share/vm/classfile/javaClasses.cpp Changeset: 0db80d8e77fc Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0db80d8e77fc Added tag jdk8-b05 for changeset dce7d24674f4 ! .hgtags Changeset: 558f525a6ebe Author: jcoomes Date: 2011-09-15 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/558f525a6ebe Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 8ab2f4108d20 Author: jcoomes Date: 2011-09-15 20:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8ab2f4108d20 7091294: disable quicksort tests Reviewed-by: jmasa, ysr, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 650d15d8f372 Author: jcoomes Date: 2011-09-15 20:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/650d15d8f372 7091255: Bump the hs22 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5a3c2bc614ca Author: jcoomes Date: 2011-09-15 20:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5a3c2bc614ca Added tag hs22-b06 for changeset 650d15d8f372 ! .hgtags From vladimir.kozlov at oracle.com Fri Sep 16 15:27:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Sep 2011 15:27:08 -0700 Subject: Request for reviews (S): 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded In-Reply-To: <6BA8611B-B5BF-4DFE-9D4C-152F6DF97EAA@oracle.com> References: <4E73A6B8.8010305@oracle.com> <6BA8611B-B5BF-4DFE-9D4C-152F6DF97EAA@oracle.com> Message-ID: <4E73CD3C.2080703@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > On Sep 16, 2011, at 12:42 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7081842/webrev >> >> 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded >> >> URLHammerThread::run (2785 bytes) method's code looks like spaghetti. It has loops, recursive and deep inplining. I see in LogCompilation that up to 70K ideal nodes are created during compilation. And the test passed with -XX:MaxNodeLimit=100000. So we simply missing node limit check in IGVN optimizer which is added. > > That looks ok to me. We may want to reconsider some of these C->unique bailouts since they don't address the number of nodes that are actually live which is the problematic number. Some things we do generate a lot of garbage nodes that don't contribute to the final code size. This is good for now though. > > tom > >> I also did some changes to LogCompilation parser which helped me: >> - added time stamp and nodes count (from parse_done event) to inlining output: >> @ 147 java.util.ArrayList::get (11 bytes) (end time: 7.1010 nodes: 1127) >> >> - stat output for phases prints starting and added nodes counts: >> optimizer 0.0030 545 497 >> matcher 0.0000 1042 -335 >> regalloc 0.0060 965 225 >> >> - ignore jvms for eliminate_allocation and eliminate_lock events instead of printing error. >> >> And I fixed linux/build.sh (which only I use, it seems) to build on x64 linux machines. >> >> Thanks, >> Vladimir > From forax at univ-mlv.fr Sat Sep 17 02:33:10 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 17 Sep 2011 11:33:10 +0200 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: Message-ID: <4E746956.6070901@univ-mlv.fr> Hi Christian, hi all, I understand that you need such kind of logic but I think it's not compatible with the approach taken by Mark Roos i.e flush all callsites if more than a predefined number of callsites have installed an inlining cache. A possible solution is to add a way in the API to know if a callsite will trigger a deoptimization if the target changes. R?mi On 09/16/2011 02:02 PM, Christian Thalinger wrote: > [This change will be pushed after 7087357. So ignore the code removal in src/share/vm/classfile/javaClasses.cpp.] > > http://cr.openjdk.java.net/~twisti/7087838/ > > 7087838: JSR 292: add throttling logic for optimistic call site optimizations > Reviewed-by: > > The optimistic optimization for MutableCallSite and VolatileCallSite > invalidate compiled methods on every setTarget. This possibly results > in a recompile. For ever-changing call sites this is a performance > hit. > > The fix is to add some throttling logic that prevents the optimistic > optimization after a specified amount of invalidations per CallSite > object. > > This change also moves the flush_dependents_on methods from Universe > to CodeCache. > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/ci/ciCallSite.cpp > src/share/vm/ci/ciCallSite.hpp > src/share/vm/classfile/javaClasses.cpp > src/share/vm/classfile/javaClasses.hpp > src/share/vm/classfile/systemDictionary.cpp > src/share/vm/classfile/vmSymbols.hpp > src/share/vm/code/codeCache.cpp > src/share/vm/code/codeCache.hpp > src/share/vm/code/dependencies.cpp > src/share/vm/code/dependencies.hpp > src/share/vm/memory/universe.cpp > src/share/vm/memory/universe.hpp > src/share/vm/oops/methodOop.cpp > src/share/vm/opto/callGenerator.cpp > src/share/vm/opto/memnode.cpp > src/share/vm/prims/jvmtiRedefineClasses.cpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/runtime/globals.hpp > From igor.veresov at oracle.com Sat Sep 17 04:29:56 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 17 Sep 2011 04:29:56 -0700 Subject: review(S): 7091764: Tiered: enable aastore profiling Message-ID: <96FAD035EAE34B098E70AF5FFC2ECE41@oracle.com> While implementing checkcast/instanceof/aastore profiling in 6919069 I somehow forgot to enable aastore profiling. The assembly is already there, it just needs to be enabled. Webrev: http://cr.openjdk.java.net/~iveresov/7091764/webrev.00/ Thanks! igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110917/0d72c91c/attachment.html From john.r.rose at oracle.com Sat Sep 17 17:58:49 2011 From: john.r.rose at oracle.com (John Rose) Date: Sat, 17 Sep 2011 17:58:49 -0700 Subject: review(S): 7091764: Tiered: enable aastore profiling In-Reply-To: <96FAD035EAE34B098E70AF5FFC2ECE41@oracle.com> References: <96FAD035EAE34B098E70AF5FFC2ECE41@oracle.com> Message-ID: <89F5E6A9-A36E-4669-BA20-9CBD21A81F94@oracle.com> Looks good. -- John On Sep 17, 2011, at 4:29 AM, Igor Veresov wrote: > While implementing checkcast/instanceof/aastore profiling in 6919069 I somehow forgot to enable aastore profiling. The assembly is already there, it just needs to be enabled. > > Webrev: http://cr.openjdk.java.net/~iveresov/7091764/webrev.00/ > > Thanks! > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110917/b5362266/attachment.html From sebastian.sickelmann at gmx.de Sun Sep 18 09:41:37 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sun, 18 Sep 2011 18:41:37 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic Message-ID: <20110918164137.218960@gmx.net> Hi, i think i send this to the wrong list(hotspot-runtime-dev). Now posting it here: Hi, while doing further investigations on my idea [0] i observed a reproducable crash of the vm. It seems to me that it happens while the hotspot tries to inline (i think) a invokedynamic call. It happens only in my second Testcases (a case where an exception is thrown) so i tried to reduce it to a smaller amount of classes. I reduces the example of my idea to some core classes which i packed to [1]. You can run the example starting the Main class. If you start it with -Xint no crash happens. I have packed it with the java-source or with disassembled classfile for the invokedynamic call. What is the Programm doing? Main starts TestNew2.testIt() 20000 times and prints out the thrown exception every time. TestNew2 is a generated class which does something like(just with out the local variable): NEW2 o = new NEW2(); Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] // Which is effective cause = o.getCause(); System.out.println(cause); Throwable newCause = new RuntimeException("NEW"); INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] // Which is effective o.initCause(newCause) which throws the exception that is catched by Main. The Binding is done via the Bootstrapper class. It looks up if the field "NEW2.cause" can be accessed by TestNew2 which isn't the case and binds the two calls to the methods NEW2.getCause and NEW2.initCause. I have checked it with java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) i have put my hs_err_pid.log here [2]. maybe b127 this is not the newest, but i didn't found a newer one. Maybe its the same problem as the porter-stemmer (don't interested me much till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't solve it. I have cross-checked it also with my local openjdk8 builds. The builds are complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev 28cf2aec4dd7 and even if i don't think it's a hotspot problem i checked it also against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ rev 75d763111eec I am not 100% sure if the error is on my side or if it is on the vm, maybe i have done something wrong with the invokedynamic. But i think it is inside hotspot because hotspot / interpreted-mode should work the same way, isn't it? Please let me know if i can make further experiments that helps to isolate/solve this problem. -- Sebastian Sorry if the oss-patches.24.eu isn't as stable as it should be but this my only free webspace i have for this actually. [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar [2] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de From christian.thalinger at oracle.com Mon Sep 19 02:31:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Sep 2011 11:31:14 +0200 Subject: review(S): 7091764: Tiered: enable aastore profiling In-Reply-To: <96FAD035EAE34B098E70AF5FFC2ECE41@oracle.com> References: <96FAD035EAE34B098E70AF5FFC2ECE41@oracle.com> Message-ID: Looks good. -- Christian On Sep 17, 2011, at 1:29 PM, Igor Veresov wrote: > While implementing checkcast/instanceof/aastore profiling in 6919069 I somehow forgot to enable aastore profiling. The assembly is already there, it just needs to be enabled. > > Webrev: http://cr.openjdk.java.net/~iveresov/7091764/webrev.00/ > > Thanks! > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110919/8a33deb2/attachment.html From igor.veresov at oracle.com Mon Sep 19 08:05:52 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 19 Sep 2011 08:05:52 -0700 Subject: review(S): 7091764: Tiered: enable aastore profiling In-Reply-To: References: <96FAD035EAE34B098E70AF5FFC2ECE41@oracle.com> Message-ID: Thanks John and Christian! igor On Monday, September 19, 2011 at 2:31 AM, Christian Thalinger wrote: > Looks good. -- Christian > > On Sep 17, 2011, at 1:29 PM, Igor Veresov wrote: > > While implementing checkcast/instanceof/aastore profiling in 6919069 I somehow forgot to enable aastore profiling. The assembly is already there, it just needs to be enabled. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7091764/webrev.00/ > > > > Thanks! > > igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110919/26e73310/attachment.html From john.r.rose at oracle.com Mon Sep 19 14:58:15 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 14:58:15 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow Message-ID: http://cr.openjdk.java.net/~jrose/7030453/webrev.00 The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. - It does not lock the root WeakHashMap, which can cause a race condition the first time a class is encountered. - It relies on internal details of WeakHashMap to avoid other race conditions. The new implementation uses a concurrently readable cache per Class object with entry versioning to manage lookups. It is more correct and scalable. The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by looking at the behavior of artificial workloads. Experience with real workloads will probably lead to further modifications (under new Change Requests). I thought of making them tunable from JVM command line properties, but since no other class in java.lang does this, I held back. The previous implementation had a store barrier which pushed (via lazySet) pending store values from the user-supplied value before the ClassValue mapping was published. I removed it because it is a false fix for user-caused race conditions. (False because it has the desired effect only on some platforms.) I think it is better to put that issue back onto the user. We still need a memory fence API to give users the right hook for such problems. There is a package-private change to java.lang.Class, adding two new fields (to the existing 19 fields declared in Class.java). Although this class is in java.lang, it is part of JSR 292. Therefore the review comments will be collected in mlvm-dev. The review request is CC-ed to hotspot-compiler (where JSR 292 changes are pushed) and core-libs (which is responsible for java.lang). -- John From john.r.rose at oracle.com Mon Sep 19 15:09:49 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 15:09:49 -0700 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Message-ID: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init http://cr.openjdk.java.net/~jrose/7077803/webrev.00 Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. -- John From john.r.rose at oracle.com Mon Sep 19 15:57:26 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 19 Sep 2011 22:57:26 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7082631: JSR 292: need profiling support in GWTs Message-ID: <20110919225758.B1FBE477EB@hg.openjdk.java.net> Changeset: 3b59f4bc8046 Author: never Date: 2011-09-07 21:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b59f4bc8046 7082631: JSR 292: need profiling support in GWTs Summary: add CountingMethodHandle Reviewed-by: twisti, jrose ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java + src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java From tom.rodriguez at oracle.com Mon Sep 19 18:02:55 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 19 Sep 2011 18:02:55 -0700 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init In-Reply-To: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> References: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> Message-ID: Looks good. tom On Sep 19, 2011, at 3:09 PM, John Rose wrote: > 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init > http://cr.openjdk.java.net/~jrose/7077803/webrev.00 > > Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. > > -- John From john.coomes at oracle.com Mon Sep 19 18:09:35 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 20 Sep 2011 01:09:35 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7091545: hs23 - set hotspot version & build number Message-ID: <20110920010943.52934477F6@hg.openjdk.java.net> Changeset: 77e1a9153757 Author: jcoomes Date: 2011-09-16 21:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/77e1a9153757 7091545: hs23 - set hotspot version & build number Reviewed-by: tonyp, never, phh, jmasa ! make/hotspot_version From rednaxelafx at gmail.com Mon Sep 19 19:00:43 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 20 Sep 2011 10:00:43 +0800 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: Hi John, On Tue, Sep 20, 2011 at 5:58 AM, John Rose wrote: > > The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by > looking at the behavior of artificial workloads. Experience with real > workloads will probably lead to further modifications (under new Change > Requests). I thought of making them tunable from JVM command line > properties, but since no other class in java.lang does this, I held back. FYI, There's one, java.lang.Integer's cache size is tunable via JVM command line flag -XX:AutoBoxCacheMax, which in turn sets Java system property "java.lang.Integer.IntegerCache.high", and affects the Integer cache size. But that's probably a special case anyway. Regards, Kris Mok -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110920/f284fbc7/attachment.html From igor.veresov at oracle.com Mon Sep 19 20:44:40 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 20 Sep 2011 03:44:40 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7091764: Tiered: enable aastore profiling Message-ID: <20110920034448.7C309477FC@hg.openjdk.java.net> Changeset: 5cceda753a4a Author: iveresov Date: 2011-09-19 15:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5cceda753a4a 7091764: Tiered: enable aastore profiling Summary: Turn on aastore profiling Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp From john.r.rose at oracle.com Mon Sep 19 21:21:19 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 21:21:19 -0700 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init In-Reply-To: References: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> Message-ID: Thanks! -- John (on my iPhone) On Sep 19, 2011, at 6:02 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 19, 2011, at 3:09 PM, John Rose wrote: > >> 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init >> http://cr.openjdk.java.net/~jrose/7077803/webrev.00 >> >> Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. >> >> -- John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Mon Sep 19 22:35:06 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 22:35:06 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: On Sep 19, 2011, at 7:00 PM, Krystal Mok wrote: > FYI, There's one, java.lang.Integer's cache size is tunable via JVM command line flag -XX:AutoBoxCacheMax, which in turn sets Java system property "java.lang.Integer.IntegerCache.high", and affects the Integer cache size. But that's probably a special case anyway. Thanks for the reminder, Kris. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110919/d0d29b19/attachment.html From christian.thalinger at oracle.com Tue Sep 20 00:25:11 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 09:25:11 +0200 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init In-Reply-To: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> References: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> Message-ID: <3666F423-2E26-4532-AC37-3FA605ED288F@oracle.com> Looks good. -- Christian On Sep 20, 2011, at 12:09 AM, John Rose wrote: > 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init > http://cr.openjdk.java.net/~jrose/7077803/webrev.00 > > Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. > > -- John From christian.thalinger at oracle.com Tue Sep 20 01:02:49 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 10:02:49 +0200 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: On Sep 19, 2011, at 11:58 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7030453/webrev.00 src/share/classes/java/lang/ClassValue.java: 233 /** Value stream for for hashCodeForCache. See similar structure in ThreadLocal. */ Two for's. 578 * from the ehad of a non-null run, which would allow them "ehad"? Otherwise I think this looks good. -- Christian > > The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: > - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. > - It does not lock the root WeakHashMap, which can cause a race condition the first time a class is encountered. > - It relies on internal details of WeakHashMap to avoid other race conditions. > > The new implementation uses a concurrently readable cache per Class object with entry versioning to manage lookups. It is more correct and scalable. > > The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by looking at the behavior of artificial workloads. Experience with real workloads will probably lead to further modifications (under new Change Requests). I thought of making them tunable from JVM command line properties, but since no other class in java.lang does this, I held back. > > The previous implementation had a store barrier which pushed (via lazySet) pending store values from the user-supplied value before the ClassValue mapping was published. I removed it because it is a false fix for user-caused race conditions. (False because it has the desired effect only on some platforms.) I think it is better to put that issue back onto the user. We still need a memory fence API to give users the right hook for such problems. > > There is a package-private change to java.lang.Class, adding two new fields (to the existing 19 fields declared in Class.java). > > Although this class is in java.lang, it is part of JSR 292. Therefore the review comments will be collected in mlvm-dev. The review request is CC-ed to hotspot-compiler (where JSR 292 changes are pushed) and core-libs (which is responsible for java.lang). > > -- John From tom.rodriguez at oracle.com Tue Sep 20 10:35:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Sep 2011 10:35:02 -0700 Subject: review for 7092236: java/util/EnumSet/EnumSetBash.java fails Message-ID: http://cr.openjdk.java.net/~never/7092236 27 lines changed: 17 ins; 7 del; 3 mod; 1161 unchg 7092236: java/util/EnumSet/EnumSetBash.java fails Reviewed-by: The changes for 7083184 moved an early bailout outside of the guarding test which caused us to skip checking some dependencies when classes are loaded during compilation. The fix is to move it back inside. I also simplified the logic since I found it quite confusing. Tested by failing test from bug report. From christian.thalinger at oracle.com Tue Sep 20 10:46:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 19:46:09 +0200 Subject: review for 7092236: java/util/EnumSet/EnumSetBash.java fails In-Reply-To: References: Message-ID: <51E5F154-A2AD-4EEB-B1E7-794B67C0B76D@oracle.com> Looks good. Thanks for fixing it and the clean up. -- Christian On Sep 20, 2011, at 7:35 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7092236 > 27 lines changed: 17 ins; 7 del; 3 mod; 1161 unchg > > 7092236: java/util/EnumSet/EnumSetBash.java fails > Reviewed-by: > > The changes for 7083184 moved an early bailout outside of the guarding > test which caused us to skip checking some dependencies when classes > are loaded during compilation. The fix is to move it back inside. I > also simplified the logic since I found it quite confusing. Tested by > failing test from bug report. > From vladimir.kozlov at oracle.com Tue Sep 20 10:59:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Sep 2011 10:59:24 -0700 Subject: review for 7092236: java/util/EnumSet/EnumSetBash.java fails In-Reply-To: References: Message-ID: <4E78D47C.6040607@oracle.com> Good. + // other we want to log all the dependences which were ^ otherwise? Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7092236 > 27 lines changed: 17 ins; 7 del; 3 mod; 1161 unchg > > 7092236: java/util/EnumSet/EnumSetBash.java fails > Reviewed-by: > > The changes for 7083184 moved an early bailout outside of the guarding > test which caused us to skip checking some dependencies when classes > are loaded during compilation. The fix is to move it back inside. I > also simplified the logic since I found it quite confusing. Tested by > failing test from bug report. > From tom.rodriguez at oracle.com Tue Sep 20 11:12:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Sep 2011 11:12:59 -0700 Subject: review for 7092236: java/util/EnumSet/EnumSetBash.java fails In-Reply-To: <51E5F154-A2AD-4EEB-B1E7-794B67C0B76D@oracle.com> References: <51E5F154-A2AD-4EEB-B1E7-794B67C0B76D@oracle.com> Message-ID: Thanks! tom On Sep 20, 2011, at 10:46 AM, Christian Thalinger wrote: > Looks good. Thanks for fixing it and the clean up. > > -- Christian > > On Sep 20, 2011, at 7:35 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7092236 >> 27 lines changed: 17 ins; 7 del; 3 mod; 1161 unchg >> >> 7092236: java/util/EnumSet/EnumSetBash.java fails >> Reviewed-by: >> >> The changes for 7083184 moved an early bailout outside of the guarding >> test which caused us to skip checking some dependencies when classes >> are loaded during compilation. The fix is to move it back inside. I >> also simplified the logic since I found it quite confusing. Tested by >> failing test from bug report. >> > From tom.rodriguez at oracle.com Tue Sep 20 11:13:36 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Sep 2011 11:13:36 -0700 Subject: review for 7092236: java/util/EnumSet/EnumSetBash.java fails In-Reply-To: <4E78D47C.6040607@oracle.com> References: <4E78D47C.6040607@oracle.com> Message-ID: <5BD0BCCE-8539-4847-A0EE-59E6A6B357DC@oracle.com> Fixed. Thanks. tom On Sep 20, 2011, at 10:59 AM, Vladimir Kozlov wrote: > Good. > > + // other we want to log all the dependences which were > ^ otherwise? > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7092236 >> 27 lines changed: 17 ins; 7 del; 3 mod; 1161 unchg >> 7092236: java/util/EnumSet/EnumSetBash.java fails >> Reviewed-by: >> The changes for 7083184 moved an early bailout outside of the guarding >> test which caused us to skip checking some dependencies when classes >> are loaded during compilation. The fix is to move it back inside. I >> also simplified the logic since I found it quite confusing. Tested by >> failing test from bug report. From john.r.rose at oracle.com Tue Sep 20 12:50:20 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Sep 2011 12:50:20 -0700 Subject: review for 7092236: java/util/EnumSet/EnumSetBash.java fails In-Reply-To: <51E5F154-A2AD-4EEB-B1E7-794B67C0B76D@oracle.com> References: <51E5F154-A2AD-4EEB-B1E7-794B67C0B76D@oracle.com> Message-ID: <0F91B471-6085-4B6C-918F-CEF36935434F@oracle.com> On Sep 20, 2011, at 10:46 AM, Christian Thalinger wrote: > Looks good. Thanks for fixing it and the clean up. Same here. The original code structure was mine and I like yours better. -- John > -- Christian > > On Sep 20, 2011, at 7:35 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7092236 >> 27 lines changed: 17 ins; 7 del; 3 mod; 1161 unchg >> >> 7092236: java/util/EnumSet/EnumSetBash.java fails >> Reviewed-by: >> >> The changes for 7083184 moved an early bailout outside of the guarding >> test which caused us to skip checking some dependencies when classes >> are loaded during compilation. The fix is to move it back inside. I >> also simplified the logic since I found it quite confusing. Tested by >> failing test from bug report. From john.r.rose at oracle.com Tue Sep 20 16:10:14 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Sep 2011 16:10:14 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> On Sep 19, 2011, at 2:58 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7030453/webrev.00 After some comments from David Holmes (thanks David!) I added internal comments about race conditions. I refreshed the webrev with the additional comments. I also changed one variable to be volatile, with a paragraph of comments explaining why. (The change to volatile will inhibit CSE of ClassValue.get calls, but I think such CSE was unlikely anyway. There should be no other performance effects.) -- John From vladimir.kozlov at oracle.com Tue Sep 20 16:23:00 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 20 Sep 2011 23:23:00 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded Message-ID: <20110920232308.41BD147836@hg.openjdk.java.net> Changeset: 075ea0ed9e7c Author: kvn Date: 2011-09-20 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/075ea0ed9e7c 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded Summary: Add missing node limit check in IGVN optimizer Reviewed-by: iveresov, never ! make/linux/build.sh ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/phaseX.cpp From tom.rodriguez at oracle.com Wed Sep 21 07:39:17 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 21 Sep 2011 14:39:17 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7092236: java/util/EnumSet/EnumSetBash.java fails Message-ID: <20110921143919.D57CD47864@hg.openjdk.java.net> Changeset: eda6988c0d81 Author: never Date: 2011-09-20 23:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eda6988c0d81 7092236: java/util/EnumSet/EnumSetBash.java fails Reviewed-by: kvn, twisti, jrose ! src/share/vm/ci/ciEnv.cpp From christian.thalinger at oracle.com Thu Sep 22 03:23:49 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Sep 2011 12:23:49 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Message-ID: http://cr.openjdk.java.net/~twisti/7092712/ 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: The problem is that ciEnv::get_fake_invokedynamic_method_impl calls get_unloaded_method with java.lang.invoke.MethodHandle as the holder for unresolved call sites. Since the loader of j.l.i.MethodHandle is the boot class loader the resolving of e.g. signature classes is done with the boot class loader resulting in problems like: (dbx) p this->print() this->print() = (void) (dbx) p that->print() that->print() = (void) Later in the game a ciInstanceKlass lookup for NEW2 returns a ciInstanceKlass created during the signature resolving in get_unloaded_method with the boot class loader as loader resulting in the above situation. The fix is to always pass an accessor to get_unloaded_method and subsequently the ciMethod constructor. src/share/vm/ci/ciEnv.cpp src/share/vm/ci/ciEnv.hpp src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciMethod.hpp src/share/vm/ci/ciObjectFactory.cpp src/share/vm/ci/ciObjectFactory.hpp From vladimir.kozlov at oracle.com Thu Sep 22 15:35:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Sep 2011 15:35:18 -0700 Subject: Request for reviews (M): 7081933: Use zeroing elimination optimization for large array Message-ID: <4E7BB826.4090204@oracle.com> http://cr.openjdk.java.net/~kvn/7081933/webrev 7081933: Use zeroing elimination optimization for large array Currently when a new array does not fit into TLAB (big array (FastAllocateSizeLimit) or most common case when no space left in TLAB) C2 calls runtime which does allocation and zeroing. But zeroing is not needed if allocation is followed by arraycopy which initialize it (ReduceBulkZeroing optimization). Add a new runtime call _new_array_nozero_Java for such case and use it only for type arrays since obj arrays have to be initialized if deoptimization happened on the return from RT to compiled code. These changes does not affect refworkload scores (including jbb2005). But crypto.aes (jvm2008) score improved around 10% on sparc. I don't see improvement on x86, may by because it has different crypto code. Added small fix to prefetch code in sparc arraycopy stub. Thanks, Vladimir From christian.thalinger at oracle.com Fri Sep 23 00:55:52 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 23 Sep 2011 09:55:52 +0200 Subject: Request for reviews (M): 7081933: Use zeroing elimination optimization for large array In-Reply-To: <4E7BB826.4090204@oracle.com> References: <4E7BB826.4090204@oracle.com> Message-ID: On Sep 23, 2011, at 12:35 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7081933/webrev > > 7081933: Use zeroing elimination optimization for large array > > Currently when a new array does not fit into TLAB (big array (FastAllocateSizeLimit) or most common case when no space left in TLAB) C2 calls runtime which does allocation and zeroing. But zeroing is not needed if allocation is followed by arraycopy which initialize it (ReduceBulkZeroing optimization). > > Add a new runtime call _new_array_nozero_Java for such case and use it only for type arrays since obj arrays have to be initialized if deoptimization happened on the return from RT to compiled code. > > These changes does not affect refworkload scores (including jbb2005). But > crypto.aes (jvm2008) score improved around 10% on sparc. I don't see improvement on x86, may by because it has different crypto code. > > Added small fix to prefetch code in sparc arraycopy stub. src/share/vm/oops/typeArrayKlass.hpp: ! typeArrayOop allocate_common(int length, bool nozero, TRAPS); + typeArrayOop allocate(int length, TRAPS) { return allocate_common(length, false, THREAD); } I personally would prefer to have the nozero argument inverted (maybe zeroing or do_zeroing): ! typeArrayOop allocate_common(int length, bool do_zeroing, TRAPS); + typeArrayOop allocate(int length, TRAPS) { return allocate_common(length, true, THREAD); } Otherwise this looks good. Nice speedup. -- Christian > > Thanks, > Vladimir From sebastian.sickelmann at gmx.de Fri Sep 23 06:19:31 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 23 Sep 2011 15:19:31 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: References: Message-ID: <4E7C8763.3000101@gmx.de> Am 22.09.2011 12:23, schrieb Christian Thalinger: > http://cr.openjdk.java.net/~twisti/7092712/ > > 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP > Reviewed-by: > > The problem is that ciEnv::get_fake_invokedynamic_method_impl calls > get_unloaded_method with java.lang.invoke.MethodHandle as the holder > for unresolved call sites. > > Since the loader of j.l.i.MethodHandle is the boot class loader the > resolving of e.g. signature classes is done with the boot class loader > resulting in problems like: > > (dbx) p this->print() > this->print() = (void) > (dbx) p that->print() > that->print() = (void) > > Later in the game a ciInstanceKlass lookup for NEW2 returns a > ciInstanceKlass created during the signature resolving in > get_unloaded_method with the boot class loader as loader resulting in > the above situation. > > The fix is to always pass an accessor to get_unloaded_method and > subsequently the ciMethod constructor. > > src/share/vm/ci/ciEnv.cpp > src/share/vm/ci/ciEnv.hpp > src/share/vm/ci/ciMethod.cpp > src/share/vm/ci/ciMethod.hpp > src/share/vm/ci/ciObjectFactory.cpp > src/share/vm/ci/ciObjectFactory.hpp > It fixed it for me on my Testcase with (jdk8). Thanks for that. I can't review it formally (because i don't understand the fix in a complete manner) but should there be an automated test for this? Or is this not a common practice at hotspot-level? Will there be a jdk7 backport? -- Sebastian From vladimir.kozlov at oracle.com Fri Sep 23 08:07:28 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Sep 2011 08:07:28 -0700 Subject: Request for reviews (M): 7081933: Use zeroing elimination optimization for large array In-Reply-To: References: <4E7BB826.4090204@oracle.com> Message-ID: <4E7CA0B0.9090809@oracle.com> Thank you, Christian I will do as you suggested. Thanks, Vladimir On 9/23/11 12:55 AM, Christian Thalinger wrote: > > On Sep 23, 2011, at 12:35 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7081933/webrev >> >> 7081933: Use zeroing elimination optimization for large array >> >> Currently when a new array does not fit into TLAB (big array (FastAllocateSizeLimit) or most common case when no space left in TLAB) C2 calls runtime which does allocation and zeroing. But zeroing is not needed if allocation is followed by arraycopy which initialize it (ReduceBulkZeroing optimization). >> >> Add a new runtime call _new_array_nozero_Java for such case and use it only for type arrays since obj arrays have to be initialized if deoptimization happened on the return from RT to compiled code. >> >> These changes does not affect refworkload scores (including jbb2005). But >> crypto.aes (jvm2008) score improved around 10% on sparc. I don't see improvement on x86, may by because it has different crypto code. >> >> Added small fix to prefetch code in sparc arraycopy stub. > > src/share/vm/oops/typeArrayKlass.hpp: > > ! typeArrayOop allocate_common(int length, bool nozero, TRAPS); > + typeArrayOop allocate(int length, TRAPS) { return allocate_common(length, false, THREAD); } > > I personally would prefer to have the nozero argument inverted (maybe zeroing or do_zeroing): > > ! typeArrayOop allocate_common(int length, bool do_zeroing, TRAPS); > + typeArrayOop allocate(int length, TRAPS) { return allocate_common(length, true, THREAD); } > > Otherwise this looks good. Nice speedup. > > -- Christian > >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Sun Sep 25 19:32:49 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 26 Sep 2011 02:32:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7089790: integrate bsd-port changes Message-ID: <20110926023253.5D7EF479B0@hg.openjdk.java.net> Changeset: f08d439fab8c Author: never Date: 2011-09-25 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f08d439fab8c 7089790: integrate bsd-port changes Reviewed-by: kvn, twisti, jrose Contributed-by: Kurt Miller , Greg Lewis , Jung-uk Kim , Christos Zoulas , Landon Fuller , The FreeBSD Foundation , Michael Franz , Roger Hoover , Alexander Strange ! agent/make/Makefile + agent/src/os/bsd/BsdDebuggerLocal.c + agent/src/os/bsd/Makefile + agent/src/os/bsd/StubDebuggerLocal.c + agent/src/os/bsd/elfmacros.h + agent/src/os/bsd/libproc.h + agent/src/os/bsd/libproc_impl.c + agent/src/os/bsd/libproc_impl.h + agent/src/os/bsd/mapfile + agent/src/os/bsd/ps_core.c + agent/src/os/bsd/ps_proc.c + agent/src/os/bsd/salibelf.c + agent/src/os/bsd/salibelf.h + agent/src/os/bsd/symtab.c + agent/src/os/bsd/symtab.h + agent/src/os/bsd/test.c + agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdOopHandle.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/SharedObject.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64ThreadContext.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdX86JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile + make/bsd/Makefile + make/bsd/README + make/bsd/adlc_updater + make/bsd/build.sh + make/bsd/makefiles/adjust-mflags.sh + make/bsd/makefiles/adlc.make + make/bsd/makefiles/amd64.make + make/bsd/makefiles/arm.make + make/bsd/makefiles/build_vm_def.sh + make/bsd/makefiles/buildtree.make + make/bsd/makefiles/compiler1.make + make/bsd/makefiles/compiler2.make + make/bsd/makefiles/core.make + make/bsd/makefiles/cscope.make + make/bsd/makefiles/debug.make + make/bsd/makefiles/defs.make + make/bsd/makefiles/dtrace.make + make/bsd/makefiles/fastdebug.make + make/bsd/makefiles/gcc.make + make/bsd/makefiles/hp.make + make/bsd/makefiles/hp1.make + make/bsd/makefiles/i486.make + make/bsd/makefiles/ia64.make + make/bsd/makefiles/jsig.make + make/bsd/makefiles/jvmg.make + make/bsd/makefiles/jvmti.make + make/bsd/makefiles/launcher.make + make/bsd/makefiles/mapfile-vers-debug + make/bsd/makefiles/mapfile-vers-jsig + make/bsd/makefiles/mapfile-vers-product + make/bsd/makefiles/optimized.make + make/bsd/makefiles/ppc.make + make/bsd/makefiles/product.make + make/bsd/makefiles/profiled.make + make/bsd/makefiles/rules.make + make/bsd/makefiles/sa.make + make/bsd/makefiles/saproc.make + make/bsd/makefiles/shark.make + make/bsd/makefiles/sparc.make + make/bsd/makefiles/sparcWorks.make + make/bsd/makefiles/sparcv9.make + make/bsd/makefiles/tiered.make + make/bsd/makefiles/top.make + make/bsd/makefiles/vm.make + make/bsd/makefiles/zero.make + make/bsd/makefiles/zeroshark.make + make/bsd/platform_amd64 + make/bsd/platform_amd64.suncc + make/bsd/platform_i486 + make/bsd/platform_i486.suncc + make/bsd/platform_ia64 + make/bsd/platform_sparc + make/bsd/platform_sparcv9 + make/bsd/platform_zero.in ! make/cscope.make ! make/defs.make ! make/linux/makefiles/arm.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/ppc.make ! make/sa.files ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make ! src/cpu/x86/vm/bytes_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/copy_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/zero/vm/bytes_zero.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/cpu/zero/vm/vm_version_zero.cpp + src/os/bsd/vm/attachListener_bsd.cpp + src/os/bsd/vm/c1_globals_bsd.hpp + src/os/bsd/vm/c2_globals_bsd.hpp + src/os/bsd/vm/chaitin_bsd.cpp + src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/dtraceJSDT_bsd.cpp + src/os/bsd/vm/globals_bsd.hpp + src/os/bsd/vm/interfaceSupport_bsd.hpp + src/os/bsd/vm/jsig.c + src/os/bsd/vm/jvm_bsd.cpp + src/os/bsd/vm/jvm_bsd.h + src/os/bsd/vm/mutex_bsd.cpp + src/os/bsd/vm/mutex_bsd.inline.hpp + src/os/bsd/vm/osThread_bsd.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/bsd/vm/os_share_bsd.hpp + src/os/bsd/vm/perfMemory_bsd.cpp + src/os/bsd/vm/stubRoutines_bsd.cpp + src/os/bsd/vm/threadCritical_bsd.cpp + src/os/bsd/vm/thread_bsd.inline.hpp + src/os/bsd/vm/vmError_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script + src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/bsd_x86_32.ad + src/os_cpu/bsd_x86/vm/bsd_x86_32.s + src/os_cpu/bsd_x86/vm/bsd_x86_64.ad + src/os_cpu/bsd_x86/vm/bsd_x86_64.s + src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/copy_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/prefetch_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vm_version_bsd_x86.cpp + src/os_cpu/bsd_zero/vm/assembler_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/prefetch_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vm_version_bsd_zero.cpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/share/vm/adlc/adlc.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/safepoint.cpp ! 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/threadLocalStorage.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/workgroup.hpp ! test/Makefile ! test/jprt.config ! test/runtime/6929067/Test6929067.sh From tom.rodriguez at ORACLE.COM Mon Sep 26 16:03:41 2011 From: tom.rodriguez at ORACLE.COM (Tom Rodriguez) Date: Mon, 26 Sep 2011 16:03:41 -0700 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: References: Message-ID: Looks good. tom On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7092712/ > > 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP > Reviewed-by: > > The problem is that ciEnv::get_fake_invokedynamic_method_impl calls > get_unloaded_method with java.lang.invoke.MethodHandle as the holder > for unresolved call sites. > > Since the loader of j.l.i.MethodHandle is the boot class loader the > resolving of e.g. signature classes is done with the boot class loader > resulting in problems like: > > (dbx) p this->print() > this->print() = (void) > (dbx) p that->print() > that->print() = (void) > > Later in the game a ciInstanceKlass lookup for NEW2 returns a > ciInstanceKlass created during the signature resolving in > get_unloaded_method with the boot class loader as loader resulting in > the above situation. > > The fix is to always pass an accessor to get_unloaded_method and > subsequently the ciMethod constructor. > > src/share/vm/ci/ciEnv.cpp > src/share/vm/ci/ciEnv.hpp > src/share/vm/ci/ciMethod.cpp > src/share/vm/ci/ciMethod.hpp > src/share/vm/ci/ciObjectFactory.cpp > src/share/vm/ci/ciObjectFactory.hpp > From vladimir.kozlov at oracle.com Mon Sep 26 16:52:41 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 26 Sep 2011 23:52:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7081933: Use zeroing elimination optimization for large array Message-ID: <20110926235246.22A18479ED@hg.openjdk.java.net> Changeset: a92cdbac8b9e Author: kvn Date: 2011-09-26 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a92cdbac8b9e 7081933: Use zeroing elimination optimization for large array Summary: Don't zero new typeArray during runtime call if the allocation is followed by arraycopy into it. Reviewed-by: twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp From volker.simonis at gmail.com Wed Sep 28 02:22:31 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Sep 2011 11:22:31 +0200 Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error In-Reply-To: References: <4E2DA45B.6040807@oracle.com> <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> <4E2DB3B4.6040007@oracle.com> Message-ID: The following request for review somehow got lost in the summer holidays. I would need one additional reviewer and somebody who would be so kind to actually submit the change once it was reviewed. Thank you and best regards, Volker On Tue, Jul 26, 2011 at 7:20 PM, Volker Simonis wrote: > Hi, > > I've made "original_exception" a Handle as suggested by Keith. Here's > the new webrev: > > http://www.progdoc.de/webrev/6865265.v2 > > Regarding Keith' comments about the verification process: he's right, > 'VerificationType::is_reference_assignable_from()' loads both > references with the same class loader (the initiating one in this > case). Initially I though that verifying if an Exception class in the > class file's exception table is "java.lang.Throwable" only by name may > be not enough, because a custom system class loader could load a bogus > Throwable class which is different from the one loaded by the boot > class loader. But I've just verified that such a scenario is > prohibited by 'ClassLoader.defineClass()' which is final and rejects > the loading of classes from the 'java.' package. > > Regards, > Volker > > On Mon, Jul 25, 2011 at 8:19 PM, Vladimir Kozlov > wrote: >> Resending to all. >> >> Keith McGuigan wrote: >>> >>> I think the code looks ok, but why not use a Handle for the >>> "original_exception" in runtime.cpp -- then you don't need to worry about >>> the GC case either. >>> >>> As to the question about the verifier comparing by name, this is correct >>> (in that this is what the verifier spec requires, IIRC), but intuitively it >>> makes sense anyway because the class's current class loader is the >>> initiating loader for any referenced class that might need to be loaded. >>> ?Thus two different references to classes with the same name will always >>> resolve to the same class implementation so a system dictionary lookup is >>> unnecessary. ?The verifier actively attempts to NOT load or initialize >>> classes when it can, but in some cases it must, unfortunately. >>> >>> -- >>> - Keith >>> >>> >>> On Jul 25, 2011, at 1:14 PM, Vladimir Kozlov wrote: >>> >>>> Forwarding to RT since runtime code is also involved. >>>> >>>> Vladimir >>>> >>>> -------- Original Message -------- >>>> Subject: Request for review (S): 6865265 JVM crashes with "missing >>>> exception handler" error >>>> Date: Mon, 25 Jul 2011 18:58:58 +0200 >>>> From: Volker Simonis >>>> To: hotspot compiler >>>> >>>> Although I've found a tiny test case for 6865265 and a small fix for >>>> the problem, I'm still not sure if my fix is complete. >>>> >>>> I would appreciate it very much if somebody could review my (somewhat >>>> lengthy) explanation for the fix and answer the two questions I >>>> encountered. >>>> Both, the explanation of the fix and the questions are in the webrev at: >>>> >>>> http://www.progdoc.de/webrev/6865265/ >>>> >>>> Regards, >>>> Volker >>> >> > From tom.rodriguez at oracle.com Wed Sep 28 08:56:00 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 Sep 2011 08:56:00 -0700 Subject: review for 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Message-ID: http://cr.openjdk.java.net/~never/7092278 131 lines changed: 101 ins; 9 del; 21 mod; 5998 unchg 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Reviewed-by: There's was a mismatch between using scaled and unscaled indexes to refer to fields in the SA because I hadn't completly hidden access to the fields. I also added proper support for reading the internal field names though that's currently not need for these tests. Tested with tmtools suite, including the failing test. From vladimir.kozlov at oracle.com Wed Sep 28 09:27:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Sep 2011 09:27:21 -0700 Subject: review for 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" In-Reply-To: References: Message-ID: <4E834AE9.3090303@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7092278 > 131 lines changed: 101 ins; 9 del; 21 mod; 5998 unchg > > 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" > Reviewed-by: > > There's was a mismatch between using scaled and unscaled indexes to > refer to fields in the SA because I hadn't completly hidden access to > the fields. I also added proper support for reading the internal > field names though that's currently not need for these tests. Tested > with tmtools suite, including the failing test. > From roland.westrelin at oracle.com Wed Sep 28 09:29:17 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 28 Sep 2011 18:29:17 +0200 Subject: review request(XS): 7096010 c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used Message-ID: http://cr.openjdk.java.net/~roland/7096010/webrev.00/ For $constanttablebase, st->print("%s") is called without an argument. Roland. From tom.rodriguez at oracle.com Wed Sep 28 09:44:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 Sep 2011 09:44:04 -0700 Subject: review request(XS): 7096010 c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used In-Reply-To: References: Message-ID: <59E2AF2E-D65E-4EF4-93E5-7BC37D7F3208@oracle.com> On Sep 28, 2011, at 9:29 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7096010/webrev.00/ > > For $constanttablebase, st->print("%s") is called without an argument. Can you add 4 spaces at the beginning too so the final output is aligned? Looks good. tom > > Roland. From tom.rodriguez at oracle.com Wed Sep 28 13:56:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 Sep 2011 13:56:41 -0700 Subject: review for 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" In-Reply-To: <4E834AE9.3090303@oracle.com> References: <4E834AE9.3090303@oracle.com> Message-ID: <204E30D0-27F3-405E-8739-C172AC892FD0@oracle.com> It was pointed out to me that the vmSymbols changes were incomplete. There aren't currently exercised, so I added a little logic to iterate them when the InstanceKlass is constructed. This exposed another issue where getAllFieldsCount() wasn't being scaled properly. It all works now. tom On Sep 28, 2011, at 9:27 AM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7092278 >> 131 lines changed: 101 ins; 9 del; 21 mod; 5998 unchg >> 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" >> Reviewed-by: >> There's was a mismatch between using scaled and unscaled indexes to >> refer to fields in the SA because I hadn't completly hidden access to >> the fields. I also added proper support for reading the internal >> field names though that's currently not need for these tests. Tested >> with tmtools suite, including the failing test. From vladimir.kozlov at oracle.com Wed Sep 28 14:24:07 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Sep 2011 14:24:07 -0700 Subject: review for 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" In-Reply-To: <204E30D0-27F3-405E-8739-C172AC892FD0@oracle.com> References: <4E834AE9.3090303@oracle.com> <204E30D0-27F3-405E-8739-C172AC892FD0@oracle.com> Message-ID: <4E839077.80407@oracle.com> You missed an other unused fields local: 868 private Field newField(int index) { 869 TypeArray fields = getFields(); otherwise looks good. Vladimir Tom Rodriguez wrote: > It was pointed out to me that the vmSymbols changes were incomplete. There aren't currently exercised, so I added a little logic to iterate them when the InstanceKlass is constructed. This exposed another issue where getAllFieldsCount() wasn't being scaled properly. It all works now. > > tom > > On Sep 28, 2011, at 9:27 AM, Vladimir Kozlov wrote: > >> Good. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7092278 >>> 131 lines changed: 101 ins; 9 del; 21 mod; 5998 unchg >>> 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" >>> Reviewed-by: >>> There's was a mismatch between using scaled and unscaled indexes to >>> refer to fields in the SA because I hadn't completly hidden access to >>> the fields. I also added proper support for reading the internal >>> field names though that's currently not need for these tests. Tested >>> with tmtools suite, including the failing test. > From tom.rodriguez at oracle.com Wed Sep 28 14:28:17 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 Sep 2011 14:28:17 -0700 Subject: review for 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" In-Reply-To: <4E839077.80407@oracle.com> References: <4E834AE9.3090303@oracle.com> <204E30D0-27F3-405E-8739-C172AC892FD0@oracle.com> <4E839077.80407@oracle.com> Message-ID: Fixed. Thanks! tom On Sep 28, 2011, at 2:24 PM, Vladimir Kozlov wrote: > You missed an other unused fields local: > > 868 private Field newField(int index) { > 869 TypeArray fields = getFields(); > > otherwise looks good. > > Vladimir > > Tom Rodriguez wrote: >> It was pointed out to me that the vmSymbols changes were incomplete. There aren't currently exercised, so I added a little logic to iterate them when the InstanceKlass is constructed. This exposed another issue where getAllFieldsCount() wasn't being scaled properly. It all works now. >> tom >> On Sep 28, 2011, at 9:27 AM, Vladimir Kozlov wrote: >>> Good. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7092278 >>>> 131 lines changed: 101 ins; 9 del; 21 mod; 5998 unchg >>>> 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" >>>> Reviewed-by: >>>> There's was a mismatch between using scaled and unscaled indexes to >>>> refer to fields in the SA because I hadn't completly hidden access to >>>> the fields. I also added proper support for reading the internal >>>> field names though that's currently not need for these tests. Tested >>>> with tmtools suite, including the failing test. From john.r.rose at oracle.com Wed Sep 28 18:44:48 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Sep 2011 18:44:48 -0700 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: References: Message-ID: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7092712/ > > ... > > The fix is to always pass an accessor to get_unloaded_method and > subsequently the ciMethod constructor. There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. I think you need to match the accessor argument in the matching loop of get_unloaded_method. Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). I think Option 1 is more precise, but Option 2 might be a more conservative change. (This unloaded method concept is very tricky, even kludgey.) -- John From tom.rodriguez at oracle.com Thu Sep 29 13:23:29 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 29 Sep 2011 20:23:29 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Message-ID: <20110929202332.A223B47A9F@hg.openjdk.java.net> Changeset: cb315dc80374 Author: never Date: 2011-09-29 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cb315dc80374 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/vmStructs.cpp From tom.rodriguez at oracle.com Thu Sep 29 16:26:38 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 29 Sep 2011 23:26:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7096016: SA build still produces "arg list too long" errors Message-ID: <20110929232640.E128447AAE@hg.openjdk.java.net> Changeset: 098acdf97f09 Author: never Date: 2011-09-29 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/098acdf97f09 7096016: SA build still produces "arg list too long" errors Reviewed-by: kvn, never Contributed-by: volker.simonis at gmail.com ! make/linux/makefiles/sa.make ! make/sa.files ! make/solaris/makefiles/sa.make ! make/windows/makefiles/sa.make From igor.veresov at oracle.com Thu Sep 29 17:15:12 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 29 Sep 2011 17:15:12 -0700 Subject: review(XS): 7096639: Tiered: Incorrect counter overflow handling for inlined methods Message-ID: Currently inlined methods at compile levels 2 and 3 never generate invocation events (only back branch events). This could lead to unhandled invocation counter overflows in case an inlinee is never called as a separate method. The fix is to call back into the runtime to report the inlinee invocation event but do so very infrequently, since we only need this to handle overflows rather than drive the policy. Webrev: http://cr.openjdk.java.net/~iveresov/7096639/webrev.00/ igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110929/44bc366e/attachment.html From vladimir.kozlov at oracle.com Thu Sep 29 17:49:49 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Sep 2011 17:49:49 -0700 Subject: review(XS): 7096639: Tiered: Incorrect counter overflow handling for inlined methods In-Reply-To: References: Message-ID: <4E85122D.8050100@oracle.com> Seems good. Vladimir Igor Veresov wrote: > Currently inlined methods at compile levels 2 and 3 never generate > invocation events (only back branch events). This could lead to > unhandled invocation counter overflows in case an inlinee is never > called as a separate method. The fix is to call back into the runtime to > report the inlinee invocation event but do so very infrequently, since > we only need this to handle overflows rather than drive the policy. > > Webrev: http://cr.openjdk.java.net/~iveresov/7096639/webrev.00/ > > igor From igor.veresov at oracle.com Fri Sep 30 01:30:48 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 30 Sep 2011 08:30:48 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7096639: Tiered: Incorrect counter overflow handling for inlined methods Message-ID: <20110930083052.1C9F047ACE@hg.openjdk.java.net> Changeset: dc45ae774613 Author: iveresov Date: 2011-09-29 23:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dc45ae774613 7096639: Tiered: Incorrect counter overflow handling for inlined methods Summary: Enable invocation events for inlinees Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/globals.hpp From roland.westrelin at oracle.com Fri Sep 30 07:37:05 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Fri, 30 Sep 2011 14:37:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7096010: c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used Message-ID: <20110930143709.713B347ADE@hg.openjdk.java.net> Changeset: ae839d1e7d4c Author: roland Date: 2011-09-30 13:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ae839d1e7d4c 7096010: c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used Summary: ADLC generates code to prepare the register string to be printed in a char array but then calls print without the char array as an argument. Reviewed-by: never ! src/share/vm/adlc/formssel.cpp From igor.veresov at oracle.com Fri Sep 30 21:19:58 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 01 Oct 2011 04:19:58 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 4 new changesets Message-ID: <20111001042007.8AD2747B0D@hg.openjdk.java.net> Changeset: da0999c4b733 Author: dcubed Date: 2011-09-16 16:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/da0999c4b733 7071904: 4/4 HotSpot: Full Debug Symbols Summary: Add support for .debuginfo files for HSX libraries. Reviewed-by: poonam, dholmes, never ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile + make/solaris/makefiles/build_vm_def.sh ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/mapfile-vers ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make Changeset: 86cbe939f0c7 Author: dcubed Date: 2011-09-19 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/86cbe939f0c7 Merge Changeset: 3607aac85aa9 Author: kevinw Date: 2011-09-22 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3607aac85aa9 7051189: Need to suppress info message if -xcheck:jni used with libjsig.so Reviewed-by: coleenp, minqi ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp + test/runtime/7051189/Xchecksig.sh Changeset: 5d871c1ff17c Author: iveresov Date: 2011-09-30 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5d871c1ff17c Merge ! make/Makefile ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! src/os/linux/vm/os_linux.cpp