From David.Holmes at Sun.COM Wed Oct 1 02:13:32 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 01 Oct 2008 19:13:32 +1000 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E2C049.2060409@Sun.COM> References: <48E2C049.2060409@Sun.COM> Message-ID: <48E33F3C.5080706@sun.com> My 2c: fix it and add a flag to restore the incorrect behaviour. David Holmes Xiaobin Lu said the following on 10/01/08 10:11: > Hi folks, > > I need your opinion about what we should do to solve the compatibility > issue regarding the active processor count. Basically, the problem is on > Solaris, if you create a processor set and then launch java process > without binding to that processor set, the number of available > processors to that java process is the total number of the online > processors minus the number of processors in the processor set you > created. Currently, we just report the total number of the online > processors as the active processor count which is wrong. This makes the > parallel garbage collector to behave in the wrong way (see bug 6749430 > for details) and we need to fix it per request from CBOE. > > There may be a compatibility issue after we correct this wrong behavior > when someone has already depended on this wrong return, which we think > it might be rare. We definitely need to invent a new flag in order to > address this and the question is whether we should keep the current > behavior as default or not. Personally, I feel we should have that flag > to fall back to the current wrong behavior, but I might be wrong. > > Thanks so much in advance for your opinion. > > -Xiaobin > > > > From Daniel.Daugherty at Sun.COM Wed Oct 1 06:32:48 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Wed, 01 Oct 2008 07:32:48 -0600 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E2C049.2060409@Sun.COM> References: <48E2C049.2060409@Sun.COM> Message-ID: <48E37C00.5080004@sun.com> The default should be the correct behavior and the option should restore the previous incorrect behavior. The hard part will be naming the option. Perhaps: -XX:+UseOnLineProcessorCountAsActiveProcessorCount The description could be something like: Restore incorrect active processor count algorithm for backward compatibility. Just suggestions... Dan Xiaobin Lu wrote: > Hi folks, > > I need your opinion about what we should do to solve the compatibility > issue regarding the active processor count. Basically, the problem is > on Solaris, if you create a processor set and then launch java process > without binding to that processor set, the number of available > processors to that java process is the total number of the online > processors minus the number of processors in the processor set you > created. Currently, we just report the total number of the online > processors as the active processor count which is wrong. This makes > the parallel garbage collector to behave in the wrong way (see bug > 6749430 for details) and we need to fix it per request from CBOE. > > There may be a compatibility issue after we correct this wrong > behavior when someone has already depended on this wrong return, which > we think it might be rare. We definitely need to invent a new flag in > order to address this and the question is whether we should keep the > current behavior as default or not. Personally, I feel we should have > that flag to fall back to the current wrong behavior, but I might be > wrong. > > Thanks so much in advance for your opinion. > > -Xiaobin > > > > From Jon.Masamitsu at Sun.COM Wed Oct 1 06:53:53 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 01 Oct 2008 06:53:53 -0700 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E2C049.2060409@Sun.COM> References: <48E2C049.2060409@Sun.COM> Message-ID: <48E380F1.7030504@Sun.COM> I would vote to have the new value be the default. That's based on the principle of "least surprise". People who need to think about such things probably already believe they are getting the new value. The number of default GC thread for the parallel collector (UseParallelGC) was changed in HSX 12 (hotspot express) to be consistent with the number of default threads used with UseParNewGC/cms (CR 6362677). So there has been a change recently. I'll probably being hearing some complaints about my change (hopefully not many), so I can include the new calculation of the active number of processors too, if relevant, in my explanations. Not sure what else beside GC will be affected by the new calculation of active processors. On 09/30/08 17:11, Xiaobin Lu wrote: > Hi folks, > > I need your opinion about what we should do to solve the compatibility > issue regarding the active processor count. Basically, the problem is on > Solaris, if you create a processor set and then launch java process > without binding to that processor set, the number of available > processors to that java process is the total number of the online > processors minus the number of processors in the processor set you > created. Currently, we just report the total number of the online > processors as the active processor count which is wrong. This makes the > parallel garbage collector to behave in the wrong way (see bug 6749430 > for details) and we need to fix it per request from CBOE. > > There may be a compatibility issue after we correct this wrong behavior > when someone has already depended on this wrong return, which we think > it might be rare. We definitely need to invent a new flag in order to > address this and the question is whether we should keep the current > behavior as default or not. Personally, I feel we should have that flag > to fall back to the current wrong behavior, but I might be wrong. > > Thanks so much in advance for your opinion. > > -Xiaobin > > > > From David.Holmes at Sun.COM Wed Oct 1 07:34:45 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 02 Oct 2008 00:34:45 +1000 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E380F1.7030504@Sun.COM> References: <48E2C049.2060409@Sun.COM> <48E380F1.7030504@Sun.COM> Message-ID: <48E38A85.60608@sun.com> Jon Masamitsu said the following on 10/01/08 23:53: > Not sure what > else beside GC will be affected by the new calculation > of active processors. Inside the VM I can't think of anything but applications also use Runtime.availableProcessors to determine how many applications threads to create (eg. to size a threadpool). David From volker.simonis at gmail.com Wed Oct 1 07:43:54 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Oct 2008 16:43:54 +0200 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E380F1.7030504@Sun.COM> References: <48E2C049.2060409@Sun.COM> <48E380F1.7030504@Sun.COM> Message-ID: os::is_server_class_machine() depends on active_processor_count() although it is not clear if a server class machine (per definition >= 2CPU's) with fewer active CPU's should still act as a server class machine or not... On 10/1/08, Jon Masamitsu wrote: > I would vote to have the new value be the default. That's > based on the principle of "least surprise". People who > need to think about such things probably already believe > they are getting the new value. > > The number of default GC thread for the parallel collector > (UseParallelGC) was changed in HSX 12 (hotspot express) to > be consistent with the number of default threads used with > UseParNewGC/cms (CR 6362677). So there has been a change > recently. I'll probably being hearing some complaints > about my change (hopefully not many), so I can include > the new calculation of the active number of processors > too, if relevant, in my explanations. Not sure what > else beside GC will be affected by the new calculation > of active processors. > > > On 09/30/08 17:11, Xiaobin Lu wrote: > > > Hi folks, > > > > I need your opinion about what we should do to solve the compatibility > issue regarding the active processor count. Basically, the problem is on > Solaris, if you create a processor set and then launch java process without > binding to that processor set, the number of available processors to that > java process is the total number of the online processors minus the number > of processors in the processor set you created. Currently, we just report > the total number of the online processors as the active processor count > which is wrong. This makes the parallel garbage collector to behave in the > wrong way (see bug 6749430 for details) and we need to fix it per request > from CBOE. > > > > There may be a compatibility issue after we correct this wrong behavior > when someone has already depended on this wrong return, which we think it > might be rare. We definitely need to invent a new flag in order to address > this and the question is whether we should keep the current behavior as > default or not. Personally, I feel we should have that flag to fall back to > the current wrong behavior, but I might be wrong. > > > > Thanks so much in advance for your opinion. > > > > -Xiaobin > > > > > > > > > > > From Jon.Masamitsu at Sun.COM Wed Oct 1 08:03:19 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 01 Oct 2008 08:03:19 -0700 Subject: compatibility issue regarding the active processor count In-Reply-To: References: <48E2C049.2060409@Sun.COM> <48E380F1.7030504@Sun.COM> Message-ID: <48E39137.80400@Sun.COM> On 10/01/08 07:43, Volker Simonis wrote: > os::is_server_class_machine() depends on active_processor_count() > although it is not clear if a server class machine (per definition >= > 2CPU's) with fewer active CPU's should still act as a server class > machine or not... I think it would be a definite improvement if is_server_class_machine() saw the fewer cpus and returned false (assuming the new and improved active_processor_count() return 1). > > On 10/1/08, Jon Masamitsu wrote: >> I would vote to have the new value be the default. That's >> based on the principle of "least surprise". People who >> need to think about such things probably already believe >> they are getting the new value. >> >> The number of default GC thread for the parallel collector >> (UseParallelGC) was changed in HSX 12 (hotspot express) to >> be consistent with the number of default threads used with >> UseParNewGC/cms (CR 6362677). So there has been a change >> recently. I'll probably being hearing some complaints >> about my change (hopefully not many), so I can include >> the new calculation of the active number of processors >> too, if relevant, in my explanations. Not sure what >> else beside GC will be affected by the new calculation >> of active processors. >> >> >> On 09/30/08 17:11, Xiaobin Lu wrote: >> >>> Hi folks, >>> >>> I need your opinion about what we should do to solve the compatibility >> issue regarding the active processor count. Basically, the problem is on >> Solaris, if you create a processor set and then launch java process without >> binding to that processor set, the number of available processors to that >> java process is the total number of the online processors minus the number >> of processors in the processor set you created. Currently, we just report >> the total number of the online processors as the active processor count >> which is wrong. This makes the parallel garbage collector to behave in the >> wrong way (see bug 6749430 for details) and we need to fix it per request >> from CBOE. >>> There may be a compatibility issue after we correct this wrong behavior >> when someone has already depended on this wrong return, which we think it >> might be rare. We definitely need to invent a new flag in order to address >> this and the question is whether we should keep the current behavior as >> default or not. Personally, I feel we should have that flag to fall back to >> the current wrong behavior, but I might be wrong. >>> Thanks so much in advance for your opinion. >>> >>> -Xiaobin >>> >>> >>> >>> >>> From Paul.Hohensee at Sun.COM Wed Oct 1 08:15:06 2008 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 01 Oct 2008 11:15:06 -0400 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E33F3C.5080706@sun.com> References: <48E2C049.2060409@Sun.COM> <48E33F3C.5080706@sun.com> Message-ID: <48E393FA.2020800@sun.com> Ditto. paul David Holmes - Sun Microsystems wrote: > My 2c: fix it and add a flag to restore the incorrect behaviour. > > David Holmes > > Xiaobin Lu said the following on 10/01/08 10:11: >> Hi folks, >> >> I need your opinion about what we should do to solve the >> compatibility issue regarding the active processor count. Basically, >> the problem is on Solaris, if you create a processor set and then >> launch java process without binding to that processor set, the number >> of available processors to that java process is the total number of >> the online processors minus the number of processors in the processor >> set you created. Currently, we just report the total number of the >> online processors as the active processor count which is wrong. This >> makes the parallel garbage collector to behave in the wrong way (see >> bug 6749430 for details) and we need to fix it per request from CBOE. >> >> There may be a compatibility issue after we correct this wrong >> behavior when someone has already depended on this wrong return, >> which we think it might be rare. We definitely need to invent a new >> flag in order to address this and the question is whether we should >> keep the current behavior as default or not. Personally, I feel we >> should have that flag to fall back to the current wrong behavior, but >> I might be wrong. >> >> Thanks so much in advance for your opinion. >> >> -Xiaobin >> >> >> >> From chuck.rasbold at sun.com Wed Oct 1 08:31:21 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Wed, 01 Oct 2008 15:31:21 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20081001153137.7E291D828@hg.openjdk.java.net> Changeset: 8261ee795323 Author: rasbold Date: 2008-09-17 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8261ee795323 6711100: 64bit fastdebug server vm crashes with assert(_base == Int,"Not an Int") Summary: insert CastII nodes to narrow type of load_array_length() node Reviewed-by: never, kvn ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6711100/Test.java Changeset: 194b8e3a2fc4 Author: never Date: 2008-09-17 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/194b8e3a2fc4 6384206: Phis which are later unneeded are impairing our ability to inline based on static types Reviewed-by: rasbold, jrose ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciMethodBlocks.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: 36ccc817fca4 Author: kvn Date: 2008-09-23 12:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/36ccc817fca4 6747051: Improve code and implicit null check generation for compressed oops Summary: Push DecodeN node below the Null check to the non-null path to use the mach node without 0 test. Reviewed-by: rasbold, never ! src/share/vm/asm/assembler.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp Changeset: 5f85534046c2 Author: rasbold Date: 2008-09-24 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5f85534046c2 6750588: assert(lrg._area >= 0,"negative spill area") running NSK stmp0101 test Summary: handle NaN costs more carefully Reviewed-by: kvn, never ! src/share/vm/opto/ifg.cpp Changeset: 885fe0f95828 Author: never Date: 2008-09-25 12:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/885fe0f95828 6744783: HotSpot segfaults if given -XX options with an empty string argument Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp Changeset: dbec32712472 Author: never Date: 2008-09-30 11:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dbec32712472 6753795: HotSpot crash in strlen() when JVMTI is used Summary: test for null instead of strlen Reviewed-by: rasbold ! src/share/vm/prims/jvmtiEnvBase.cpp Changeset: be41fa651400 Author: rasbold Date: 2008-09-30 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/be41fa651400 Merge ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp From Xiaobin.Lu at Sun.COM Wed Oct 1 10:38:02 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 01 Oct 2008 10:38:02 -0700 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E37C00.5080004@sun.com> References: <48E2C049.2060409@Sun.COM> <48E37C00.5080004@sun.com> Message-ID: <48E3B57A.1090801@Sun.COM> How about "-XX:+UseOnlinePsrCountAsActivePsrCount"? Thanks to all for the feedbacks. -Xiaobin Daniel D. Daugherty wrote: > The default should be the correct behavior and the option should > restore the previous incorrect behavior. The hard part will be > naming the option. Perhaps: > > -XX:+UseOnLineProcessorCountAsActiveProcessorCount > > The description could be something like: > > Restore incorrect active processor count algorithm for > backward compatibility. > > Just suggestions... > > Dan > > > Xiaobin Lu wrote: >> Hi folks, >> >> I need your opinion about what we should do to solve the >> compatibility issue regarding the active processor count. Basically, >> the problem is on Solaris, if you create a processor set and then >> launch java process without binding to that processor set, the number >> of available processors to that java process is the total number of >> the online processors minus the number of processors in the processor >> set you created. Currently, we just report the total number of the >> online processors as the active processor count which is wrong. This >> makes the parallel garbage collector to behave in the wrong way (see >> bug 6749430 for details) and we need to fix it per request from CBOE. >> >> There may be a compatibility issue after we correct this wrong >> behavior when someone has already depended on this wrong return, >> which we think it might be rare. We definitely need to invent a new >> flag in order to address this and the question is whether we should >> keep the current behavior as default or not. Personally, I feel we >> should have that flag to fall back to the current wrong behavior, but >> I might be wrong. >> >> Thanks so much in advance for your opinion. >> >> -Xiaobin >> >> >> >> From karen.kinnear at sun.com Wed Oct 1 21:02:04 2008 From: karen.kinnear at sun.com (karen.kinnear at sun.com) Date: Thu, 02 Oct 2008 04:02:04 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081002040213.ACB86D9A9@hg.openjdk.java.net> Changeset: e4355b352b7d Author: coleenp Date: 2008-09-26 13:33 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e4355b352b7d 6719149: Wrong "java/lang/String should not be loaded yet" assertion in fastdebug bits with UseStringCache Summary: Assertion is invalid because java.lang.String may be initialized just before this assertion. Reviewed-by: phh ! src/share/vm/runtime/thread.cpp Changeset: 99dd4bbd9eec Author: acorn Date: 2008-09-30 12:24 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/99dd4bbd9eec Merge ! src/share/vm/runtime/thread.cpp Changeset: b7483806cc49 Author: acorn Date: 2008-10-01 20:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b7483806cc49 Merge From antonios.printezis at sun.com Wed Oct 1 16:42:57 2008 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Wed, 01 Oct 2008 23:42:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20081001234310.846CCD8D9@hg.openjdk.java.net> Changeset: 06df86c2ec37 Author: iveresov Date: 2008-09-27 00:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/06df86c2ec37 6740923: NUMA allocator: Ensure the progress of adaptive chunk resizing Summary: Treat a chuck where the allocation has failed as fully used. Reviewed-by: ysr ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp Changeset: a4b729f5b611 Author: jcoomes Date: 2008-09-30 11:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a4b729f5b611 6716466: par compact - remove VerifyParallelOldWithMarkSweep code Reviewed-by: jmasa ! src/share/vm/code/nmethod.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/runtime/globals.hpp Changeset: 81cd571500b0 Author: jcoomes Date: 2008-09-30 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/81cd571500b0 6725697: par compact - rename class ChunkData to RegionData Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 0166ac265d53 Author: jcoomes Date: 2008-09-30 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0166ac265d53 6729594: par compact - remove unused block table implementation Reviewed-by: tonyp, jmasa, apetrusenko ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/runtime/globals.hpp Changeset: ddfad9496151 Author: tonyp Date: 2008-10-01 15:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ddfad9496151 Merge ! src/share/vm/runtime/globals.hpp From daniel.daugherty at sun.com Thu Oct 2 08:47:52 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Thu, 02 Oct 2008 15:47:52 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20081002154806.B5295D9EA@hg.openjdk.java.net> Changeset: 9646293b9637 Author: xdono Date: 2008-09-25 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9646293b9637 Added tag jdk7-b36 for changeset e91159f921a5 ! .hgtags Changeset: 0e31d37915ff Author: trims Date: 2008-10-01 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0e31d37915ff 6754998: Update Hotspot version for hs14 b06 Summary: Bump Hotspot build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: af90fe21c1e3 Author: trims Date: 2008-10-01 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/af90fe21c1e3 Merge Changeset: c005b6eac36e Author: dcubed Date: 2008-10-02 06:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c005b6eac36e Merge From erik.trimble at sun.com Thu Oct 2 10:40:44 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 02 Oct 2008 17:40:44 +0000 Subject: hg: jdk7/hotspot/jdk: 27 new changesets Message-ID: <20081002174704.E758CDA3D@hg.openjdk.java.net> Changeset: 094873a59791 Author: sjiang Date: 2008-09-09 14:17 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/094873a59791 6736611: [Evt Srv] EventSubscriber.unsubscribe removes other listeners Reviewed-by: emcmanus ! src/share/classes/javax/management/event/EventSubscriber.java + test/javax/management/eventService/SubUnsubTest.java Changeset: 1643868af837 Author: emcmanus Date: 2008-09-09 14:57 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1643868af837 6746196: Some JMX classes do not compile with Eclipse compiler Reviewed-by: dfuchs Contributed-by: roman.kennke at aicas.com ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java Changeset: 5778303e2e14 Author: dfuchs Date: 2008-09-09 17:01 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5778303e2e14 6745832: jmx namespaces: Some refactoring/commenting would improve code readability. Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/DispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/DomainDispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/NamespaceDispatchInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java ! src/share/classes/com/sun/jmx/namespace/HandlerInterceptor.java ! src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java ! src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java ! src/share/classes/com/sun/jmx/namespace/RoutingConnectionProxy.java ! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/com/sun/jmx/namespace/RoutingServerProxy.java ! src/share/classes/javax/management/namespace/JMXDomain.java ! src/share/classes/javax/management/namespace/JMXNamespace.java ! src/share/classes/javax/management/namespace/JMXNamespaces.java ! src/share/classes/javax/management/namespace/JMXRemoteNamespace.java ! src/share/classes/javax/management/namespace/MBeanServerConnectionWrapper.java ! test/javax/management/namespace/Wombat.java Changeset: 84417fdd8358 Author: martin Date: 2008-09-09 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/84417fdd8358 6728229: (str) StringBuilder.append(CharSequence) does not throw IndexOutOfBoundsException Summary: Major spec rework Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java Changeset: 12f5110538d3 Author: martin Date: 2008-09-09 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/12f5110538d3 6733145: (bf) CharBuffer.subSequence can be updated to take advantage of covariant returns Summary: Change return type to CharBuffer Reviewed-by: alanb ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/X-Buffer.java Changeset: 2b44dd8ed72d Author: emcmanus Date: 2008-09-10 13:36 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2b44dd8ed72d 6734813: Provide a way to construct an ObjectName without checked exceptions 6746649: ObjectName constructors and methods declare unchecked exceptions in throws clauses Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/javax/management/MBeanServerDelegate.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/QueryNotificationFilter.java ! src/share/classes/javax/management/event/EventClientDelegateMBean.java ! src/share/classes/javax/management/namespace/MBeanServerSupport.java ! src/share/classes/sun/management/Util.java + test/javax/management/ObjectName/ValueOfTest.java Changeset: b35ccd203a7e Author: emcmanus Date: 2008-09-10 14:56 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b35ccd203a7e 6746759: Fix for 6734813 introduced build break Reviewed-by: dfuchs ! src/share/classes/sun/management/ClassLoadingImpl.java ! src/share/classes/sun/management/CompilationImpl.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotInternal.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MemoryImpl.java ! src/share/classes/sun/management/OperatingSystemImpl.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadImpl.java Changeset: 3e7b9a0f3a6f Author: dfuchs Date: 2008-09-10 16:27 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3e7b9a0f3a6f 6746754: jmx namespace: test for leading separator missing 6669137: RFE: InstanceNotFoundException should have a constructor that takes an ObjectName 6746796: jmx namespaces: Several tests are missing an @bug or @run keyword Summary: Note on 6669137: first implementation of 6669137 was actually pushed with 5072476 - here we only have a small update and a test case. Also re-fixes 6737133: Compilation failure of test/javax/management/eventService/LeaseManagerDeadlockTest.java which had failed. Reviewed-by: emcmanus, yjoan ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/javax/management/InstanceNotFoundException.java + test/javax/management/MBeanServer/InstanceNotFoundExceptionTest.java ! test/javax/management/MBeanServerFactory/NamedMBeanServerTest.java ! test/javax/management/eventService/LeaseManagerDeadlockTest.java ! test/javax/management/namespace/DomainCreationTest.java ! test/javax/management/namespace/EventWithNamespaceControlTest.java ! test/javax/management/namespace/EventWithNamespaceTest.java ! test/javax/management/namespace/ExportNamespaceTest.java ! test/javax/management/namespace/JMXDomainTest.java ! test/javax/management/namespace/JMXNamespaceSecurityTest.java ! test/javax/management/namespace/JMXNamespaceTest.java ! test/javax/management/namespace/JMXNamespaceViewTest.java ! test/javax/management/namespace/JMXNamespacesTest.java ! test/javax/management/namespace/JMXRemoteNamespaceTest.java ! test/javax/management/namespace/LazyDomainTest.java + test/javax/management/namespace/LeadingSeparatorsTest.java ! test/javax/management/namespace/NamespaceCreationTest.java ! test/javax/management/namespace/NamespaceNotificationsTest.java ! test/javax/management/namespace/NullObjectNameTest.java ! test/javax/management/namespace/QueryNamesTest.java ! test/javax/management/namespace/RemoveNotificationListenerTest.java ! test/javax/management/namespace/RoutingServerProxyTest.java ! test/javax/management/namespace/SerialParamProcessorTest.java ! test/javax/management/namespace/SourceNamespaceTest.java ! test/javax/management/namespace/VirtualMBeanNotifTest.java ! test/javax/management/namespace/VirtualMBeanTest.java ! test/javax/management/namespace/VirtualNamespaceQueryTest.java ! test/javax/management/namespace/VirtualPropsTest.java Changeset: bee470ba5b24 Author: bristor Date: 2008-09-11 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bee470ba5b24 6440786: Cannot create a ZIP file containing zero entries Summary: Allow reading and writing of ZIP files with zero entries. Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/native/java/util/zip/zip_util.c + test/java/util/zip/TestEmptyZip.java Changeset: ebc38225b4a9 Author: emcmanus Date: 2008-09-12 15:17 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ebc38225b4a9 6747411: EventClient causes thread leaks Summary: Reworked thread management in EventClient and related classes. Reviewed-by: sjiang, dfuchs ! src/share/classes/com/sun/jmx/event/LeaseManager.java ! src/share/classes/com/sun/jmx/event/RepeatedSingletonJob.java ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/FetchingEventRelay.java ! src/share/classes/javax/management/event/RMIPushEventForwarder.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java + test/javax/management/eventService/EventClientThreadTest.java ! test/javax/management/eventService/SharingThreadTest.java Changeset: 6a49dd6635ba Author: dfuchs Date: 2008-09-12 17:58 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6a49dd6635ba 6747899: jmx namespaces: hooks for permission checks should be defined in HandlerInterceptor Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/namespace/HandlerInterceptor.java ! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java Changeset: 09a7e38337e9 Author: dfuchs Date: 2008-09-12 19:06 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/09a7e38337e9 6747983: jmx namespace: unspecified self-link detection logic Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java ! src/share/classes/javax/management/namespace/JMXRemoteNamespace.java ! test/javax/management/namespace/JMXNamespaceTest.java Changeset: def697d44797 Author: tbell Date: 2008-09-12 23:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/def697d44797 Merge Changeset: 044bfa235270 Author: dfuchs Date: 2008-09-17 13:40 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/044bfa235270 6748745: JConsole: plotters don't resize well when the window is resized Summary: part of the fix was contributed by jfdenise Reviewed-by: jfdenise ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java Changeset: eb342082e2b6 Author: jccollet Date: 2008-09-04 15:26 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb342082e2b6 6692802: HttpCookie needs to support HttpOnly attribute Summary: Added HttpOnly tag support to HttpCookie class. Reviewed-by: chegar, michaelm ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: d276b0716d13 Author: wetmore Date: 2008-09-05 00:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d276b0716d13 Merge Changeset: bcb61dfc8514 Author: weijun Date: 2008-09-08 14:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bcb61dfc8514 6740833: krb5.conf does not accept kdc=hostname (no spaces around =) Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Config.java Changeset: b0378bb50d83 Author: michaelm Date: 2008-09-11 17:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b0378bb50d83 6744329: Exception in light weight http server code Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ChunkedOutputStream.java + test/com/sun/net/httpserver/bugs/B6744329.java Changeset: 80fe10573687 Author: mullan Date: 2008-09-11 14:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/80fe10573687 6465942: Add problem identification facility to the CertPathValidator framework Summary: Add support to the java.security.cert APIs for determining the reason that a certification path is invalid. Reviewed-by: vinnie ! src/share/classes/java/security/cert/CertPathValidatorException.java + src/share/classes/java/security/cert/PKIXReason.java ! src/share/classes/sun/security/provider/certpath/BasicChecker.java ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/KeyChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PolicyChecker.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! test/java/security/cert/CertPathValidator/nameConstraintsRFC822/ValidateCertPath.java + test/java/security/cert/CertPathValidatorException/ReasonTest.java + test/java/security/cert/CertPathValidatorException/Serial.java + test/java/security/cert/CertPathValidatorException/cert_file + test/java/security/cert/CertPathValidatorException/jdk6.serial ! test/java/security/cert/PolicyNode/GetPolicyQualifiers.java Changeset: 482a1857b598 Author: mullan Date: 2008-09-11 18:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/482a1857b598 Merge Changeset: 80fd09f239f4 Author: wetmore Date: 2008-09-15 00:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/80fd09f239f4 Merge Changeset: 0100b3e66894 Author: wetmore Date: 2008-09-16 00:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0100b3e66894 Merge Changeset: e81a1ebde376 Author: wetmore Date: 2008-09-18 00:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e81a1ebde376 Merge Changeset: a1ab54c36c8a Author: sjiang Date: 2008-09-22 15:43 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a1ab54c36c8a 6697180: JMX query results in java.io.IOException: Illegal state - also a deadlock can also be seen Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java + test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java Changeset: 4a62773bf60e Author: jjh Date: 2008-09-22 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4a62773bf60e 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race Summary: Have the debuggee stop at a bkpt instead of running to completion. Reviewed-by: tbell ! test/com/sun/jdi/ClassesByName2Test.java Changeset: b54ba7058851 Author: tbell Date: 2008-09-22 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b54ba7058851 Merge Changeset: ed8f850f9f94 Author: tbell Date: 2008-09-26 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ed8f850f9f94 Merge From erik.trimble at sun.com Thu Oct 2 10:53:05 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 02 Oct 2008 17:53:05 +0000 Subject: hg: jdk7/hotspot/langtools: 7 new changesets Message-ID: <20081002175317.89762DA43@hg.openjdk.java.net> Changeset: 91eea580fbe9 Author: jjg Date: 2008-09-09 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/91eea580fbe9 6557752: Original type of an AST should be made available even if it is replaced with an ErrorType 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/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/javax/lang/model/type/ErrorType.java + test/tools/javac/api/6557752/T6557752.java Changeset: a92b756a888f Author: jjg Date: 2008-09-09 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a92b756a888f 6724118: change JavaCompiler to not use Scanner directly 6736119: refactor Parser and Parser.Factory Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Parser.java + src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! test/tools/javac/6304921/TestLog.java Changeset: 7e2249b1c13d Author: tbell Date: 2008-09-12 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7e2249b1c13d Merge Changeset: eff38cc97183 Author: jjg Date: 2008-09-16 18:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/eff38cc97183 6574134: Allow for alternative implementation of Name Table with garbage collection of name bytes Reviewed-by: darcy, mcimadamore ! src/share/classes/com/sun/tools/apt/mirror/AptEnv.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/Name.java + src/share/classes/com/sun/tools/javac/util/Names.java + src/share/classes/com/sun/tools/javac/util/SharedNameTable.java + src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! test/tools/javac/unit/util/convert/EnclosingCandidates.java Changeset: 8ec49685f4e8 Author: jjg Date: 2008-09-18 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8ec49685f4e8 6728697: tools/javac/versionOpt.sh fails on OpenJDK builds Reviewed-by: darcy ! test/Makefile - test/bootclasspath-exclude.jtx + test/tools/javac/VersionOpt.java - test/tools/javac/versionOpt.sh Changeset: 829dea15ff99 Author: jjg Date: 2008-09-18 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/829dea15ff99 6744408: Extra ouput is appearing in stderr Reviewed-by: bpatel ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: 2e3d9966e62b Author: tbell Date: 2008-09-26 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2e3d9966e62b Merge From erik.trimble at sun.com Thu Oct 2 16:12:33 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 02 Oct 2008 23:12:33 +0000 Subject: hg: jdk7/hotspot/hotspot: 6755406: minor mistakes in copyright notices Message-ID: <20081002231237.BF978DA86@hg.openjdk.java.net> Changeset: f1ecf9191140 Author: trims Date: 2008-10-02 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f1ecf9191140 6755406: minor mistakes in copyright notices Summary: Mismatch in some header copyrights from standard templates Reviewed-by: jcoomes ! make/hotspot_distro ! test/compiler/6646019/Test.java ! test/compiler/6689060/Test.java ! test/compiler/6695810/Test.java From Karen.Kinnear at Sun.COM Fri Oct 3 05:59:21 2008 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Fri, 03 Oct 2008 08:59:21 -0400 Subject: CFV: Laurent Daynes as member of the HotSpot Group Message-ID: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> I would like to nominate Laurent Daynes for membership in the HotSpot Group. Laurent works in Sun Labs in Grenoble France. He has extensive experience in HotSpot with a strong background in multitasking and garbage collection. He is currently working on the Maxine VM research project in the labs. Please cast your vote by replying, publicly, to this message with either Vote: yes or Vote: no as the first line of the message body. You may, at your option, indicate the reason for your decision on subsequent lines. Votes must be cast in the open; votes sent as private replies will not be counted. Votes are due by midnight UTC next Friday, October 10th, after which time the votes will be tallied and reported to this list. Only Members of the HotSpot Group are eligible to vote on this decision. The current Members are: Andrei Pangin Andrey Petrusenko Antonios Printezis Chuck Rasbold Coleen Phillimore Chris Phillips Daniel Daugherty Dave Dice David Holmes Erik Trimble Igor Veresov Ivan Krylov James Melvin Jim Holmlund John Coomes John Rose Jon Masamitsu Karen Kinnear Keith McGuigan Kenneth Russell Kevin Walls Lev Serebryakov Paul Hohensee Peter Kessler Stephen Bohne Steve Goldman Thomas Rodriguez Vladimir Kozlov Xiaobin Lu Y S Ramakrishna Yumin Qi -- Karen Kinnear From Keith.McGuigan at Sun.COM Fri Oct 3 06:09:13 2008 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Fri, 03 Oct 2008 09:09:13 -0400 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E61979.6040007@sun.com> Vote: yes Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this decision. > The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From Paul.Hohensee at Sun.COM Fri Oct 3 06:19:45 2008 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 03 Oct 2008 09:19:45 -0400 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E61BF1.5060505@sun.com> Vote: yes Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this > decision. The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From Daniel.Daugherty at Sun.COM Fri Oct 3 06:19:39 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Fri, 03 Oct 2008 07:19:39 -0600 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E61BEB.2070003@sun.com> Vote: yes Dan Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this > decision. The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From Chris.Phillips at Sun.COM Fri Oct 3 06:23:26 2008 From: Chris.Phillips at Sun.COM (Chris Phillips) Date: Fri, 03 Oct 2008 09:23:26 -0400 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E61CCE.9020908@Sun.Com> Vote: yes Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this > decision. The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear -- -- -- Woda: "Java: write once, debug anywhere" Hong Zhang http://thehenrys.ca | Chris Phillips - Sun Java Sustaining JVM Engineer, | | mailto:Chris.Phillips at Sun.Com (416)483-3768 | | http://LGonQn.Org/www/Chris.Phillips cell: (416)505-3610 | "EPIC stands for Expects Perfectly Intuitive Compilers" P. Bannon http://www.hazmatmodine.com NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. "blah blah blah - Ginger!" -- From Chuck.Rasbold at Sun.COM Fri Oct 3 06:44:27 2008 From: Chuck.Rasbold at Sun.COM (Chuck Rasbold) Date: Fri, 03 Oct 2008 06:44:27 -0700 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E621BB.5040303@sun.com> Vote: yes Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this > decision. The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From Coleen.Phillimore at Sun.COM Fri Oct 3 06:43:57 2008 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Fri, 03 Oct 2008 09:43:57 -0400 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E6219D.8030109@sun.com> Vote: yes On 10/03/08 08:59, Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this > decision. The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From James.Melvin at Sun.COM Fri Oct 3 07:53:14 2008 From: James.Melvin at Sun.COM (James.Melvin at Sun.COM) Date: Fri, 03 Oct 2008 10:53:14 -0400 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E631DA.3010808@Sun.COM> Vote: yes Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this decision. > The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From Peter.Kessler at Sun.COM Fri Oct 3 07:53:23 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Fri, 03 Oct 2008 07:53:23 -0700 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E631E3.2040105@Sun.COM> Vote: yes ... peter Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this decision. > The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From Antonios.Printezis at sun.com Fri Oct 3 07:43:41 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Fri, 03 Oct 2008 10:43:41 -0400 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E62F9D.4060606@sun.com> Vote: oui :-) Tony Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this > decision. The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From Thomas.Rodriguez at Sun.COM Fri Oct 3 08:44:36 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 03 Oct 2008 08:44:36 -0700 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: Vote: yes On Oct 3, 2008, at 5:59 AM, Karen Kinnear wrote: > > I would like to nominate Laurent Daynes for membership in the > HotSpot Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this > decision. The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From David.Holmes at Sun.COM Fri Oct 3 19:42:27 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 04 Oct 2008 12:42:27 +1000 Subject: CFV: Laurent Daynes as member of the HotSpot Group In-Reply-To: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> References: <5A5BB919-BBC0-4544-BFC1-8DE35E672488@sun.com> Message-ID: <48E6D813.1090302@sun.com> Vote: yes David Holmes Karen Kinnear said the following on 10/03/08 22:59: > > I would like to nominate Laurent Daynes for membership in the HotSpot > Group. > > Laurent works in Sun Labs in Grenoble France. He has extensive > experience in > HotSpot with a strong background in multitasking and garbage > collection. He is currently > working on the Maxine VM research project in the labs. > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not > be counted. > > Votes are due by midnight UTC next Friday, October 10th, after which > time the votes will be tallied and reported to this list. > > Only Members of the HotSpot Group are eligible to vote on this decision. > The current > Members are: > > Andrei Pangin > Andrey Petrusenko > Antonios Printezis > Chuck Rasbold > Coleen Phillimore > Chris Phillips > Daniel Daugherty > Dave Dice > David Holmes > Erik Trimble > Igor Veresov > Ivan Krylov > James Melvin > Jim Holmlund > John Coomes > John Rose > Jon Masamitsu > Karen Kinnear > Keith McGuigan > Kenneth Russell > Kevin Walls > Lev Serebryakov > Paul Hohensee > Peter Kessler > Stephen Bohne > Steve Goldman > Thomas Rodriguez > Vladimir Kozlov > Xiaobin Lu > Y S Ramakrishna > Yumin Qi > > -- Karen Kinnear From charles.nutter at sun.com Fri Oct 3 19:55:22 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 03 Oct 2008 21:55:22 -0500 Subject: Understanding PrintOptoAssembly Message-ID: <48E6DB1A.8080600@sun.com> I'm trying to take JRuby performance up a notch, and it seems like the next best thing for me to do is examine what hotspot is actually emitting. At the JVM Languages Summit, Cliff Click informed me that paths we expected were inlining actually were not. As a result of my dicussions with him I've decided to try other flags to get more information. The first such flag I have easy access to is PrintOptoAssembly. However, I'm having some trouble understanding the output. Would it be possible for someone to post (on a wiki, perhaps) a snippit of a log and some walkthrough of what each element means? And I will describe the actual problem I have. We do dynamic invocation by calling through a piece of normal Java code called CachingCallSite. CachingCallSite has a call method that looks up the method and invokes it. If the cache is successful, it will continue to invoke the same method every time. But since the calls all pass through a virtual invocation to a totally generalized piece of Java code, the dynamically-selected call does not inline. I need to try other techniques, and I want some feedback that shows convincingly whether or not I'm making progress. - Charlie From charles.nutter at sun.com Fri Oct 3 21:12:41 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 03 Oct 2008 23:12:41 -0500 Subject: Understanding PrintOptoAssembly In-Reply-To: <48E6DB1A.8080600@sun.com> References: <48E6DB1A.8080600@sun.com> Message-ID: <48E6ED39.7060601@sun.com> Charles Oliver Nutter wrote: > I'm trying to take JRuby performance up a notch, and it seems like the > next best thing for me to do is examine what hotspot is actually > emitting. At the JVM Languages Summit, Cliff Click informed me that > paths we expected were inlining actually were not. As a result of my > dicussions with him I've decided to try other flags to get more > information. The first such flag I have easy access to is > PrintOptoAssembly. > > However, I'm having some trouble understanding the output. Would it be > possible for someone to post (on a wiki, perhaps) a snippit of a log and > some walkthrough of what each element means? Here's an example a confusing bit for me: 29f CALL,static org.jruby.runtime.ThreadContext::pollThreadEvents # org.jruby.runtime.ThreadContext::callThreadPoll @ bci:19 L[0]=_ # org.jruby.runtime.callsite.CachingCallSite::pollAndGetClass @ bci:1 L[0]=_ L[1]=_ L[2]=esp + #144 L[3]=_ # org.jruby.runtime.callsite.CallSiteInvoker::call @ bci:3 L[0]=esp + #32 L[1]=esp + #28 L[2]=esp + #144 L[3]=e sp + #144 L[4]=esp + #48 L[5]=_ L[6]=_ # bench.bench_fib_recursive::method__0$RUBY$fib_ruby @ bci:114 L[0]=esp + #152 L[1]=esp + #28 L[2]=esp + #144 L [3]=_ L[4]=_ L[5]=_ L[6]=esp + #20 L[7]=_ L[8]=_ L[9]=_ L[10]=_ L[11]=esp + #64 STK[0]=esp + #24 STK[1]=esp + #28 STK[2]=esp + #144 # AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) AllocatedObj(0x90f90b20) I can handle most of the x86ish assembly in the code bodies, but I'm not sure what all these lines around the CALL are. Obviously the L bits are describing how the local variables for the methods are being allocated, but what do the bits mean exactly? Why are there four different method descriptions after the CALL line? Also, this is appearing in the assembly for fib_ruby, and I see it listed here as well. This particular call could be one of the recursions back into fib_ruby via the CachingCallSite stuff. - Charlie From Xiaobin.Lu at Sun.COM Sat Oct 4 11:32:27 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Sat, 04 Oct 2008 11:32:27 -0700 Subject: review request for 6673124 Message-ID: <48E7B6BB.9030304@Sun.COM> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6673124/webrev/ Details: Hotspot needs to compute the number of available CPUs available to the java process in order to determine which flavor of VM to be used or how many GC threads needs to created for parallel collector. Also, the user could call Runtime.availableProcessors() and use that result to determine how many threads needs to be created for their applications, etc. Here is the current way to compute that number on Solaris where the problem might be seen. First, we check whether the process is bound to a existing processor set, if yes, we then check how many processors inside that processor set and use that number as the available CPUs. If not, we just return the number of total online CPUs as the number of available CPUs. This ignores the fact that even the process is NOT running inside a processor set, however, if there is any processor set around, the CPUs in that processor set won't be available to the java process. So the correct way of doing this is to ignore whether the process is bound to a processor set or not, as long as "pset_bind" returns successfully, we then use "pset_info" to check the available CPUs to us. We decided not to invent another flag to fall back to the old behavior which is absolutely wrong. Plus it is hard to come up with a sensible name for that flag, not to mention the user has to dig through globals.hpp to find out that flag to use. Reviewed by: Verified by: Experiments made on multi-core Solaris machines and trace put in the code to verify the return value is correct. JPRT. Thanks, -Xiaobin From yzhang1985 at gmail.com Sun Oct 5 13:36:12 2008 From: yzhang1985 at gmail.com (Yale Zhang) Date: Sun, 5 Oct 2008 16:36:12 -0400 Subject: How do are callers patched when a method is recompiled? Message-ID: <9052e0a90810051336xe907ba2ra72d8b9e3d38fc49@mail.gmail.com> Hi. I'm trying to build a dynamic optimization framework for LLVM and have been looking at HotSpot for ideas on how to patch the callers when a method is recompiled. I've spent over an hour looking at functions like new_nmethod, register_method and I can't figure it out. I've been thinking about the following approaches: 1. lazy relinking - keep the old code and patch callers only when they refer to the old code. I guess you can do this by patching the old code to find the call site and patch it. Then there's the question of when to throw away the old fragment. Could use reference counting or garbage collection. 2. relink immediately - upon recompiling, all callers are patched. This would be expensive because it would entail either going through every function looking for such a call (more processing) or maintaining a list of callers for each function (more storage). So, how does HotSpot do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081005/b305425b/attachment.html From David.Holmes at Sun.COM Sun Oct 5 17:44:14 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 06 Oct 2008 10:44:14 +1000 Subject: review request for 6673124 In-Reply-To: <48E7B6BB.9030304@Sun.COM> References: <48E7B6BB.9030304@Sun.COM> Message-ID: <48E95F5E.9060203@sun.com> Looks good to me. David Xiaobin Lu said the following on 10/05/08 04:32: > Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6673124/webrev/ > > Details: > > Hotspot needs to compute the number of available CPUs available to the > java process in order to determine which flavor of VM to be used or how > many GC threads needs to created for parallel collector. Also, the user > could call Runtime.availableProcessors() and use that result to > determine how many threads needs to be created for their applications, etc. > > Here is the current way to compute that number on Solaris where the > problem might be seen. First, we check whether the process is bound to a > existing processor set, if yes, we then check how many processors inside > that processor set and use that number as the available CPUs. If not, we > just return the number of total online CPUs as the number of available > CPUs. This ignores the fact that even the process is NOT running inside > a processor set, however, if there is any processor set around, the CPUs > in that processor set won't be available to the java process. So the > correct way of doing this is to ignore whether the process is bound to a > processor set or not, as long as "pset_bind" returns successfully, we > then use "pset_info" to check the available CPUs to us. > > We decided not to invent another flag to fall back to the old behavior > which is absolutely wrong. Plus it is hard to come up with a sensible > name for that flag, not to mention the user has to dig through > globals.hpp to find out that flag to use. > > Reviewed by: > > Verified by: > Experiments made on multi-core Solaris machines and trace put in the > code to verify the return value is correct. > JPRT. > > Thanks, > -Xiaobin > > > > > From charles.nutter at sun.com Mon Oct 6 13:21:21 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 06 Oct 2008 15:21:21 -0500 Subject: Understanding PrintOptoAssembly In-Reply-To: <48E6ED39.7060601@sun.com> References: <48E6DB1A.8080600@sun.com> <48E6ED39.7060601@sun.com> Message-ID: <48EA7341.5080502@sun.com> Charles Oliver Nutter wrote: > Here's an example a confusing bit for me: > > 29f CALL,static org.jruby.runtime.ThreadContext::pollThreadEvents > # org.jruby.runtime.ThreadContext::callThreadPoll @ bci:19 L[0]=_ > # org.jruby.runtime.callsite.CachingCallSite::pollAndGetClass @ > bci:1 L[0]=_ L[1]=_ L[2]=esp + #144 L[3]=_ > # org.jruby.runtime.callsite.CallSiteInvoker::call @ bci:3 > L[0]=esp + #32 L[1]=esp + #28 L[2]=esp + #144 L[3]=e > sp + #144 L[4]=esp + #48 L[5]=_ L[6]=_ > # bench.bench_fib_recursive::method__0$RUBY$fib_ruby @ bci:114 > L[0]=esp + #152 L[1]=esp + #28 L[2]=esp + #144 L > [3]=_ L[4]=_ L[5]=_ L[6]=esp + #20 L[7]=_ L[8]=_ L[9]=_ L[10]=_ > L[11]=esp + #64 STK[0]=esp + #24 STK[1]=esp + #28 STK[2]=esp + #144 # Ok, I think I'm starting to understand it now after playing around a bit. The call above is actually to pollthreadEvents; the others listed below it are the backtrace to that point...calls which have all already been inlined. So what this shows is where it finally bails out of inlined code to do a call, and where the call it's making actually occurs. Correct? - Charlie From Thomas.Rodriguez at Sun.COM Mon Oct 6 13:50:15 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 06 Oct 2008 13:50:15 -0700 Subject: Understanding PrintOptoAssembly In-Reply-To: <48EA7341.5080502@sun.com> References: <48E6DB1A.8080600@sun.com> <48E6ED39.7060601@sun.com> <48EA7341.5080502@sun.com> Message-ID: <52530DED-5D0A-4B34-BC59-9A9B43C3FA29@sun.com> Yes that's right. The CALL,static part says that we know that we are going to call exactly ThreadContext::pollThreadEvents. CALL,dynamic is used for sites where there might be multiple receivers. The L[#] and STK[#] tell where the values for the locals and stack live. The value "_" means that local is dead so we have no value for it. Any others parts that are confusing? tom On Oct 6, 2008, at 1:21 PM, Charles Oliver Nutter wrote: > Charles Oliver Nutter wrote: >> Here's an example a confusing bit for me: >> 29f CALL,static >> org.jruby.runtime.ThreadContext::pollThreadEvents >> # org.jruby.runtime.ThreadContext::callThreadPoll @ bci:19 >> L[0]=_ >> # >> org.jruby.runtime.callsite.CachingCallSite::pollAndGetClass @ bci: >> 1 L[0]=_ L[1]=_ L[2]=esp + #144 L[3]=_ >> # org.jruby.runtime.callsite.CallSiteInvoker::call @ bci:3 >> L[0]=esp + #32 L[1]=esp + #28 L[2]=esp + #144 L[3]=e >> sp + #144 L[4]=esp + #48 L[5]=_ L[6]=_ >> # bench.bench_fib_recursive::method__0$RUBY$fib_ruby @ bci: >> 114 L[0]=esp + #152 L[1]=esp + #28 L[2]=esp + #144 L >> [3]=_ L[4]=_ L[5]=_ L[6]=esp + #20 L[7]=_ L[8]=_ L[9]=_ L[10]=_ >> L[11]=esp + #64 STK[0]=esp + #24 STK[1]=esp + #28 STK[2]=esp + >> #144 # > > Ok, I think I'm starting to understand it now after playing around a > bit. The call above is actually to pollthreadEvents; the others > listed below it are the backtrace to that point...calls which have > all already been inlined. So what this shows is where it finally > bails out of inlined code to do a call, and where the call it's > making actually occurs. > > Correct? > > - Charlie From Thomas.Rodriguez at Sun.COM Mon Oct 6 13:58:06 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 06 Oct 2008 13:58:06 -0700 Subject: How do are callers patched when a method is recompiled? In-Reply-To: <9052e0a90810051336xe907ba2ra72d8b9e3d38fc49@mail.gmail.com> References: <9052e0a90810051336xe907ba2ra72d8b9e3d38fc49@mail.gmail.com> Message-ID: <165A5712-815D-4249-93D1-7E4568AE7743@sun.com> The basic machinery relies on making methods not entrant and reclaiming them once we're sure no inline cache could still contain a reference to them. We overwrite the first instructions of the generated code with an instruction sequence that gets us into the handle_wrong_method stub. Look at NativeJump::patch_verified_entry and SharedRuntime::handle_wrong_method. This forces any callers to reresolve the call site and either find any new generated code or fall back to the interpreter. NMethodSweeper takes care of cleaning all the inline caches that might still contain references to the nmethod by cleaning a portion of the code cache at every safepoint. Once we're sure that no inline cache could contain a reference to the not entrant nmethod we mark it for reclamation. There are some tricky bits in the runtime where code is operating on an nmethod and we want to be sure it isn't swept from underneath us and these use the nmethodLocker which is basically a reference counter that delays the freeing of the nmethod. We're not attempting to be aggressive in how quickly we reclaim the storage from the code cache and there are some problems with the current code if the rate of invalidation gets too high but those are just implementation details. There are a lot of ways our current implementation could be improved but it performs adequately in most ways so other than a few bug fixes it largely hasn't changed for a long time. The main flaw we'll have to address in the future is that if the rate of invalidation and/or the number of nmethods is high it performs way too much work at each safepoint. It processes a 1/4 of the code cache each time and it probably needs metric that is tied how much work it performs instead. tom On Oct 5, 2008, at 1:36 PM, Yale Zhang wrote: > Hi. I'm trying to build a dynamic optimization framework for LLVM > and have been looking at HotSpot for ideas on how to patch the > callers when a method is recompiled. I've spent over an hour looking > at functions like new_nmethod, register_method and I can't figure it > out. > > I've been thinking about the following approaches: > > 1. lazy relinking - keep the old code and patch callers only when > they refer to the old code. I guess you can do this by patching the > old code to find the call site and patch it. Then there's the > question of > when to throw away the old fragment. Could use reference counting or > garbage collection. > > 2. relink immediately - upon recompiling, all callers are patched. > This would be expensive because it would entail either going through > every function looking for such a call (more processing) or > maintaining a list of callers for each function (more storage). > > So, how does HotSpot do it? From Xiaobin.Lu at Sun.COM Mon Oct 6 16:06:59 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 06 Oct 2008 16:06:59 -0700 Subject: compatibility issue regarding the active processor count In-Reply-To: <48E2C049.2060409@Sun.COM> References: <48E2C049.2060409@Sun.COM> Message-ID: <48EA9A13.8050508@Sun.COM> According to the discussion with Paul and others, we decided to drop the flag completely. The main reason is that the current behavior is so bad that no one is going to be using it anyway. They may have already used ParallelGCThreads to get around it. Plus, we have some reservation about adding another long option name to the existing pool which has already grown so big. -Xiaobin Xiaobin Lu wrote: > Hi folks, > > I need your opinion about what we should do to solve the compatibility > issue regarding the active processor count. Basically, the problem is > on Solaris, if you create a processor set and then launch java process > without binding to that processor set, the number of available > processors to that java process is the total number of the online > processors minus the number of processors in the processor set you > created. Currently, we just report the total number of the online > processors as the active processor count which is wrong. This makes > the parallel garbage collector to behave in the wrong way (see bug > 6749430 for details) and we need to fix it per request from CBOE. > > There may be a compatibility issue after we correct this wrong > behavior when someone has already depended on this wrong return, which > we think it might be rare. We definitely need to invent a new flag in > order to address this and the question is whether we should keep the > current behavior as default or not. Personally, I feel we should have > that flag to fall back to the current wrong behavior, but I might be > wrong. > > Thanks so much in advance for your opinion. > > -Xiaobin > > > > From yzhang1985 at gmail.com Mon Oct 6 19:27:36 2008 From: yzhang1985 at gmail.com (Yale Zhang) Date: Mon, 6 Oct 2008 22:27:36 -0400 Subject: How do are callers patched when a method is recompiled? In-Reply-To: <165A5712-815D-4249-93D1-7E4568AE7743@sun.com> References: <9052e0a90810051336xe907ba2ra72d8b9e3d38fc49@mail.gmail.com> <165A5712-815D-4249-93D1-7E4568AE7743@sun.com> Message-ID: <9052e0a90810061927t33b8577fu9ca978bf87f22405@mail.gmail.com> Tom, Thanks for helping. The method you describe is almost exactly as I envisioned it in #1, which has the advantage of being lock free, not needing to store an explicit list of callers to patch, and gradual patching via the detour created. However, I see a potential problem. If you overwrite the 1st instruction in a function when a thread is in the code, then the function might not execute atomically if it has to execute the clobbered instruction again. Is it assumed that the patched instruction is a stack frame save instruction that never get executed > once? Also, I see why the patch can't overwrite > 1 instruction due to the possibility of executing an invalid instruction. Does HotSpot attempt to always make the 1st instruction of a function >= 5 bytes (patch size for X86)? Overall, while this method is efficient, I think it creates an ugly implementation due to ISA specifics. Does anybody know how applicable in general this method is on various ISAs? I see that it's used for x86_64, x86, and Sparc. On Mon, Oct 6, 2008 at 4:58 PM, Tom Rodriguez wrote: > The basic machinery relies on making methods not entrant and reclaiming > them once we're sure no inline cache could still contain a reference to > them. We overwrite the first instructions of the generated code with an > instruction sequence that gets us into the handle_wrong_method stub. Look > at NativeJump::patch_verified_entry and SharedRuntime::handle_wrong_method. > This forces any callers to reresolve the call site and either find any new > generated code or fall back to the interpreter. NMethodSweeper takes care > of cleaning all the inline caches that might still contain references to the > nmethod by cleaning a portion of the code cache at every safepoint. Once > we're sure that no inline cache could contain a reference to the not entrant > nmethod we mark it for reclamation. There are some tricky bits in the > runtime where code is operating on an nmethod and we want to be sure it > isn't swept from underneath us and these use the nmethodLocker which is > basically a reference counter that delays the freeing of the nmethod. > > We're not attempting to be aggressive in how quickly we reclaim the storage > from the code cache and there are some problems with the current code if the > rate of invalidation gets too high but those are just implementation > details. There are a lot of ways our current implementation could be > improved but it performs adequately in most ways so other than a few bug > fixes it largely hasn't changed for a long time. The main flaw we'll have > to address in the future is that if the rate of invalidation and/or the > number of nmethods is high it performs way too much work at each safepoint. > It processes a 1/4 of the code cache each time and it probably needs metric > that is tied how much work it performs instead. > > tom > > > On Oct 5, 2008, at 1:36 PM, Yale Zhang wrote: > > Hi. I'm trying to build a dynamic optimization framework for LLVM and have >> been looking at HotSpot for ideas on how to patch the callers when a method >> is recompiled. I've spent over an hour looking at functions like >> new_nmethod, register_method and I can't figure it out. >> >> I've been thinking about the following approaches: >> >> 1. lazy relinking - keep the old code and patch callers only when they >> refer to the old code. I guess you can do this by patching the old code to >> find the call site and patch it. Then there's the question of >> when to throw away the old fragment. Could use reference counting or >> garbage collection. >> >> 2. relink immediately - upon recompiling, all callers are patched. This >> would be expensive because it would entail either going through every >> function looking for such a call (more processing) or maintaining a list of >> callers for each function (more storage). >> >> So, how does HotSpot do it? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081006/f8839a9b/attachment.html From Thomas.Rodriguez at Sun.COM Mon Oct 6 22:59:53 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 06 Oct 2008 22:59:53 -0700 Subject: How do are callers patched when a method is recompiled? In-Reply-To: <9052e0a90810061927t33b8577fu9ca978bf87f22405@mail.gmail.com> References: <9052e0a90810051336xe907ba2ra72d8b9e3d38fc49@mail.gmail.com> <165A5712-815D-4249-93D1-7E4568AE7743@sun.com> <9052e0a90810061927t33b8577fu9ca978bf87f22405@mail.gmail.com> Message-ID: <5D4E3321-5A01-4721-8A07-0391F2ABE09E@Sun.COM> On Oct 6, 2008, at 7:27 PM, Yale Zhang wrote: > Tom, > > Thanks for helping. The method you describe is almost exactly as I > envisioned it in #1, which has the advantage of being lock free, not > needing to store an explicit list of callers to patch, and gradual > patching via the detour created. However, I see a potential problem. > If you overwrite the 1st instruction in a function when a thread is > in the code, then the function might not execute atomically if it > has to execute the clobbered instruction again. Is it assumed that > the patched instruction is a stack frame save instruction that never > get executed > once? Also, I see why the patch can't overwrite > 1 > instruction due to the possibility of executing an invalid > instruction. Does HotSpot attempt to always make the 1st instruction > of a function >= 5 bytes (patch size for X86)? It does create some constraints on what the first instruction of the nmethod is and we always align the entry point to at least 8 bytes. There are assertions scattered about that check these conditions. Instruction cache memory consistency tends to be weaker than the normal memory hierarchy so we rely on store atomicity and don't require that other threads immediately see the changes to the instruction stream. > Overall, while this method is efficient, I think it creates an ugly > implementation due to ISA specifics. Does anybody know how > applicable in general this method is on various ISAs? I see that > it's used for x86_64, x86, and Sparc. There are also ia64, ppc and arm ports of hotspot in existence that use the same basic mechanism. x86 uses a branch but sparc uses a trapping instruction along with extra logic in the signal handler. So there are lots of ways to approach the entry point patching. Any ISA with fixed size instructions is relatively easy, it's only x86 that makes the patching part somewhat tricky. tom > > On Mon, Oct 6, 2008 at 4:58 PM, Tom Rodriguez > wrote: > The basic machinery relies on making methods not entrant and > reclaiming them once we're sure no inline cache could still contain > a reference to them. We overwrite the first instructions of the > generated code with an instruction sequence that gets us into the > handle_wrong_method stub. Look at NativeJump::patch_verified_entry > and SharedRuntime::handle_wrong_method. This forces any callers to > reresolve the call site and either find any new generated code or > fall back to the interpreter. NMethodSweeper takes care of cleaning > all the inline caches that might still contain references to the > nmethod by cleaning a portion of the code cache at every safepoint. > Once we're sure that no inline cache could contain a reference to > the not entrant nmethod we mark it for reclamation. There are some > tricky bits in the runtime where code is operating on an nmethod and > we want to be sure it isn't swept from underneath us and these use > the nmethodLocker which is basically a reference counter that delays > the freeing of the nmethod. > > We're not attempting to be aggressive in how quickly we reclaim the > storage from the code cache and there are some problems with the > current code if the rate of invalidation gets too high but those are > just implementation details. There are a lot of ways our current > implementation could be improved but it performs adequately in most > ways so other than a few bug fixes it largely hasn't changed for a > long time. The main flaw we'll have to address in the future is > that if the rate of invalidation and/or the number of nmethods is > high it performs way too much work at each safepoint. It processes > a 1/4 of the code cache each time and it probably needs metric that > is tied how much work it performs instead. > > tom > > > On Oct 5, 2008, at 1:36 PM, Yale Zhang wrote: > > Hi. I'm trying to build a dynamic optimization framework for LLVM > and have been looking at HotSpot for ideas on how to patch the > callers when a method is recompiled. I've spent over an hour looking > at functions like new_nmethod, register_method and I can't figure it > out. > > I've been thinking about the following approaches: > > 1. lazy relinking - keep the old code and patch callers only when > they refer to the old code. I guess you can do this by patching the > old code to find the call site and patch it. Then there's the > question of > when to throw away the old fragment. Could use reference counting or > garbage collection. > > 2. relink immediately - upon recompiling, all callers are patched. > This would be expensive because it would entail either going through > every function looking for such a call (more processing) or > maintaining a list of callers for each function (more storage). > > So, how does HotSpot do it? > > From jameswang99 at yahoo.com Tue Oct 7 19:06:48 2008 From: jameswang99 at yahoo.com (Cong Wang) Date: Tue, 7 Oct 2008 21:06:48 -0500 Subject: open jdk debug options Message-ID: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> Hi all: I am trying to modify some part of the hotspot runtime interpreter and I would like to debug that using either dbx or gdb. I have compile the file using the following options: ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs ALT_FREETYPE_LIB_PATH=/usr/local/lib ALT_FREETYPE_HEADERS_PATH=/usr/local/include ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8 ANT_HOME=/usr/sfw ALT_OUTPUTDIR=/scratch/wang/java_tm_7 DEV_ONLY=true DEBUG=true I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin directory. I would like to set a break point at hotspot/src/cpu/sparc/vm/assembler_sparc.cpp MacroAssembler::compiler_lock_object function. I have tried to use the dbx pathmap command but it doesn't seem to help dbx to locate the source file or the function definition. Any suggestions? Thanks in advance for any comment. -- Regards James Wang From Jon.Masamitsu at Sun.COM Tue Oct 7 20:03:50 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 07 Oct 2008 20:03:50 -0700 Subject: open jdk debug options In-Reply-To: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> References: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> Message-ID: <48EC2316.3050901@sun.com> How do you start dbx on java? And what is dbx saying exactly? Cong Wang wrote: > Hi all: > I am trying to modify some part of the hotspot runtime interpreter > and I would like to debug that using either dbx or gdb. I have compile > the file using the following options: > > ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs > ALT_FREETYPE_LIB_PATH=/usr/local/lib > ALT_FREETYPE_HEADERS_PATH=/usr/local/include > ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8 > ANT_HOME=/usr/sfw > ALT_OUTPUTDIR=/scratch/wang/java_tm_7 > DEV_ONLY=true > DEBUG=true > > I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin > directory. I would like to set a break point at > hotspot/src/cpu/sparc/vm/assembler_sparc.cpp > MacroAssembler::compiler_lock_object function. I have tried to use the > dbx pathmap command but it doesn't seem to help dbx to locate the > source file or the function definition. > Any suggestions? Thanks in advance for any comment. > > From jameswang99 at yahoo.com Tue Oct 7 21:15:40 2008 From: jameswang99 at yahoo.com (Cong Wang) Date: Tue, 7 Oct 2008 23:15:40 -0500 Subject: open jdk debug options In-Reply-To: <48EC2316.3050901@sun.com> References: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> <48EC2316.3050901@sun.com> Message-ID: <92350dc0810072115s4885fec8m6cb7ec9c798deadc@mail.gmail.com> Hi Jon: I went into the ALT_OUTPUTDIR/bin start dbx with : dbx java For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading java Reading /usr/lib/ld.so.1 Reading /lib/libthread.so.1 Reading /scratch/wang/java_tm_7/lib/sparc/jli/libjli.so Reading /lib/libdl.so.1 Reading /lib/libc.so.1 then I map the src file foler into the current folder, using pathmap pathmap /scratch/wang/openjdk/hotspot/src/cpu/sparc/vm /scratch/wang/java_tm_7/bin after the pathmap, I try to find the function using whereis compiler_lock_object there is no output. But I know that function is in /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so, therefore I use the following to load the shared library: loadobject -load /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so Reading /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so Loaded loadobject: /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so now, when I use whereis to find compiler_lock_object, I got: whereis compiler_lock_object function: `/scratch/wang/java_tm_7/lib/sparc/server/libjvm.so`assembler_sparc.cpp`#__1cOMacroAssemblerUcompiler_lock_object6MpnMRegisterImpl_222pnVBiasedLockingCounters__v_ [non -g, demangles to: MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*)] Then, I set a break point using: stop in compiler_lock_object dbx: warning: 'compiler_lock_object' has no debugger info -- will trigger on first instruction (2) stop in MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*) So, I run my application in the debugger using: run -server -Xcomp -Xbatch -Xss128k -XX:NewSize=256m -Xnoclassgc -verbose:gc -classpath /scratch/wang/java_tm_7/bin/ SynchronizedCounter (process id 25142) dbx: process 25142 about to exec("/scratch/wang/java_tm_7/bin/java") dbx: program "/scratch/wang/java_tm_7/bin/java" just exec'ed dbx: to go back to the original program use "debug $oprog" t at 1 (l at 1) stopped in main at 0x00010d30 0x00010d30: main : save %sp, -128, %sp (dbx) cont t at 2 (l at 2) signal SEGV (no mapping at the fault address) in (unknown) at 0xfc063710 0xfc063710: ld [%o0 + 4], %l0 Current function is jni_invoke_nonstatic (optimized) 1084 JavaCalls::call(result, method, &java_args, CHECK); I will never get to my break point. But if I run this outside dbx, everything works fine. SynchronizedCounter is a small multi-threaed java program I wrote to test the jvm. It has two threads try to grab a lock and increment a shared counter. It works fine but I want to change how the jvm manages the lock, so I want to stop the program when jvm creates a lock and acquires it. Thanks for any comment you may have in advance. Regards James Wang On Tue, Oct 7, 2008 at 10:03 PM, Jon Masamitsu wrote: > How do you start dbx on java? And what is dbx saying > exactly? > > Cong Wang wrote: >> >> Hi all: >> I am trying to modify some part of the hotspot runtime interpreter >> and I would like to debug that using either dbx or gdb. I have compile >> the file using the following options: >> >> ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs >> ALT_FREETYPE_LIB_PATH=/usr/local/lib >> ALT_FREETYPE_HEADERS_PATH=/usr/local/include >> ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8 >> ANT_HOME=/usr/sfw >> ALT_OUTPUTDIR=/scratch/wang/java_tm_7 >> DEV_ONLY=true >> DEBUG=true >> >> I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin >> directory. I would like to set a break point at >> hotspot/src/cpu/sparc/vm/assembler_sparc.cpp >> MacroAssembler::compiler_lock_object function. I have tried to use the >> dbx pathmap command but it doesn't seem to help dbx to locate the >> source file or the function definition. >> Any suggestions? Thanks in advance for any comment. >> >> > > -- Regards James Wang From neojia at gmail.com Tue Oct 7 21:54:57 2008 From: neojia at gmail.com (Neo Jia) Date: Tue, 7 Oct 2008 21:54:57 -0700 Subject: open jdk debug options In-Reply-To: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> References: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> Message-ID: <5d649bdb0810072154p4c69e659g340fb5fd1ab291a4@mail.gmail.com> I have done that long time ago (last Summer) but it is definitely doable with gdb. But, you have to enable "+ggdb3" to get all the C++ symbols. Thanks, Neo On Tue, Oct 7, 2008 at 7:06 PM, Cong Wang wrote: > Hi all: > I am trying to modify some part of the hotspot runtime interpreter > and I would like to debug that using either dbx or gdb. I have compile > the file using the following options: > > ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs > ALT_FREETYPE_LIB_PATH=/usr/local/lib > ALT_FREETYPE_HEADERS_PATH=/usr/local/include > ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8 > ANT_HOME=/usr/sfw > ALT_OUTPUTDIR=/scratch/wang/java_tm_7 > DEV_ONLY=true > DEBUG=true > > I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin > directory. I would like to set a break point at > hotspot/src/cpu/sparc/vm/assembler_sparc.cpp > MacroAssembler::compiler_lock_object function. I have tried to use the > dbx pathmap command but it doesn't seem to help dbx to locate the > source file or the function definition. > Any suggestions? Thanks in advance for any comment. > > -- > Regards > James Wang > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From Jon.Masamitsu at Sun.COM Tue Oct 7 22:05:55 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 07 Oct 2008 22:05:55 -0700 Subject: open jdk debug options In-Reply-To: <92350dc0810072115s4885fec8m6cb7ec9c798deadc@mail.gmail.com> References: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> <48EC2316.3050901@sun.com> <92350dc0810072115s4885fec8m6cb7ec9c798deadc@mail.gmail.com> Message-ID: <48EC3FB3.8090206@sun.com> When you start dbx java you are starting dbx on the java launcher. The launcher does an exec of the VM. In the output below from dbx the "stopped in main" indicates that the exec has happened and you've stopped in the main of the VM. At that point dbx has forgotten about the breakpoints you've set because it thinks the breakpoints are in the launcher. You need to set your LD_LIBRARY_PATH to point to the libjvm.so that you've built. Compile this program public class PrintLibraryPath { public static void main(String[] args) { System.out.println(System.getProperty("java.library.path")); } } and execute it with the java you want to debug. I have /usr/jdk/jdk1.5.0_11/bin/java so ------------------- /usr/jdk/jdk1.5.0_11/bin/java PrintLibraryPath /usr/jdk/instances/jdk1.5.0/jre/lib/sparc/server:/usr/jdk/instances/jdk1.5.0/jre/lib/sparc:/usr/jdk/instances/jdk1.5.0/jre/../lib/sparc:/usr/lib ------------------- prints the LD_LIBRARY_PATH for /usr/jdk/jdk1.5.0_11/bin/java Set your LD_LIBRARY_PATH accordingly. Then start dbx on java and you should see something like ------------------- dbx /usr/jdk/jdk1.5.0_11/bin/java For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrcReading java Reading ld.so.1 Reading libthread.so.1 Reading libdl.so.1 Reading libc.so.1 ------------------- Run with -version ------------------- dbx: run -version Running: java -version (process id 6309) Reading libc_psr.so.1 Reading libjvm.so Reading libsocket.so.1 Reading libsched.so.1 Reading libCrun.so.1 Reading libm.so.1 Reading libnsl.so.1 Reading libm.so.2 Reading libscf.so.1 Reading libdoor.so.1 Reading libuutil.so.1 Reading libmd5.so.1 Reading libmd5_psr.so.1 Reading libmp.so.2 Reading libhpi.so Reading libverify.so Reading libjava.so Reading libzip.so java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode) execution completed, exit code is 0 dbx: ------------------- Running with -version causes the VM to execute and all the libraries get loaded. You should them see your /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so You should be able to set your breakpoints now and run with your real java command line. Cong Wang wrote: > Hi Jon: > I went into the ALT_OUTPUTDIR/bin > start dbx with : > dbx java > For information about new features see `help changes' > To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc > Reading java > Reading /usr/lib/ld.so.1 > Reading /lib/libthread.so.1 > Reading /scratch/wang/java_tm_7/lib/sparc/jli/libjli.so > Reading /lib/libdl.so.1 > Reading /lib/libc.so.1 > > then I map the src file foler into the current folder, using pathmap > > pathmap /scratch/wang/openjdk/hotspot/src/cpu/sparc/vm > /scratch/wang/java_tm_7/bin > > after the pathmap, I try to find the function using > > whereis compiler_lock_object > > there is no output. > > But I know that function is in > /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so, therefore > I use the following to load the shared library: > loadobject -load /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so > Reading /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so > Loaded loadobject: /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so > > now, when I use whereis to find compiler_lock_object, I got: > whereis compiler_lock_object > function: > `/scratch/wang/java_tm_7/lib/sparc/server/libjvm.so`assembler_sparc.cpp`#__1cOMacroAssemblerUcompiler_lock_object6MpnMRegisterImpl_222pnVBiasedLockingCounters__v_ > [non -g, demangles to: > MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*)] > > Then, I set a break point using: > stop in compiler_lock_object > dbx: warning: 'compiler_lock_object' has no debugger info -- will > trigger on first instruction > (2) stop in MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*) > > > So, I run my application in the debugger > using: > > run -server -Xcomp -Xbatch -Xss128k -XX:NewSize=256m -Xnoclassgc > -verbose:gc -classpath /scratch/wang/java_tm_7/bin/ > SynchronizedCounter > > (process id 25142) > dbx: process 25142 about to exec("/scratch/wang/java_tm_7/bin/java") > dbx: program "/scratch/wang/java_tm_7/bin/java" just exec'ed > dbx: to go back to the original program use "debug $oprog" > t at 1 (l at 1) stopped in main at 0x00010d30 > 0x00010d30: main : save %sp, -128, %sp > > (dbx) cont > t at 2 (l at 2) signal SEGV (no mapping at the fault address) in (unknown) > at 0xfc063710 > 0xfc063710: ld [%o0 + 4], %l0 > Current function is jni_invoke_nonstatic (optimized) > 1084 JavaCalls::call(result, method, &java_args, CHECK); > > I will never get to my break point. But if I run this outside dbx, > everything works fine. > > SynchronizedCounter is a small multi-threaed java program I wrote to > test the jvm. It has two threads try to grab a lock and increment a > shared counter. > It works fine but I want to change how the jvm manages the lock, so I > want to stop the program when jvm creates a lock and acquires it. > > Thanks for any comment you may have in advance. > > Regards > James Wang > > > On Tue, Oct 7, 2008 at 10:03 PM, Jon Masamitsu wrote: > >> How do you start dbx on java? And what is dbx saying >> exactly? >> >> Cong Wang wrote: >> >>> Hi all: >>> I am trying to modify some part of the hotspot runtime interpreter >>> and I would like to debug that using either dbx or gdb. I have compile >>> the file using the following options: >>> >>> ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs >>> ALT_FREETYPE_LIB_PATH=/usr/local/lib >>> ALT_FREETYPE_HEADERS_PATH=/usr/local/include >>> ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8 >>> ANT_HOME=/usr/sfw >>> ALT_OUTPUTDIR=/scratch/wang/java_tm_7 >>> DEV_ONLY=true >>> DEBUG=true >>> >>> I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin >>> directory. I would like to set a break point at >>> hotspot/src/cpu/sparc/vm/assembler_sparc.cpp >>> MacroAssembler::compiler_lock_object function. I have tried to use the >>> dbx pathmap command but it doesn't seem to help dbx to locate the >>> source file or the function definition. >>> Any suggestions? Thanks in advance for any comment. >>> >>> >>> >> > > > > From neojia at gmail.com Tue Oct 7 22:08:37 2008 From: neojia at gmail.com (Neo Jia) Date: Tue, 7 Oct 2008 22:08:37 -0700 Subject: open jdk debug options In-Reply-To: <48EC3FB3.8090206@sun.com> References: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> <48EC2316.3050901@sun.com> <92350dc0810072115s4885fec8m6cb7ec9c798deadc@mail.gmail.com> <48EC3FB3.8090206@sun.com> Message-ID: <5d649bdb0810072208v740cdcafm129c3e7a1ddacd7d@mail.gmail.com> On Tue, Oct 7, 2008 at 10:05 PM, Jon Masamitsu wrote: > > When you start > > dbx java > > you are starting dbx on the java launcher. The > launcher does an exec of the VM. > In the output below from dbx the "stopped in main" > indicates that the exec has happened and you've > stopped in the main of the VM. At that point > dbx has forgotten about the breakpoints you've > set because it thinks the breakpoints are in the > launcher. FYI. gdb can keep follow the exec after 6.5. Thanks, Neo > > You need to set your LD_LIBRARY_PATH > to point to the libjvm.so that you've built. > > Compile this program > > public class PrintLibraryPath { > public static void main(String[] args) { > System.out.println(System.getProperty("java.library.path")); > } > } > > and execute it with the java you want to debug. > > I have /usr/jdk/jdk1.5.0_11/bin/java so > > ------------------- > /usr/jdk/jdk1.5.0_11/bin/java PrintLibraryPath > /usr/jdk/instances/jdk1.5.0/jre/lib/sparc/server:/usr/jdk/instances/jdk1.5.0/jre/lib/sparc:/usr/jdk/instances/jdk1.5.0/jre/../lib/sparc:/usr/lib > ------------------- > > prints the LD_LIBRARY_PATH for /usr/jdk/jdk1.5.0_11/bin/java > > Set your LD_LIBRARY_PATH accordingly. > > Then start dbx on java and you should see something like > > ------------------- > dbx /usr/jdk/jdk1.5.0_11/bin/java > For information about new features see `help changes' > To remove this message, put `dbxenv suppress_startup_message 7.5' in your > .dbxrcReading java > Reading ld.so.1 > Reading libthread.so.1 > Reading libdl.so.1 > Reading libc.so.1 > ------------------- > > Run with -version > > ------------------- > > dbx: run -version > Running: java -version > (process id 6309) > Reading libc_psr.so.1 > Reading libjvm.so > Reading libsocket.so.1 > Reading libsched.so.1 > Reading libCrun.so.1 > Reading libm.so.1 > Reading libnsl.so.1 > Reading libm.so.2 > Reading libscf.so.1 > Reading libdoor.so.1 > Reading libuutil.so.1 > Reading libmd5.so.1 > Reading libmd5_psr.so.1 > Reading libmp.so.2 > Reading libhpi.so > Reading libverify.so > Reading libjava.so > Reading libzip.so > java version "1.5.0_11" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) > Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode) > > execution completed, exit code is 0 > dbx: > ------------------- > > Running with -version causes the VM to execute and all the > libraries get loaded. You should them see your > > /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so > > You should be able to set your breakpoints now and run > with your real java command line. > > > Cong Wang wrote: >> >> Hi Jon: >> I went into the ALT_OUTPUTDIR/bin >> start dbx with : >> dbx java >> For information about new features see `help changes' >> To remove this message, put `dbxenv suppress_startup_message 7.6' in your >> .dbxrc >> Reading java >> Reading /usr/lib/ld.so.1 >> Reading /lib/libthread.so.1 >> Reading /scratch/wang/java_tm_7/lib/sparc/jli/libjli.so >> Reading /lib/libdl.so.1 >> Reading /lib/libc.so.1 >> >> then I map the src file foler into the current folder, using pathmap >> >> pathmap /scratch/wang/openjdk/hotspot/src/cpu/sparc/vm >> /scratch/wang/java_tm_7/bin >> >> after the pathmap, I try to find the function using >> >> whereis compiler_lock_object >> >> there is no output. >> >> But I know that function is in >> /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so, therefore >> I use the following to load the shared library: >> loadobject -load /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so >> Reading /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so >> Loaded loadobject: /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so >> >> now, when I use whereis to find compiler_lock_object, I got: >> whereis compiler_lock_object >> function: >> >> `/scratch/wang/java_tm_7/lib/sparc/server/libjvm.so`assembler_sparc.cpp`#__1cOMacroAssemblerUcompiler_lock_object6MpnMRegisterImpl_222pnVBiasedLockingCounters__v_ >> [non -g, demangles to: >> >> MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*)] >> >> Then, I set a break point using: >> stop in compiler_lock_object >> dbx: warning: 'compiler_lock_object' has no debugger info -- will >> trigger on first instruction >> (2) stop in >> MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*) >> >> >> So, I run my application in the debugger >> using: >> >> run -server -Xcomp -Xbatch -Xss128k -XX:NewSize=256m -Xnoclassgc >> -verbose:gc -classpath /scratch/wang/java_tm_7/bin/ >> SynchronizedCounter >> >> (process id 25142) >> dbx: process 25142 about to exec("/scratch/wang/java_tm_7/bin/java") >> dbx: program "/scratch/wang/java_tm_7/bin/java" just exec'ed >> dbx: to go back to the original program use "debug $oprog" >> t at 1 (l at 1) stopped in main at 0x00010d30 >> 0x00010d30: main : save %sp, -128, %sp >> >> (dbx) cont >> t at 2 (l at 2) signal SEGV (no mapping at the fault address) in (unknown) >> at 0xfc063710 >> 0xfc063710: ld [%o0 + 4], %l0 >> Current function is jni_invoke_nonstatic (optimized) >> 1084 JavaCalls::call(result, method, &java_args, CHECK); >> >> I will never get to my break point. But if I run this outside dbx, >> everything works fine. >> >> SynchronizedCounter is a small multi-threaed java program I wrote to >> test the jvm. It has two threads try to grab a lock and increment a >> shared counter. >> It works fine but I want to change how the jvm manages the lock, so I >> want to stop the program when jvm creates a lock and acquires it. >> >> Thanks for any comment you may have in advance. >> >> Regards >> James Wang >> >> >> On Tue, Oct 7, 2008 at 10:03 PM, Jon Masamitsu >> wrote: >> >>> >>> How do you start dbx on java? And what is dbx saying >>> exactly? >>> >>> Cong Wang wrote: >>> >>>> >>>> Hi all: >>>> I am trying to modify some part of the hotspot runtime interpreter >>>> and I would like to debug that using either dbx or gdb. I have compile >>>> the file using the following options: >>>> >>>> ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs >>>> ALT_FREETYPE_LIB_PATH=/usr/local/lib >>>> ALT_FREETYPE_HEADERS_PATH=/usr/local/include >>>> ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8 >>>> ANT_HOME=/usr/sfw >>>> ALT_OUTPUTDIR=/scratch/wang/java_tm_7 >>>> DEV_ONLY=true >>>> DEBUG=true >>>> >>>> I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin >>>> directory. I would like to set a break point at >>>> hotspot/src/cpu/sparc/vm/assembler_sparc.cpp >>>> MacroAssembler::compiler_lock_object function. I have tried to use the >>>> dbx pathmap command but it doesn't seem to help dbx to locate the >>>> source file or the function definition. >>>> Any suggestions? Thanks in advance for any comment. >>>> >>>> >>>> >>> >>> >> >> >> >> > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From jameswang99 at yahoo.com Tue Oct 7 22:13:14 2008 From: jameswang99 at yahoo.com (Cong Wang) Date: Wed, 8 Oct 2008 13:13:14 +0800 Subject: open jdk debug options In-Reply-To: <5d649bdb0810072208v740cdcafm129c3e7a1ddacd7d@mail.gmail.com> References: <92350dc0810071906v3efd0a90k79e5c426fd73a87@mail.gmail.com> <48EC2316.3050901@sun.com> <92350dc0810072115s4885fec8m6cb7ec9c798deadc@mail.gmail.com> <48EC3FB3.8090206@sun.com> <5d649bdb0810072208v740cdcafm129c3e7a1ddacd7d@mail.gmail.com> Message-ID: <92350dc0810072213i3fe2b210q3a0a5332202ff920@mail.gmail.com> OK. So, Neo, the option for -ggdb3 is for sun cc or gcc? Thank you all for your response so far. Regards James Wang On Wed, Oct 8, 2008 at 1:08 PM, Neo Jia wrote: > On Tue, Oct 7, 2008 at 10:05 PM, Jon Masamitsu wrote: >> >> When you start >> >> dbx java >> >> you are starting dbx on the java launcher. The >> launcher does an exec of the VM. >> In the output below from dbx the "stopped in main" >> indicates that the exec has happened and you've >> stopped in the main of the VM. At that point >> dbx has forgotten about the breakpoints you've >> set because it thinks the breakpoints are in the >> launcher. > > FYI. gdb can keep follow the exec after 6.5. > > Thanks, > Neo > >> >> You need to set your LD_LIBRARY_PATH >> to point to the libjvm.so that you've built. >> >> Compile this program >> >> public class PrintLibraryPath { >> public static void main(String[] args) { >> System.out.println(System.getProperty("java.library.path")); >> } >> } >> >> and execute it with the java you want to debug. >> >> I have /usr/jdk/jdk1.5.0_11/bin/java so >> >> ------------------- >> /usr/jdk/jdk1.5.0_11/bin/java PrintLibraryPath >> /usr/jdk/instances/jdk1.5.0/jre/lib/sparc/server:/usr/jdk/instances/jdk1.5.0/jre/lib/sparc:/usr/jdk/instances/jdk1.5.0/jre/../lib/sparc:/usr/lib >> ------------------- >> >> prints the LD_LIBRARY_PATH for /usr/jdk/jdk1.5.0_11/bin/java >> >> Set your LD_LIBRARY_PATH accordingly. >> >> Then start dbx on java and you should see something like >> >> ------------------- >> dbx /usr/jdk/jdk1.5.0_11/bin/java >> For information about new features see `help changes' >> To remove this message, put `dbxenv suppress_startup_message 7.5' in your >> .dbxrcReading java >> Reading ld.so.1 >> Reading libthread.so.1 >> Reading libdl.so.1 >> Reading libc.so.1 >> ------------------- >> >> Run with -version >> >> ------------------- >> >> dbx: run -version >> Running: java -version >> (process id 6309) >> Reading libc_psr.so.1 >> Reading libjvm.so >> Reading libsocket.so.1 >> Reading libsched.so.1 >> Reading libCrun.so.1 >> Reading libm.so.1 >> Reading libnsl.so.1 >> Reading libm.so.2 >> Reading libscf.so.1 >> Reading libdoor.so.1 >> Reading libuutil.so.1 >> Reading libmd5.so.1 >> Reading libmd5_psr.so.1 >> Reading libmp.so.2 >> Reading libhpi.so >> Reading libverify.so >> Reading libjava.so >> Reading libzip.so >> java version "1.5.0_11" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >> Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode) >> >> execution completed, exit code is 0 >> dbx: >> ------------------- >> >> Running with -version causes the VM to execute and all the >> libraries get loaded. You should them see your >> >> /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so >> >> You should be able to set your breakpoints now and run >> with your real java command line. >> >> >> Cong Wang wrote: >>> >>> Hi Jon: >>> I went into the ALT_OUTPUTDIR/bin >>> start dbx with : >>> dbx java >>> For information about new features see `help changes' >>> To remove this message, put `dbxenv suppress_startup_message 7.6' in your >>> .dbxrc >>> Reading java >>> Reading /usr/lib/ld.so.1 >>> Reading /lib/libthread.so.1 >>> Reading /scratch/wang/java_tm_7/lib/sparc/jli/libjli.so >>> Reading /lib/libdl.so.1 >>> Reading /lib/libc.so.1 >>> >>> then I map the src file foler into the current folder, using pathmap >>> >>> pathmap /scratch/wang/openjdk/hotspot/src/cpu/sparc/vm >>> /scratch/wang/java_tm_7/bin >>> >>> after the pathmap, I try to find the function using >>> >>> whereis compiler_lock_object >>> >>> there is no output. >>> >>> But I know that function is in >>> /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so, therefore >>> I use the following to load the shared library: >>> loadobject -load /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so >>> Reading /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so >>> Loaded loadobject: /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so >>> >>> now, when I use whereis to find compiler_lock_object, I got: >>> whereis compiler_lock_object >>> function: >>> >>> `/scratch/wang/java_tm_7/lib/sparc/server/libjvm.so`assembler_sparc.cpp`#__1cOMacroAssemblerUcompiler_lock_object6MpnMRegisterImpl_222pnVBiasedLockingCounters__v_ >>> [non -g, demangles to: >>> >>> MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*)] >>> >>> Then, I set a break point using: >>> stop in compiler_lock_object >>> dbx: warning: 'compiler_lock_object' has no debugger info -- will >>> trigger on first instruction >>> (2) stop in >>> MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*) >>> >>> >>> So, I run my application in the debugger >>> using: >>> >>> run -server -Xcomp -Xbatch -Xss128k -XX:NewSize=256m -Xnoclassgc >>> -verbose:gc -classpath /scratch/wang/java_tm_7/bin/ >>> SynchronizedCounter >>> >>> (process id 25142) >>> dbx: process 25142 about to exec("/scratch/wang/java_tm_7/bin/java") >>> dbx: program "/scratch/wang/java_tm_7/bin/java" just exec'ed >>> dbx: to go back to the original program use "debug $oprog" >>> t at 1 (l at 1) stopped in main at 0x00010d30 >>> 0x00010d30: main : save %sp, -128, %sp >>> >>> (dbx) cont >>> t at 2 (l at 2) signal SEGV (no mapping at the fault address) in (unknown) >>> at 0xfc063710 >>> 0xfc063710: ld [%o0 + 4], %l0 >>> Current function is jni_invoke_nonstatic (optimized) >>> 1084 JavaCalls::call(result, method, &java_args, CHECK); >>> >>> I will never get to my break point. But if I run this outside dbx, >>> everything works fine. >>> >>> SynchronizedCounter is a small multi-threaed java program I wrote to >>> test the jvm. It has two threads try to grab a lock and increment a >>> shared counter. >>> It works fine but I want to change how the jvm manages the lock, so I >>> want to stop the program when jvm creates a lock and acquires it. >>> >>> Thanks for any comment you may have in advance. >>> >>> Regards >>> James Wang >>> >>> >>> On Tue, Oct 7, 2008 at 10:03 PM, Jon Masamitsu >>> wrote: >>> >>>> >>>> How do you start dbx on java? And what is dbx saying >>>> exactly? >>>> >>>> Cong Wang wrote: >>>> >>>>> >>>>> Hi all: >>>>> I am trying to modify some part of the hotspot runtime interpreter >>>>> and I would like to debug that using either dbx or gdb. I have compile >>>>> the file using the following options: >>>>> >>>>> ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs >>>>> ALT_FREETYPE_LIB_PATH=/usr/local/lib >>>>> ALT_FREETYPE_HEADERS_PATH=/usr/local/include >>>>> ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8 >>>>> ANT_HOME=/usr/sfw >>>>> ALT_OUTPUTDIR=/scratch/wang/java_tm_7 >>>>> DEV_ONLY=true >>>>> DEBUG=true >>>>> >>>>> I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin >>>>> directory. I would like to set a break point at >>>>> hotspot/src/cpu/sparc/vm/assembler_sparc.cpp >>>>> MacroAssembler::compiler_lock_object function. I have tried to use the >>>>> dbx pathmap command but it doesn't seem to help dbx to locate the >>>>> source file or the function definition. >>>>> Any suggestions? Thanks in advance for any comment. >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! > -- Regards James Wang From neo