From john.coomes at oracle.com Sat Oct 1 04:52:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 01 Oct 2011 11:52:43 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20111001115255.4477447B1F@hg.openjdk.java.net> Changeset: 3f0cf875af83 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3f0cf875af83 Added tag jdk8-b06 for changeset 0db80d8e77fc ! .hgtags Changeset: 0663e7617095 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0663e7617095 Added tag jdk8-b07 for changeset 3f0cf875af83 ! .hgtags Changeset: da883b9e6d37 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/da883b9e6d37 Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 49ed7eacfd16 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/49ed7eacfd16 Added tag hs23-b01 for changeset da883b9e6d37 ! .hgtags Changeset: 95607b70acb5 Author: jcoomes Date: 2011-09-30 22:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/95607b70acb5 7096124: Bump the hs23 build number to 02 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From coleen.phillimore at oracle.com Mon Oct 3 08:02:16 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 03 Oct 2011 11:02:16 -0400 Subject: class file reconstitutor / LVT In-Reply-To: <4E8782C3.4070605@oracle.com> References: <4E8712D6.5000300@oracle.com> <4E8751E8.6000609@oracle.com> <4E8782C3.4070605@oracle.com> Message-ID: <4E89CE78.2050003@oracle.com> Hi Thomas, I was going to answer over the weekend but had to check on something. I like the idea of cutting down the patch size with the LVT change and (hopefully) the RC_TRACE change a lot. To check things into openjdk there are new rules (which I can't find exactly) which says you have to have someone check in something for you 8 times, then you're a committer and then someone has to check in something 32 times before you're a reviewer. Anyway, I think you need to send Mark.Reinhold at oracle.com your openjdk user name and some secret ssh code so that you can check things in. And then you get on this list: http://db.openjdk.java.net/people Mark probably wont' respond right away because he's at JavaOne. In the meantime, you can send out a code review as a patch file to: hotspot-dev at openjdk.java.net There are ways to get webrevs out to the openjdk list but you have to have the secret password and name first. Thanks, Coleen On 10/1/2011 5:14 PM, Thomas Wuerthinger wrote: > Coleen, > > could you please brief me on how to proceed on this? What is the > required process for pushing the patch for the LVT bug fix to the > OpenJDK repo. Should this be done by you or can I do it somehow > myself? This small and simple patch might be the right way to get me > introduced to the process. > > Cutting down on the final patch size is probably a good idea (if it is > not a too painful process to get a smaller changeset in). So we might > consider gradually bringing the changes to other parts of the VM in > place before doing the final swap of the jvmtiRedefineClasses.cpp/hpp > files. > > - thomas > > > On 10/1/11 7:46 PM, Daniel D. Daugherty wrote: >> Makes sense to me... >> >> For the LVT bug, here is a bug that can be used: >> >> 7064927 4/3 retransformClasses() does not pass in LocalVariableTable >> of a method >> >> to track the issue... >> >> Dan >> >> >> On 10/1/11 7:17 AM, Thomas Wuerthinger wrote: >>> Coleen, Dan, >>> >>> I'm currently doing some further patch clean up. During that I found >>> the changes to jvmtiClassFileReconstitutor that are basically just >>> the addition of the LVT (local variable table) to the class file >>> reconstitutor and resolve the comment "FIXME: for now no LVT" (patch >>> in the attachment). Does it make sense to commit things like that >>> separately in advance in order to reduce the size of the final >>> enhanced class redefinition patch? >>> >>> @Coleen: It could also make sense to create a separate patch that >>> replaces the TRACE_RANGE with the new tracing, because this would >>> significantly reduce the number of touched files of the full class >>> redefinition patch. >>> >>> - thomas > From drazzib at drazzib.com Mon Oct 3 15:45:18 2011 From: drazzib at drazzib.com (Damien Raude-Morvan) Date: Tue, 4 Oct 2011 00:45:18 +0200 Subject: [patch] Fix hotspot build failures on s390 (linux + 32bits) Message-ID: <201110040045.19233.drazzib@drazzib.com> Hi, Hotspot makes some assumptions about size_t, depending on the architecture (32bit/64bit), which doesn't work on s390 (32bit) but works under s390x (64bit). The fix is to add casts to size_t, as already done in other places. Failure on s390 : https://buildd.debian.org/status/logs.php?pkg=openjdk-7&ver=7~b147-2.0~pre6-1&arch=s390 Success on s390x : http://buildd.debian- ports.org/status/logs.php?pkg=openjdk-7&ver=7~b147-2.0~pre6-1&arch=s390x **hotspot-s390.diff** : Old patch [1] from Mathias (but didn't seems to get merged in icedtea7- forest). gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp | 2 - gc_implementation/g1/concurrentMark.cpp | 6 +-- gc_implementation/g1/g1CollectedHeap.cpp | 2 - gc_implementation/g1/heapRegionRemSet.cpp | 2 - gc_implementation/parNew/parNewGeneration.cpp | 2 - gc_implementation/parallelScavenge/parMarkBitMap.cpp | 2 - memory/collectorPolicy.cpp | 16 +++++----- oops/objArrayKlass.inline.hpp | 4 +- runtime/arguments.cpp | 2 - utilities/bitMap.inline.hpp | 4 +- 10 files changed, 21 insertions(+), 21 deletions(-) **s390_hotspot_fix.diff** : Fix others FTBFS on s390. methodLiveness.cpp | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011- July/015041.html Cheers, -- Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: s390_hotspot_fix.diff Type: text/x-patch Size: 3477 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111004/a6ee5a1d/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: hotspot-s390.diff Type: text/x-patch Size: 10121 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111004/a6ee5a1d/attachment-0001.bin From x.resolute at gmail.com Tue Oct 4 14:01:05 2011 From: x.resolute at gmail.com (Resolute) Date: Wed, 5 Oct 2011 05:01:05 +0800 Subject: No subject Message-ID: From tony.printezis at oracle.com Thu Oct 6 14:52:27 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Thu, 06 Oct 2011 21:52:27 +0000 Subject: hg: hsx/hotspot-main/hotspot: 16 new changesets Message-ID: <20111006215300.0465D47C56@hg.openjdk.java.net> Changeset: 4f93f0d00802 Author: tonyp Date: 2011-09-20 09:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4f93f0d00802 7059019: G1: add G1 support to the SA Summary: Extend the SA to recognize the G1CollectedHeap and implement any code that's needed by our serviceability tools (jmap, jinfo, jstack, etc.) that depend on the SA. Reviewed-by: never, poonam, johnc ! agent/make/Makefile + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegion.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! make/sa.files ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 663cb89032b1 Author: johnc Date: 2011-09-20 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/663cb89032b1 7092412: G1: Some roots not marked during an initial mark that gets an evacuation failure Summary: As a result of the changes for 7080389, an evacuation failure during an initial mark pause may result in some root objects not being marked. Pass whether the caller is a root scanning closure into the evacuation failure handling code so that the thread that successfully forwards an object to itself also marks the object. Reviewed-by: ysr, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 114e52976463 Author: tonyp Date: 2011-09-21 01:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/114e52976463 7045232: G1: pool names are inconsistent with other collectors (don't have 'Space') Summary: Make sure the eden and survivor pools have "Space" in their name. Reviewed-by: jmasa, ysr ! src/share/vm/services/g1MemoryPool.cpp Changeset: 1847b501ae74 Author: johnc Date: 2011-09-21 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1847b501ae74 7068215: G1: Print reference processing time during remark Summary: Displays the elapsed time taken to perform reference processing during remark as part of the PrintGCDetails output. Reviewed-by: ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d912b598c6c3 Author: tonyp Date: 2011-09-21 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d912b598c6c3 7091032: G1: assert failure when NewRatio is used Summary: The desired min / max heap sizes are miscalculated at initialization when NewRatio is used. The changeset also includes an additional small change to turn a print statement into a warning. Reviewed-by: johnc, jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 5cc33133bc6d Author: johnc Date: 2011-09-21 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5cc33133bc6d 7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header output Summary: Cast HeapRegion::GrainBytes to size_t in output statement. Reviewed-by: ysr, brutisso, pbk, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: f0ecbe78fc7b Author: tonyp Date: 2011-09-22 07:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f0ecbe78fc7b 7092238: G1: Uninitialized field gc_efficiency in G1PrintRegionLivenessInfo output Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4dfb2df418f2 Author: johnc Date: 2011-09-22 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4dfb2df418f2 6484982: G1: process references during evacuation pauses Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate. Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/thread.cpp Changeset: 8229bd737950 Author: tonyp Date: 2011-09-23 16:07 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8229bd737950 7075646: G1: fix inconsistencies in the monitoring data Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat. Reviewed-by: jmasa, brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: e807478bf9ca Author: brutisso Date: 2011-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e807478bf9ca 7091366: re-enable quicksort tests Summary: Added extern "C" to make it build with JDK6 compilers Reviewed-by: jwilhelm, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 273b46400613 Author: johnc Date: 2011-09-28 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/273b46400613 7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835 Summary: Some objects may not be marked in the event of an evacuation failure in a partially young GC, during a marking cycle. Avoid this situation by not allowing partially young GCs during a marking cycle. Reviewed-by: tonyp, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 811ec3d0833b Author: johnc Date: 2011-10-03 12:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/811ec3d0833b 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 81aa07130d30 Author: tonyp Date: 2011-10-03 19:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/81aa07130d30 7097048: G1: extend the G1 SA changes to print per-heap space information Reviewed-by: brutisso, johnc ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: c63b928b212b Author: stefank Date: 2011-09-12 16:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c63b928b212b 7021322: assert(object_end <= top()) failed: Object crosses promotion LAB boundary Summary: Pass the same object size value to both allocate and unallocate_object Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp Changeset: 65a8ff39a6da Author: johnc Date: 2011-10-05 08:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/65a8ff39a6da 7095194: G1: HeapRegion::GrainBytes, GrainWords, and CardsPerRegion should be size_t Summary: Declare GrainBytes, GrainWords, and CardsPerRegion as size_t. Reviewed-by: jcoomes, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: fd65bc7c09b6 Author: tonyp Date: 2011-10-06 13:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd65bc7c09b6 Merge ! agent/make/Makefile ! make/sa.files ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp From tom.rodriguez at oracle.com Thu Oct 6 14:57:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 6 Oct 2011 14:57:10 -0700 Subject: review for 7098528: crash with java -XX:+ExtendedDTraceProbes Message-ID: http://cr.openjdk.java.net/~never/7098528 61 lines changed: 46 ins; 12 del; 3 mod; 6107 unchg 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: The problem is that the dtrace and jvmti code asks for the size of the java.lang.Class instance before we've set the oop_size. We could just pass the size argument down through the various interfaces but that seems fragile. Instead I changed the initialization path for Class instances to setup the indirections earlier so that the dtrace paths work correctly. Tested with failing command from bug report. From vladimir.kozlov at oracle.com Thu Oct 6 15:26:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 06 Oct 2011 15:26:37 -0700 Subject: review for 7098528: crash with java -XX:+ExtendedDTraceProbes In-Reply-To: References: Message-ID: <4E8E2B1D.7070300@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7098528 > 61 lines changed: 46 ins; 12 del; 3 mod; 6107 unchg > > 7098528: crash with java -XX:+ExtendedDTraceProbes > Reviewed-by: > > The problem is that the dtrace and jvmti code asks for the size of the > java.lang.Class instance before we've set the oop_size. We could just > pass the size argument down through the various interfaces but that > seems fragile. Instead I changed the initialization path for Class > instances to setup the indirections earlier so that the dtrace paths > work correctly. Tested with failing command from bug report. > From tom.rodriguez at oracle.com Thu Oct 6 15:56:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 6 Oct 2011 15:56:21 -0700 Subject: review for 7098528: crash with java -XX:+ExtendedDTraceProbes In-Reply-To: <4E8E2B1D.7070300@oracle.com> References: <4E8E2B1D.7070300@oracle.com> Message-ID: Thanks for the reviews. tom On Oct 6, 2011, at 3:26 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7098528 >> 61 lines changed: 46 ins; 12 del; 3 mod; 6107 unchg >> 7098528: crash with java -XX:+ExtendedDTraceProbes >> Reviewed-by: >> The problem is that the dtrace and jvmti code asks for the size of the >> java.lang.Class instance before we've set the oop_size. We could just >> pass the size argument down through the various interfaces but that >> seems fragile. Instead I changed the initialization path for Class >> instances to setup the indirections earlier so that the dtrace paths >> work correctly. Tested with failing command from bug report. From wynne.wang at oracle.com Sun Oct 9 23:50:49 2011 From: wynne.wang at oracle.com (wynne.wang) Date: Mon, 10 Oct 2011 14:50:49 +0800 Subject: Fwd: large jar file failed In-Reply-To: <4E9177AD.2080203@oracle.com> References: <4E9177AD.2080203@oracle.com> Message-ID: <4E9295C9.7020101@oracle.com> Hi Experts I need help to solve a JDK issue. It is easy to repeat, one created a jar file > 2GB , and it failed to run. By the deeper investigation, I found the error was thrown from the SelectVersion() method in JVM . Inside the openjdk source code(/share/bin/java.c), I found some interesting notes as: * A NOTE TO DEVELOPERS: For performance reasons it is important that * the program image remain relatively small until after SelectVersion * CreateExecutionEnvironment have finished their possibly recursive * processing. Watch everything, but resist all temptations to use Java * interfaces. OK, the fact is , now there is a jar file> 2GB , and if it could pass the SelectVersion() check in JVM? Or any advice ? Thanks Wynne From wynne.wang at oracle.com Sun Oct 9 03:30:05 2011 From: wynne.wang at oracle.com (wynne.wang) Date: Sun, 09 Oct 2011 18:30:05 +0800 Subject: Fwd: large jar file failed Message-ID: <4E9177AD.2080203@oracle.com> Hi Experts I need help to solve a JDK issue. It is easy to repeat, one created a jar file > 2GB , and it failed to run. By the deeper investigation, I found the error was thrown from the SelectVersion() method in JVM . Inside the openjdk source code(/share/bin/java.c), I found some interesting notes as: * A NOTE TO DEVELOPERS: For performance reasons it is important that * the program image remain relatively small until after SelectVersion * CreateExecutionEnvironment have finished their possibly recursive * processing. Watch everything, but resist all temptations to use Java * interfaces. OK, the fact is , now there is a jar file >2GB , and if it could pass the SelectVersion() check in JVM? Or any advice ? Thanks Wynne From david.holmes at oracle.com Sun Oct 9 20:22:13 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Oct 2011 13:22:13 +1000 Subject: Fwd: large jar file failed In-Reply-To: <4E9177AD.2080203@oracle.com> References: <4E9177AD.2080203@oracle.com> Message-ID: <4E9264E5.2050001@oracle.com> I've bcc'ed the hotspot lists and redirected this to serviceability as this is a launcher issue not a JVM issue. On 9/10/2011 8:30 PM, wynne.wang wrote: > Hi Experts > > I need help to solve a JDK issue. > > It is easy to repeat, one created a jar file> 2GB , and it failed to run. > > By the deeper investigation, I found the error was thrown from the > SelectVersion() method in JVM . What was the error? I suspect it may have been EOVERFLOW as the jar file was not opened with O_LARGEFILE set. David Holmes ------------ > > Inside the openjdk source code(/share/bin/java.c), I found some > interesting notes as: > > * A NOTE TO DEVELOPERS: For performance reasons it is important that > * the program image remain relatively small until after SelectVersion > * CreateExecutionEnvironment have finished their possibly recursive > * processing. Watch everything, but resist all temptations to use Java > * interfaces. > > OK, the fact is , now there is a jar file>2GB , and if it could pass > the SelectVersion() check in JVM? > Or any advice ? > > Thanks > > Wynne > > > From wynne.wang at oracle.com Sun Oct 9 23:48:28 2011 From: wynne.wang at oracle.com (wynne.wang) Date: Mon, 10 Oct 2011 14:48:28 +0800 Subject: Fwd: large jar file failed In-Reply-To: <4E9177AD.2080203@oracle.com> References: <4E9177AD.2080203@oracle.com> Message-ID: <4E92953C.8040404@oracle.com> Hi Experts > I need help to solve a JDK issue. > > It is easy to repeat, one created a jar file > 2GB , and it failed to run. > > By the deeper investigation, I found the error was thrown from the > SelectVersion() method in JVM . > > Inside the openjdk source code(/share/bin/java.c), I found some > interesting notes as: > > * A NOTE TO DEVELOPERS: For performance reasons it is important that > * the program image remain relatively small until after SelectVersion > * CreateExecutionEnvironment have finished their possibly recursive > * processing. Watch everything, but resist all temptations to use Java > * interfaces. > > OK, the fact is , now there is a jar file >2GB , and if it could pass > the SelectVersion() check in JVM? > Or any advice ? > > Thanks > > Wynne > > > From daniel.daugherty at oracle.com Tue Oct 11 10:34:09 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Oct 2011 11:34:09 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) Message-ID: <4E947E11.6070004@oracle.com> Greetings, Tom R shepherded the the BSD Port into HotSpot Express 23 using: 7089790 integrate bsd-port changes and I'm following up on that work using the following bug: 7098194 integrate macosx-port changes The synopsis is a bit off. In reality, the 7098194changeset will include additional changes from the BSD Port in addition the deltas made by the MacOS X Port. The bsd-port/hotspot tip changeset for this resync is: changeset: 2729:f1a18ada5853 tag: tip user: Greg Lewis date: Wed Sep 21 22:29:10 2011 -0700 summary: . Finish removing hsearch_r. The macosx-port/hotspot changeset for this merge is: changeset: 2756:69de8d34a370 tag: tip user: swingler at apple.com date: Thu Sep 29 18:10:16 2011 -0700 summary: Adding JAVA_LIBRARY_PATH for bundled app launching (avoids stomping DYLD_LIBRARY_PATH) The focus of 7098194 is to get the MacOS X port into HSX-23 without regressing the non-MacOS X platforms. In other words, we're trying to get HSX-23 caught up with the BSD Port and MacOS X Port projects. Shaking out the MacOS X Port itself will be done with other changesets on an as needed basis. Just to be clear, the push target for this changeset is the RT_Baseline sub-repo of HotSpot Express (currently HSX-23): http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot Like what Tom did for 7089790, I'm posting multiple webrevs so folks can review these changes in different ways. My primary focus here is the common or shared code so I'm less worried about the BSD or MacOS X specific changes. Obviously, if you see something I messed up in those files, I'd like to know. Here's the webrev for all the changes in one shot: http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ The order of the files in the above webrev is the same as for for the subset webrevs below. Here's the webrevs for the changes in subsets: http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ The above webrev has the changes to the bsd-port/hotspot repo made after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ The above webrev has the non-Dtrace and non-infrastructure changes made for the MacOS X port. There's a couple of files that also contain Dtrace related changes, but I decided it was better to include those files in this subset. http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ The above webrev has almost all of the changes to enable Dtrace on MacOS X (a couple of files are in the macosx-other-code subset). On MacOS X, a newer version of Dtrace is implemented than on Solaris which is why the code is #ifdef'ed. I had to change the original #ifdef'ing because the original implementation had put some non-Dtrace code into #ifdef USDT1 ... #endif blocks so the code didn't build on non-Solaris platforms. In order to be more clean with #ifdef'ing, I redid all MacOS X Dtrace #ifdef'ing in the following forms: #ifndef USDT2 #else /* USDT2 */ #endif /* USDT2 */ #ifndef USDT2 #endif /* ! USDT2 */ Yes, I realize that the MacOS X Dtrace implementation does not follow HotSpot style guidelines very consistently, but I decided not to fix that so I could diff against the macosx-port/hotspot more reliably. I have to consult with Keith McGuigan about how to migrate the Solaris Dtrace implementation to the newer version. However, that work will be done independently of this bug (7098194). http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ The above webrev has all the infrastructure (e.g., Makefile) related changes. Many/most folks aren't interested in Makefile stuff so I've put these changes in their own subset. Of course, I need Kelly O'Hair to bless these changes... Builds done so far: - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo Testing done so far: - Serviceability stack (25 subsuites): VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, logging, mm SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, misc_attach, misc_jvmstat, misc_tools - Tested configs (8 configs) {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} - MacOS X builds have only had minimal 'java -version' type testing, i.e., did the build "work"? No regressions have been seen in the Solaris X86 testing and WinXP testing should be finished later today. Things still to do (in no particular order): - gather the list of contributors for the changeset comment - JPRT test jobs when the JPRT-hotspotwest queue settles down - dtrace testing on Solaris X86 - code review - start bring up of more formal dev testing on MacOS X Thanks, in advance, for any review comments. Dan From daniel.daugherty at oracle.com Tue Oct 11 10:55:46 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Oct 2011 11:55:46 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E947E11.6070004@oracle.com> References: <4E947E11.6070004@oracle.com> Message-ID: <4E948322.30009@oracle.com> Why is that right after you send out a webrev, you see an error that you somehow read past and missed? http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/src/os_cpu/bsd_x86/vm/bsd_x86_32.s.frames.html Tom R had fixed the original changes to use p2align instead of align and I accidentally reverted that change. I will fix that. That file also has several changes like: @@ -260,11 +270,11 @@ jz 4f cmpl $32,%ecx jbe 2f # <= 32 dwords rep; smovl jmp 4f - .=.+8 + .space 8 2: subl %esi,%edi .p2align 4,,15 3: movl (%esi),%edx movl %edx,(%edi,%esi,1) subl $4,%esi and I would love to know if those are OK to leave in... Thanks. Dan On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: > Greetings, > > Tom R shepherded the the BSD Port into HotSpot Express 23 using: > > 7089790 integrate bsd-port changes > > and I'm following up on that work using the following bug: > > 7098194 integrate macosx-port changes > > The synopsis is a bit off. In reality, the 7098194changeset will > include additional changes from the BSD Port in addition the deltas > made by the MacOS X Port. The bsd-port/hotspot tip changeset for > this resync is: > > changeset: 2729:f1a18ada5853 > tag: tip > user: Greg Lewis > date: Wed Sep 21 22:29:10 2011 -0700 > summary: . Finish removing hsearch_r. > > The macosx-port/hotspot changeset for this merge is: > > changeset: 2756:69de8d34a370 > tag: tip > user: swingler at apple.com > date: Thu Sep 29 18:10:16 2011 -0700 > summary: Adding JAVA_LIBRARY_PATH for bundled app launching > (avoids stomping DYLD_LIBRARY_PATH) > > The focus of 7098194 is to get the MacOS X port into HSX-23 without > regressing the non-MacOS X platforms. In other words, we're trying > to get HSX-23 caught up with the BSD Port and MacOS X Port projects. > Shaking out the MacOS X Port itself will be done with other changesets > on an as needed basis. > > Just to be clear, the push target for this changeset is the RT_Baseline > sub-repo of HotSpot Express (currently HSX-23): > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot > > Like what Tom did for 7089790, I'm posting multiple webrevs so folks > can review these changes in different ways. My primary focus here is > the common or shared code so I'm less worried about the BSD or MacOS X > specific changes. Obviously, if you see something I messed up in those > files, I'd like to know. > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ > > The order of the files in the above webrev is the same as for > for the subset webrevs below. > > Here's the webrevs for the changes in subsets: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ > > > The above webrev has the changes to the bsd-port/hotspot repo made > after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ > > > The above webrev has the non-Dtrace and non-infrastructure changes > made for the MacOS X port. There's a couple of files that also > contain > Dtrace related changes, but I decided it was better to include those > files in this subset. > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ > > > The above webrev has almost all of the changes to enable Dtrace on > MacOS X (a couple of files are in the macosx-other-code subset). > On MacOS X, a newer version of Dtrace is implemented than on Solaris > which is why the code is #ifdef'ed. I had to change the original > #ifdef'ing because the original implementation had put some > non-Dtrace > code into #ifdef USDT1 ... #endif blocks so the code didn't build on > non-Solaris platforms. In order to be more clean with #ifdef'ing, I > redid all MacOS X Dtrace #ifdef'ing in the following forms: > > #ifndef USDT2 > > > > #else /* USDT2 */ > > #endif /* USDT2 */ > > #ifndef USDT2 > > > #endif /* ! USDT2 */ > > Yes, I realize that the MacOS X Dtrace implementation does not follow > HotSpot style guidelines very consistently, but I decided not to fix > that so I could diff against the macosx-port/hotspot more reliably. > > I have to consult with Keith McGuigan about how to migrate the > Solaris > Dtrace implementation to the newer version. However, that work > will be > done independently of this bug (7098194). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ > > > The above webrev has all the infrastructure (e.g., Makefile) related > changes. Many/most folks aren't interested in Makefile stuff so I've > put these changes in their own subset. Of course, I need Kelly O'Hair > to bless these changes... > > Builds done so far: > > - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} > - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} > - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new > HSX repo > - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX > repo > > Testing done so far: > > - Serviceability stack (25 subsuites): > VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, > logging, mm > SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, > mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, > misc_attach, misc_jvmstat, misc_tools > - Tested configs (8 configs) > {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} > > - MacOS X builds have only had minimal 'java -version' type testing, > i.e., did the build "work"? > > No regressions have been seen in the Solaris X86 testing and WinXP > testing should be finished later today. > > Things still to do (in no particular order): > > - gather the list of contributors for the changeset comment > - JPRT test jobs when the JPRT-hotspotwest queue settles down > - dtrace testing on Solaris X86 > - code review > - start bring up of more formal dev testing on MacOS X > > Thanks, in advance, for any review comments. > > Dan > > From vladimir.kozlov at oracle.com Tue Oct 11 11:58:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Oct 2011 11:58:10 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E947E11.6070004@oracle.com> References: <4E947E11.6070004@oracle.com> Message-ID: <4E9491C2.9090005@oracle.com> Dan, In agent/src/os/bsd/symtab.c why parenthesis were removed?: - struct elf_symbol* sym = &(symtab->symbols[n]); + struct elf_symbol* sym = &symtab->symbols[n]; Why new Dtrace implementation for MacOS X use 2 lines where it is not needed (a lot of places)? For example: +#else /* USDT2 */ + HOTSPOT_GC_END( +); +#endif /* USDT2 */ Is this what you called "does not follow HotSpot style guidelines very consistently"? Next file miss copyright header: src/share/vm/utilities/dtrace_usdt2_disabled.hpp.html BSD makefiles use COMPILER_WARNINGS_FATAL which is not defined anywhere. And other platforms do not use it. Thanks, Vladimir Daniel D. Daugherty wrote: > Greetings, > > Tom R shepherded the the BSD Port into HotSpot Express 23 using: > > 7089790 integrate bsd-port changes > > and I'm following up on that work using the following bug: > > 7098194 integrate macosx-port changes > > The synopsis is a bit off. In reality, the 7098194changeset will > include additional changes from the BSD Port in addition the deltas > made by the MacOS X Port. The bsd-port/hotspot tip changeset for > this resync is: > > changeset: 2729:f1a18ada5853 > tag: tip > user: Greg Lewis > date: Wed Sep 21 22:29:10 2011 -0700 > summary: . Finish removing hsearch_r. > > The macosx-port/hotspot changeset for this merge is: > > changeset: 2756:69de8d34a370 > tag: tip > user: swingler at apple.com > date: Thu Sep 29 18:10:16 2011 -0700 > summary: Adding JAVA_LIBRARY_PATH for bundled app launching > (avoids stomping DYLD_LIBRARY_PATH) > > The focus of 7098194 is to get the MacOS X port into HSX-23 without > regressing the non-MacOS X platforms. In other words, we're trying > to get HSX-23 caught up with the BSD Port and MacOS X Port projects. > Shaking out the MacOS X Port itself will be done with other changesets > on an as needed basis. > > Just to be clear, the push target for this changeset is the RT_Baseline > sub-repo of HotSpot Express (currently HSX-23): > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot > > Like what Tom did for 7089790, I'm posting multiple webrevs so folks > can review these changes in different ways. My primary focus here is > the common or shared code so I'm less worried about the BSD or MacOS X > specific changes. Obviously, if you see something I messed up in those > files, I'd like to know. > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ > > The order of the files in the above webrev is the same as for > for the subset webrevs below. > > Here's the webrevs for the changes in subsets: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ > > > The above webrev has the changes to the bsd-port/hotspot repo made > after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ > > > The above webrev has the non-Dtrace and non-infrastructure changes > made for the MacOS X port. There's a couple of files that also contain > Dtrace related changes, but I decided it was better to include those > files in this subset. > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ > > > The above webrev has almost all of the changes to enable Dtrace on > MacOS X (a couple of files are in the macosx-other-code subset). > On MacOS X, a newer version of Dtrace is implemented than on Solaris > which is why the code is #ifdef'ed. I had to change the original > #ifdef'ing because the original implementation had put some non-Dtrace > code into #ifdef USDT1 ... #endif blocks so the code didn't build on > non-Solaris platforms. In order to be more clean with #ifdef'ing, I > redid all MacOS X Dtrace #ifdef'ing in the following forms: > > #ifndef USDT2 > > > > #else /* USDT2 */ > > #endif /* USDT2 */ > > #ifndef USDT2 > > > #endif /* ! USDT2 */ > > Yes, I realize that the MacOS X Dtrace implementation does not follow > HotSpot style guidelines very consistently, but I decided not to fix > that so I could diff against the macosx-port/hotspot more reliably. > > I have to consult with Keith McGuigan about how to migrate the Solaris > Dtrace implementation to the newer version. However, that work will be > done independently of this bug (7098194). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ > > > The above webrev has all the infrastructure (e.g., Makefile) related > changes. Many/most folks aren't interested in Makefile stuff so I've > put these changes in their own subset. Of course, I need Kelly O'Hair > to bless these changes... > > Builds done so far: > > - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} > - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} > - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX > repo > - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo > > Testing done so far: > > - Serviceability stack (25 subsuites): > VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, > logging, mm > SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, > mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, > misc_attach, misc_jvmstat, misc_tools > - Tested configs (8 configs) > {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} > > - MacOS X builds have only had minimal 'java -version' type testing, > i.e., did the build "work"? > > No regressions have been seen in the Solaris X86 testing and WinXP > testing should be finished later today. > > Things still to do (in no particular order): > > - gather the list of contributors for the changeset comment > - JPRT test jobs when the JPRT-hotspotwest queue settles down > - dtrace testing on Solaris X86 > - code review > - start bring up of more formal dev testing on MacOS X > > Thanks, in advance, for any review comments. > > Dan > From astrange at apple.com Tue Oct 11 12:21:32 2011 From: astrange at apple.com (Alexander Strange) Date: Tue, 11 Oct 2011 15:21:32 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E948322.30009@oracle.com> References: <4E947E11.6070004@oracle.com> <4E948322.30009@oracle.com> Message-ID: <328D9FAE-3CBC-46BB-9270-A49EA09A6B81@apple.com> I made the .space change in order to support our Clang compiler, which has its own integrated assembler that doesn't accept '.=.+'. GAS accepts '.=.+8' and '.space' interchangeably, so I don't think this should cause problems for you. Some other Makefile changes (accepting CC/CC32/COMPILER_WARNINGS_FATAL from the environment) are also there to test Clang support. However, llvm-gcc is the default compiler, so those changes don't need to be accepted for hotspot to build on OS X. On Oct 11, 2011, at 1:55 PM, Daniel D. Daugherty wrote: > Why is that right after you send out a webrev, you see an error > that you somehow read past and missed? > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/src/os_cpu/bsd_x86/vm/bsd_x86_32.s.frames.html > > Tom R had fixed the original changes to use p2align instead of > align and I accidentally reverted that change. I will fix that. > > That file also has several changes like: > > @@ -260,11 +270,11 @@ > jz 4f > cmpl $32,%ecx > jbe 2f # <= 32 dwords > rep; smovl > jmp 4f > - .=.+8 > + .space 8 > 2: subl %esi,%edi > .p2align 4,,15 > 3: movl (%esi),%edx > movl %edx,(%edi,%esi,1) > subl $4,%esi > > and I would love to know if those are OK to leave in... > > Thanks. > > Dan > > > On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the Solaris >> Dtrace implementation to the newer version. However, that work will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> >> From paul.hohensee at oracle.com Tue Oct 11 12:44:23 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 11 Oct 2011 15:44:23 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E9491C2.9090005@oracle.com> References: <4E947E11.6070004@oracle.com> <4E9491C2.9090005@oracle.com> Message-ID: <4E949C97.7090202@oracle.com> On 10/11/11 2:58 PM, Vladimir Kozlov wrote: > Dan, > > In agent/src/os/bsd/symtab.c why parenthesis were removed?: > > - struct elf_symbol* sym = &(symtab->symbols[n]); > + struct elf_symbol* sym = &symtab->symbols[n]; A matter of readability perhaps. The parens are redundant: -> binds more closely than &. > > > Why new Dtrace implementation for MacOS X use 2 lines where it is not > needed (a lot of places)? For example: > > +#else /* USDT2 */ > + HOTSPOT_GC_END( > +); > +#endif /* USDT2 */ > > Is this what you called "does not follow HotSpot style guidelines very > consistently"? I'm ok with fixing that (the style issue) later, as long as it does get fixed. Use of the macro preprocessor is the devil, unless we absolutely, positively have no choice. :) Paul > > > Next file miss copyright header: > > src/share/vm/utilities/dtrace_usdt2_disabled.hpp.html > > > BSD makefiles use COMPILER_WARNINGS_FATAL which is not defined > anywhere. And other platforms do not use it. > > Thanks, > Vladimir > > Daniel D. Daugherty wrote: >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also >> contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some >> non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not >> follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the >> Solaris >> Dtrace implementation to the newer version. However, that work >> will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly >> O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >> HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >> repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> From daniel.daugherty at oracle.com Tue Oct 11 13:06:11 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Oct 2011 14:06:11 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E9491C2.9090005@oracle.com> References: <4E947E11.6070004@oracle.com> <4E9491C2.9090005@oracle.com> Message-ID: <4E94A1B3.3090507@oracle.com> Vladimir, Thanks for the fast review! Replies are in-line below... On 10/11/11 12:58 PM, Vladimir Kozlov wrote: > Dan, > > In agent/src/os/bsd/symtab.c why parenthesis were removed?: > > - struct elf_symbol* sym = &(symtab->symbols[n]); > + struct elf_symbol* sym = &symtab->symbols[n]; Good catch! It looks like I mis-merged that change. I have fixed it. > Why new Dtrace implementation for MacOS X use 2 lines where it is not > needed (a lot of places)? For example: > > +#else /* USDT2 */ > + HOTSPOT_GC_END( > +); > +#endif /* USDT2 */ > > Is this what you called "does not follow HotSpot style guidelines very > consistently"? Yup! I fixed all that formatting stuff in one version of my port and then I threw it all away when I realized that I couldn't easily see if I made any mis-merges... > Next file miss copyright header: > > src/share/vm/utilities/dtrace_usdt2_disabled.hpp.html Added the missing copyright header and also added the missing nested include protection. > BSD makefiles use COMPILER_WARNINGS_FATAL which is not defined anywhere. I believe it is used by build invocation outside the HSX repo. > And other platforms do not use it. Yup! And I'm not sure I want to add support for it to the other platforms. I don't want to encourage anyone to disable compiler warnings being fatal on platform that we've already gotten clean. That said, this logic (COMPILER_WARNINGS_FATAL) is likely to change when the build revamp work arrives in JDK8. Dan > > Thanks, > Vladimir > > Daniel D. Daugherty wrote: >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also >> contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some >> non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not >> follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the >> Solaris >> Dtrace implementation to the newer version. However, that work >> will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly >> O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >> HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >> repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> From daniel.daugherty at oracle.com Tue Oct 11 13:11:24 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Oct 2011 14:11:24 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E949C97.7090202@oracle.com> References: <4E947E11.6070004@oracle.com> <4E9491C2.9090005@oracle.com> <4E949C97.7090202@oracle.com> Message-ID: <4E94A2EC.50102@oracle.com> On 10/11/11 1:44 PM, Paul Hohensee wrote: > On 10/11/11 2:58 PM, Vladimir Kozlov wrote: >> Dan, >> >> In agent/src/os/bsd/symtab.c why parenthesis were removed?: >> >> - struct elf_symbol* sym = &(symtab->symbols[n]); >> + struct elf_symbol* sym = &symtab->symbols[n]; > > A matter of readability perhaps. The parens are redundant: -> binds > more closely than &. I'm changing it to what Tom had (i.e., with parens) to reduce the noise in the diffs. > >> Why new Dtrace implementation for MacOS X use 2 lines where it is not >> needed (a lot of places)? For example: >> >> +#else /* USDT2 */ >> + HOTSPOT_GC_END( >> +); >> +#endif /* USDT2 */ >> >> Is this what you called "does not follow HotSpot style guidelines >> very consistently"? > > I'm ok with fixing that (the style issue) later, as long as it does > get fixed. Use of the > macro preprocessor is the devil, unless we absolutely, positively have > no choice. :) I can promise that a bug will get filed to track the whole issue of migrating from USDT1 -> USDT2. Included in that bug will be a note about the style issues. That's the best I can say at the moment. Dan > > Paul > >> >> >> Next file miss copyright header: >> >> src/share/vm/utilities/dtrace_usdt2_disabled.hpp.html >> >> >> BSD makefiles use COMPILER_WARNINGS_FATAL which is not defined >> anywhere. And other platforms do not use it. >> >> Thanks, >> Vladimir >> >> Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also >>> contain >>> Dtrace related changes, but I decided it was better to include >>> those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on >>> Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some >>> non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>> build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not >>> follow >>> HotSpot style guidelines very consistently, but I decided not to >>> fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the >>> Solaris >>> Dtrace implementation to the newer version. However, that work >>> will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> >>> The above webrev has all the infrastructure (e.g., Makefile) >>> related >>> changes. Many/most folks aren't interested in Makefile stuff so >>> I've >>> put these changes in their own subset. Of course, I need Kelly >>> O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>> jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>> HSX repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>> HSX repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> From rhoover at apple.com Tue Oct 11 13:25:14 2011 From: rhoover at apple.com (roger hoover) Date: Tue, 11 Oct 2011 14:25:14 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E9491C2.9090005@oracle.com> References: <4E947E11.6070004@oracle.com> <4E9491C2.9090005@oracle.com> Message-ID: I did the USDT2 implementation with some mechanical tools and a lot of by-hand followup. My intension was to leave the structure of the USDT1 macro calls in place. Most of the USDT2 changes are a smallish delta on the USDT1 macro calls. If we were to have macro-in-a-macro capabilities, we could implement this small difference with another macro. Fortunately for sanity's sake, macros-in-macros don't work well in the C preprocessor, and I had to duplicate the entire macro call. If Oracle moves the Solaris implementation from USDT1 to USDT2, then by all means the USDT2 code should be cleaned up. On the other hand, if the USDT1 implementation is to live on, any formatting changes should enhance the ability to make consistent modifications to both USDT1 and USDT2. roger On Oct 11, 2011, at 12:58 PM, Vladimir Kozlov wrote: > Dan, > > Why new Dtrace implementation for MacOS X use 2 lines where it is not needed (a lot of places)? For example: > > +#else /* USDT2 */ > + HOTSPOT_GC_END( > +); > +#endif /* USDT2 */ > > Is this what you called "does not follow HotSpot style guidelines very consistently"? > > Thanks, > Vladimir > > Daniel D. Daugherty wrote: >> Greetings, >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> 7089790 integrate bsd-port changes >> and I'm following up on that work using the following bug: >> 7098194 integrate macosx-port changes >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> The macosx-port/hotspot changeset for this merge is: >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> Here's the webrev for all the changes in one shot: >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> Here's the webrevs for the changes in subsets: >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> Yes, I realize that the MacOS X Dtrace implementation does not follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> I have to consult with Keith McGuigan about how to migrate the Solaris >> Dtrace implementation to the newer version. However, that work will be >> done independently of this bug (7098194). >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly O'Hair >> to bless these changes... >> Builds done so far: >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >> Testing done so far: >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> Things still to do (in no particular order): >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> Thanks, in advance, for any review comments. >> Dan From vladimir.kozlov at oracle.com Tue Oct 11 13:59:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Oct 2011 13:59:59 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E94A1B3.3090507@oracle.com> References: <4E947E11.6070004@oracle.com> <4E9491C2.9090005@oracle.com> <4E94A1B3.3090507@oracle.com> Message-ID: <4E94AE4F.4010506@oracle.com> Thank you, Dan I agree for this round we should leave new Dtrace amd Mikefiles code as it is. Thank you, Alexander and Roger for explaining these changes. Regards, Vladimir Daniel D. Daugherty wrote: > Vladimir, > > Thanks for the fast review! > > Replies are in-line below... > > > On 10/11/11 12:58 PM, Vladimir Kozlov wrote: >> Dan, >> >> In agent/src/os/bsd/symtab.c why parenthesis were removed?: >> >> - struct elf_symbol* sym = &(symtab->symbols[n]); >> + struct elf_symbol* sym = &symtab->symbols[n]; > > Good catch! It looks like I mis-merged that change. > > I have fixed it. > > >> Why new Dtrace implementation for MacOS X use 2 lines where it is not >> needed (a lot of places)? For example: >> >> +#else /* USDT2 */ >> + HOTSPOT_GC_END( >> +); >> +#endif /* USDT2 */ >> >> Is this what you called "does not follow HotSpot style guidelines very >> consistently"? > > Yup! I fixed all that formatting stuff in one version of my port > and then I threw it all away when I realized that I couldn't > easily see if I made any mis-merges... > > >> Next file miss copyright header: >> >> src/share/vm/utilities/dtrace_usdt2_disabled.hpp.html > > Added the missing copyright header and also added the missing > nested include protection. > > >> BSD makefiles use COMPILER_WARNINGS_FATAL which is not defined anywhere. > > I believe it is used by build invocation outside the HSX repo. > > >> And other platforms do not use it. > > Yup! And I'm not sure I want to add support for it to the other > platforms. I don't want to encourage anyone to disable compiler > warnings being fatal on platform that we've already gotten clean. > > That said, this logic (COMPILER_WARNINGS_FATAL) is likely to > change when the build revamp work arrives in JDK8. > > Dan > > > > >> >> Thanks, >> Vladimir >> >> Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also >>> contain >>> Dtrace related changes, but I decided it was better to include those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some >>> non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not >>> follow >>> HotSpot style guidelines very consistently, but I decided not to fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the >>> Solaris >>> Dtrace implementation to the newer version. However, that work >>> will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> >>> The above webrev has all the infrastructure (e.g., Makefile) related >>> changes. Many/most folks aren't interested in Makefile stuff so I've >>> put these changes in their own subset. Of course, I need Kelly >>> O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>> HSX repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >>> repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> From paul.hohensee at oracle.com Tue Oct 11 14:05:57 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 11 Oct 2011 17:05:57 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E94AE4F.4010506@oracle.com> References: <4E947E11.6070004@oracle.com> <4E9491C2.9090005@oracle.com> <4E94A1B3.3090507@oracle.com> <4E94AE4F.4010506@oracle.com> Message-ID: <4E94AFB5.2030001@oracle.com> Ditto for me. On 10/11/11 4:59 PM, Vladimir Kozlov wrote: > Thank you, Dan > > I agree for this round we should leave new Dtrace amd Mikefiles code > as it is. > Thank you, Alexander and Roger for explaining these changes. > > Regards, > Vladimir > > Daniel D. Daugherty wrote: >> Vladimir, >> >> Thanks for the fast review! >> >> Replies are in-line below... >> >> >> On 10/11/11 12:58 PM, Vladimir Kozlov wrote: >>> Dan, >>> >>> In agent/src/os/bsd/symtab.c why parenthesis were removed?: >>> >>> - struct elf_symbol* sym = &(symtab->symbols[n]); >>> + struct elf_symbol* sym = &symtab->symbols[n]; >> >> Good catch! It looks like I mis-merged that change. >> >> I have fixed it. >> >> >>> Why new Dtrace implementation for MacOS X use 2 lines where it is >>> not needed (a lot of places)? For example: >>> >>> +#else /* USDT2 */ >>> + HOTSPOT_GC_END( >>> +); >>> +#endif /* USDT2 */ >>> >>> Is this what you called "does not follow HotSpot style guidelines >>> very consistently"? >> >> Yup! I fixed all that formatting stuff in one version of my port >> and then I threw it all away when I realized that I couldn't >> easily see if I made any mis-merges... >> >> >>> Next file miss copyright header: >>> >>> src/share/vm/utilities/dtrace_usdt2_disabled.hpp.html >> >> Added the missing copyright header and also added the missing >> nested include protection. >> >> >>> BSD makefiles use COMPILER_WARNINGS_FATAL which is not defined >>> anywhere. >> >> I believe it is used by build invocation outside the HSX repo. >> >> >>> And other platforms do not use it. >> >> Yup! And I'm not sure I want to add support for it to the other >> platforms. I don't want to encourage anyone to disable compiler >> warnings being fatal on platform that we've already gotten clean. >> >> That said, this logic (COMPILER_WARNINGS_FATAL) is likely to >> change when the build revamp work arrives in JDK8. >> >> Dan >> >> >> >> >>> >>> Thanks, >>> Vladimir >>> >>> Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>> >>>> 7089790 integrate bsd-port changes >>>> >>>> and I'm following up on that work using the following bug: >>>> >>>> 7098194 integrate macosx-port changes >>>> >>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>> include additional changes from the BSD Port in addition the deltas >>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>> this resync is: >>>> >>>> changeset: 2729:f1a18ada5853 >>>> tag: tip >>>> user: Greg Lewis >>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>> summary: . Finish removing hsearch_r. >>>> >>>> The macosx-port/hotspot changeset for this merge is: >>>> >>>> changeset: 2756:69de8d34a370 >>>> tag: tip >>>> user: swingler at apple.com >>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>> (avoids stomping DYLD_LIBRARY_PATH) >>>> >>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>> regressing the non-MacOS X platforms. In other words, we're trying >>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>> Shaking out the MacOS X Port itself will be done with other changesets >>>> on an as needed basis. >>>> >>>> Just to be clear, the push target for this changeset is the >>>> RT_Baseline >>>> sub-repo of HotSpot Express (currently HSX-23): >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>> >>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>> can review these changes in different ways. My primary focus here is >>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>> specific changes. Obviously, if you see something I messed up in those >>>> files, I'd like to know. >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>> >>>> The order of the files in the above webrev is the same as for >>>> for the subset webrevs below. >>>> >>>> Here's the webrevs for the changes in subsets: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>> >>>> >>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>> >>>> >>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>> made for the MacOS X port. There's a couple of files that also >>>> contain >>>> Dtrace related changes, but I decided it was better to include >>>> those >>>> files in this subset. >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>> >>>> >>>> The above webrev has almost all of the changes to enable Dtrace on >>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>> On MacOS X, a newer version of Dtrace is implemented than on >>>> Solaris >>>> which is why the code is #ifdef'ed. I had to change the original >>>> #ifdef'ing because the original implementation had put some >>>> non-Dtrace >>>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>>> build on >>>> non-Solaris platforms. In order to be more clean with >>>> #ifdef'ing, I >>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> >>>> #else /* USDT2 */ >>>> >>>> #endif /* USDT2 */ >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> #endif /* ! USDT2 */ >>>> >>>> Yes, I realize that the MacOS X Dtrace implementation does not >>>> follow >>>> HotSpot style guidelines very consistently, but I decided not >>>> to fix >>>> that so I could diff against the macosx-port/hotspot more >>>> reliably. >>>> >>>> I have to consult with Keith McGuigan about how to migrate the >>>> Solaris >>>> Dtrace implementation to the newer version. However, that work >>>> will be >>>> done independently of this bug (7098194). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>> >>>> >>>> The above webrev has all the infrastructure (e.g., Makefile) >>>> related >>>> changes. Many/most folks aren't interested in Makefile stuff so >>>> I've >>>> put these changes in their own subset. Of course, I need Kelly >>>> O'Hair >>>> to bless these changes... >>>> >>>> Builds done so far: >>>> >>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>> jvmg} >>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>> HSX repo >>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>>> HSX repo >>>> >>>> Testing done so far: >>>> >>>> - Serviceability stack (25 subsuites): >>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>> logging, mm >>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>> misc_attach, misc_jvmstat, misc_tools >>>> - Tested configs (8 configs) >>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>> >>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>> i.e., did the build "work"? >>>> >>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>> testing should be finished later today. >>>> >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>> - dtrace testing on Solaris X86 >>>> - code review >>>> - start bring up of more formal dev testing on MacOS X >>>> >>>> Thanks, in advance, for any review comments. >>>> >>>> Dan >>>> From keith.mcguigan at oracle.com Tue Oct 11 14:18:55 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 11 Oct 2011 17:18:55 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: References: <4E947E11.6070004@oracle.com> <4E9491C2.9090005@oracle.com> Message-ID: FWIW, I believe the build platform for jdk7 is Solaris 10, which does support USDT2, as far as I know. So if we can convert to use USDT2 all the time and drop the USDT1 code, that would be good. -- - Keith On Oct 11, 2011, at 4:25 PM, roger hoover wrote: > I did the USDT2 implementation with some mechanical tools and a lot > of by-hand followup. My intension was to leave the structure of the > USDT1 macro calls in place. Most of the USDT2 changes are a > smallish delta on the USDT1 macro calls. If we were to have macro- > in-a-macro capabilities, we could implement this small difference > with another macro. > > Fortunately for sanity's sake, macros-in-macros don't work well in > the C preprocessor, and I had to duplicate the entire macro call. > If Oracle moves the Solaris implementation from USDT1 to USDT2, then > by all means the USDT2 code should be cleaned up. On the other > hand, if the USDT1 implementation is to live on, any formatting > changes should enhance the ability to make consistent modifications > to both USDT1 and USDT2. > > roger > > On Oct 11, 2011, at 12:58 PM, Vladimir Kozlov wrote: > >> Dan, >> >> Why new Dtrace implementation for MacOS X use 2 lines where it is >> not needed (a lot of places)? For example: >> >> +#else /* USDT2 */ >> + HOTSPOT_GC_END( >> +); >> +#endif /* USDT2 */ >> >> Is this what you called "does not follow HotSpot style guidelines >> very consistently"? >> >> Thanks, >> Vladimir >> >> Daniel D. Daugherty wrote: >>> Greetings, >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> 7089790 integrate bsd-port changes >>> and I'm following up on that work using the following bug: >>> 7098194 integrate macosx-port changes >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> The macosx-port/hotspot changeset for this merge is: >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other >>> changesets >>> on an as needed basis. >>> Just to be clear, the push target for this changeset is the >>> RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or >>> MacOS X >>> specific changes. Obviously, if you see something I messed up in >>> those >>> files, I'd like to know. >>> Here's the webrev for all the changes in one shot: >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> Here's the webrevs for the changes in subsets: >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> The above webrev has the changes to the bsd-port/hotspot repo >>> made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> The above webrev has the non-Dtrace and non-infrastructure >>> changes >>> made for the MacOS X port. There's a couple of files that also >>> contain >>> Dtrace related changes, but I decided it was better to include >>> those >>> files in this subset. >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> The above webrev has almost all of the changes to enable >>> Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on >>> Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some non- >>> Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>> build on >>> non-Solaris platforms. In order to be more clean with >>> #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> Yes, I realize that the MacOS X Dtrace implementation does not >>> follow >>> HotSpot style guidelines very consistently, but I decided not to >>> fix >>> that so I could diff against the macosx-port/hotspot more >>> reliably. >>> I have to consult with Keith McGuigan about how to migrate the >>> Solaris >>> Dtrace implementation to the newer version. However, that work >>> will be >>> done independently of this bug (7098194). >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> The above webrev has all the infrastructure (e.g., Makefile) >>> related >>> changes. Many/most folks aren't interested in Makefile stuff so >>> I've >>> put these changes in their own subset. Of course, I need Kelly >>> O'Hair >>> to bless these changes... >>> Builds done so far: >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>> jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with >>> new HSX repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>> HSX repo >>> Testing done so far: >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> Things still to do (in no particular order): >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> Thanks, in advance, for any review comments. >>> Dan > From daniel.daugherty at oracle.com Tue Oct 11 20:37:06 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Oct 2011 21:37:06 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E947E11.6070004@oracle.com> References: <4E947E11.6070004@oracle.com> Message-ID: <4E950B62.8070504@oracle.com> On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: > Things still to do (in no particular order): > > - gather the list of contributors for the changeset comment Here's the list of folks that Tom used for the BSD-port push: Kurt Miller Greg Lewis Jung-uk Kim Christos Zoulas Landon Fuller The FreeBSD Foundation Michael Franz Roger Hoover Alexander Strange Since I'm syncing with bsd-port/hotspot in addition to merging in macosx-port/hotspot, should I use the same list of folks? > - JPRT test jobs when the JPRT-hotspotwest queue settles down JPRT-hotspotwest test job with '-release jdk7' passed. JPRT-hotspotwest test job with '-release jdk8' is in the queue. > - dtrace testing on Solaris X86 I didn't have JDK8-B08 baseline test results for dtrace, but I do now: Results dir: vm-dtrace-prod-client-fast-comp.solaris-i586 executed: 333 passed: 329 ignored: 0 failed: 4 time: 14 minute(s) Results dir: vm-dtrace-prod-client-fast-mixed.solaris-i586 executed: 333 passed: 328 ignored: 0 failed: 5 time: 14 minute(s) Results dir: vm-dtrace-prod-client-prod-comp.solaris-i586 executed: 333 passed: 320 ignored: 0 failed: 13 time: 11 minute(s) Results dir: vm-dtrace-prod-client-prod-mixed.solaris-i586 executed: 333 passed: 319 ignored: 0 failed: 14 time: 10 minute(s) Results dir: vm-dtrace-prod-server-fast-comp.solaris-i586 executed: 333 passed: 329 ignored: 0 failed: 4 time: 17 minute(s) Results dir: vm-dtrace-prod-server-fast-mixed.solaris-i586 executed: 333 passed: 328 ignored: 0 failed: 5 time: 16 minute(s) Results dir: vm-dtrace-prod-server-prod-comp.solaris-i586 executed: 333 passed: 320 ignored: 0 failed: 13 time: 12 minute(s) Results dir: vm-dtrace-prod-server-prod-mixed.solaris-i586 executed: 333 passed: 319 ignored: 0 failed: 14 time: 11 minute(s) Summary of Test Results (8 result dirs) ========================================= all executed: 2664 all passed: 2592 all ignored: 0 all failed: 72 time: 1 hour(s) 45 minute(s) so no unexpected failures in the baseline. Here are the results with the MacOS X port bits on Solaris X86: Results dir: vm-dtrace-prod-client_bh_mac_os_x_port_dcubed-fast-comp.solaris-i586 executed: 333 passed: 329 ignored: 0 failed: 4 time: 14 minute(s) Results dir: vm-dtrace-prod-client_bh_mac_os_x_port_dcubed-fast-mixed.solaris-i586 executed: 333 passed: 328 ignored: 0 failed: 5 time: 14 minute(s) Results dir: vm-dtrace-prod-client_bh_mac_os_x_port_dcubed-prod-comp.solaris-i586 executed: 333 passed: 320 ignored: 0 failed: 13 time: 11 minute(s) Results dir: vm-dtrace-prod-client_bh_mac_os_x_port_dcubed-prod-mixed.solaris-i586 executed: 333 passed: 319 ignored: 0 failed: 14 time: 10 minute(s) Results dir: vm-dtrace-prod-server_bh_mac_os_x_port_dcubed-fast-comp.solaris-i586 executed: 333 passed: 329 ignored: 0 failed: 4 time: 20 minute(s) Results dir: vm-dtrace-prod-server_bh_mac_os_x_port_dcubed-fast-mixed.solaris-i586 executed: 333 passed: 328 ignored: 0 failed: 5 time: 16 minute(s) Results dir: vm-dtrace-prod-server_bh_mac_os_x_port_dcubed-prod-comp.solaris-i586 executed: 333 passed: 320 ignored: 0 failed: 13 time: 12 minute(s) Results dir: vm-dtrace-prod-server_bh_mac_os_x_port_dcubed-prod-mixed.solaris-i586 executed: 333 passed: 319 ignored: 0 failed: 14 time: 11 minute(s) Summary of Test Results (8 result dirs) ========================================= all executed: 2664 all passed: 2592 all ignored: 0 all failed: 72 time: 1 hour(s) 48 minute(s) > - code review Complete review from Vladimir. Paul H. is doing a complete review. Several of the folks that did the original work have chimed in and answered questions. Is there anyone else doing a code review for whom I should wait? Dan > - start bring up of more formal dev testing on MacOS X From david.holmes at oracle.com Tue Oct 11 21:48:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Oct 2011 14:48:14 +1000 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E947E11.6070004@oracle.com> References: <4E947E11.6070004@oracle.com> Message-ID: <4E951C0E.2060900@oracle.com> Hi Dan, src/cpu/x86/vm/jni_x86.h I don't understand why this change would be needed: ! #if defined(_LP64) && !defined(__APPLE__) typedef long jlong; #else typedef long long jlong; #endif this is saying that on "apple" under _LP64 a long is not 64-bits. But the very definition of LP64 is that longs and pointers are 64-bits. ??? --- src/os//vm/os_.cpp + void os::set_native_thread_name(const char *name) { + // Not yet implemented. + return; + } I hate seeing "shared" code that is not implemented on 3 out of 4 supported platforms. Though it seems Linux will also support pthread_setname_np as of March 2010 (not sure which kernel or glibc versions needed). If not for the fact this also adds an exported JVM method to set the native thread name, we could otherwise bury this in the platform specific native thread creation code (which might also obviate the need for the new _is_attached logic - see next point). I also wonder what Java code is using this new JVM API? Also wondering where the "current thread only" restriction came about? --- src/share/vm/runtime/thread.hpp + // Remember whether or not we were attached + bool _is_attached; It took me a while to realize that _is_attached really means "was attached" ie that the Java thread came about due to a native thread attaching to the VM via JNI attachCurrentThread. Could I suggest this is renamed to was_attached? --- src/share/vm/utilities/debug.cpp Why are we exposing this debug code in a product build? --- src/share/vm/prims/jni.cpp The USDT2 ifdef changes are truly ugly especially in this file. Is there no way to hide USDT1 vs USDT2 at a lower level so that the top-level probe points are not affected? I know this is flagged for "future work" but history shows such cleans ups rarely if ever happen - and this current code really is pretty awful to look at. Cheers, David On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: > Greetings, > > Tom R shepherded the the BSD Port into HotSpot Express 23 using: > > 7089790 integrate bsd-port changes > > and I'm following up on that work using the following bug: > > 7098194 integrate macosx-port changes > > The synopsis is a bit off. In reality, the 7098194changeset will > include additional changes from the BSD Port in addition the deltas > made by the MacOS X Port. The bsd-port/hotspot tip changeset for > this resync is: > > changeset: 2729:f1a18ada5853 > tag: tip > user: Greg Lewis > date: Wed Sep 21 22:29:10 2011 -0700 > summary: . Finish removing hsearch_r. > > The macosx-port/hotspot changeset for this merge is: > > changeset: 2756:69de8d34a370 > tag: tip > user: swingler at apple.com > date: Thu Sep 29 18:10:16 2011 -0700 > summary: Adding JAVA_LIBRARY_PATH for bundled app launching > (avoids stomping DYLD_LIBRARY_PATH) > > The focus of 7098194 is to get the MacOS X port into HSX-23 without > regressing the non-MacOS X platforms. In other words, we're trying > to get HSX-23 caught up with the BSD Port and MacOS X Port projects. > Shaking out the MacOS X Port itself will be done with other changesets > on an as needed basis. > > Just to be clear, the push target for this changeset is the RT_Baseline > sub-repo of HotSpot Express (currently HSX-23): > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot > > Like what Tom did for 7089790, I'm posting multiple webrevs so folks > can review these changes in different ways. My primary focus here is > the common or shared code so I'm less worried about the BSD or MacOS X > specific changes. Obviously, if you see something I messed up in those > files, I'd like to know. > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ > > The order of the files in the above webrev is the same as for > for the subset webrevs below. > > Here's the webrevs for the changes in subsets: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ > > > The above webrev has the changes to the bsd-port/hotspot repo made > after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ > > > The above webrev has the non-Dtrace and non-infrastructure changes > made for the MacOS X port. There's a couple of files that also contain > Dtrace related changes, but I decided it was better to include those > files in this subset. > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ > > > The above webrev has almost all of the changes to enable Dtrace on > MacOS X (a couple of files are in the macosx-other-code subset). > On MacOS X, a newer version of Dtrace is implemented than on Solaris > which is why the code is #ifdef'ed. I had to change the original > #ifdef'ing because the original implementation had put some non-Dtrace > code into #ifdef USDT1 ... #endif blocks so the code didn't build on > non-Solaris platforms. In order to be more clean with #ifdef'ing, I > redid all MacOS X Dtrace #ifdef'ing in the following forms: > > #ifndef USDT2 > > > > #else /* USDT2 */ > > #endif /* USDT2 */ > > #ifndef USDT2 > > > #endif /* ! USDT2 */ > > Yes, I realize that the MacOS X Dtrace implementation does not follow > HotSpot style guidelines very consistently, but I decided not to fix > that so I could diff against the macosx-port/hotspot more reliably. > > I have to consult with Keith McGuigan about how to migrate the Solaris > Dtrace implementation to the newer version. However, that work will be > done independently of this bug (7098194). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ > > > The above webrev has all the infrastructure (e.g., Makefile) related > changes. Many/most folks aren't interested in Makefile stuff so I've > put these changes in their own subset. Of course, I need Kelly O'Hair > to bless these changes... > > Builds done so far: > > - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} > - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} > - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX > repo > - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo > > Testing done so far: > > - Serviceability stack (25 subsuites): > VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, > logging, mm > SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, > mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, > misc_attach, misc_jvmstat, misc_tools > - Tested configs (8 configs) > {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} > > - MacOS X builds have only had minimal 'java -version' type testing, > i.e., did the build "work"? > > No regressions have been seen in the Solaris X86 testing and WinXP > testing should be finished later today. > > Things still to do (in no particular order): > > - gather the list of contributors for the changeset comment > - JPRT test jobs when the JPRT-hotspotwest queue settles down > - dtrace testing on Solaris X86 > - code review > - start bring up of more formal dev testing on MacOS X > > Thanks, in advance, for any review comments. > > Dan > From daniel.daugherty at oracle.com Wed Oct 12 08:48:23 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 09:48:23 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E951C0E.2060900@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> Message-ID: <4E95B6C7.6000103@oracle.com> David, Thanks for the thorough review (as always). Replies embedded below. On 10/11/11 10:48 PM, David Holmes wrote: > Hi Dan, > > src/cpu/x86/vm/jni_x86.h > > I don't understand why this change would be needed: > > ! #if defined(_LP64) && !defined(__APPLE__) > typedef long jlong; > #else > typedef long long jlong; > #endif > > this is saying that on "apple" under _LP64 a long is not 64-bits. But > the very definition of LP64 is that longs and pointers are 64-bits. ??? $ cat sizes.c #include int main() { printf("Hello world! _LP64="); #ifdef _LP64 printf("%d\n", _LP64); #else printf("undefined\n"); #endif printf("sizeof(long) = %d\n", (int) sizeof(long)); printf("sizeof(long long) = %d\n", (int) sizeof(long long)); } Output on my MacOS 10.6.8 machine: Hello world! _LP64=1 sizeof(long) = 8 sizeof(long long) = 8 Output on my Solaris X86 machine: Hello world! _LP64=undefined sizeof(long) = 4 sizeof(long long) = 8 Output on my Solaris X86 machine when built with '-m64': Hello world! _LP64=1 sizeof(long) = 8 sizeof(long long) = 8 Since __APPLE__ machines have a 8 byte long, I don't understand why the person thought that "long long jlong" was necessary... We need an Apple person to jump in here... > src/os//vm/os_.cpp > > + void os::set_native_thread_name(const char *name) { > + // Not yet implemented. > + return; > + } > > I hate seeing "shared" code that is not implemented on 3 out of 4 > supported platforms. Though it seems Linux will also support > pthread_setname_np as of March 2010 (not sure which kernel or glibc > versions needed). If not for the fact this also adds an exported JVM > method to set the native thread name, we could otherwise bury this in > the platform specific native thread creation code (which might also > obviate the need for the new _is_attached logic - see next point). I > also wonder what Java code is using this new JVM API? I suspect that this new API is used by other pieces of the MacOS X port project, but I don't know that for sure. Again, we need an Apple person to jump in here. > Also wondering where the "current thread only" restriction came about? If the API is restricted to the "current thread", then we don't have to worry about races and locking. Also, I'm wondering why there is no return code. > src/share/vm/runtime/thread.hpp > > + // Remember whether or not we were attached > + bool _is_attached; > > It took me a while to realize that _is_attached really means "was > attached" ie that the Java thread came about due to a native thread > attaching to the VM via JNI attachCurrentThread. Could I suggest this > is renamed to was_attached? I was taking another look at this. The key user of the new flag is: src/share/vm/prims/jvm.cpp JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject jthread, jstring n ame)) JVMWrapper("JVM_SetNativeThreadName"); ResourceMark rm(THREAD); oop java_thread = JNIHandles::resolve_non_null(jthread); JavaThread* thr = java_lang_Thread::thread(java_thread); // Thread naming only supported for the current thread, doesn't work for // target threads. if (Thread::current() == thr && !thr->is_attached()) { // we don't set the name of an attached thread to avoid stepping // on other programs const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::reso lve_non_null(name)); os::set_native_thread_name(thread_name); } JVM_END which is coded to not set the name of a thread that has been attached. In the JavaThread(bool) constructor: _is_attached = _is_attaching = is_attaching; we set both flags to the "is_attaching" parameter (default false) so if we're coming down the JNI attach path, that parameter should be true so we set both flags to true. After the thread has been properly attached, we call set_attached() which sets the _is_attaching flag to false. Whew! In the JavaThread(ThreadFunction, size_t) constructor we set both flags to false because we're not attaching... and we didn't come down the JNI attach path. I don't like the "was attached" attribute and I no longer like the "is attaching" and "is attached" attributes either. Sigh. I think both fields need to be cleaned up and renamed. Perhaps something like: is_attaching_via_jni was_attached_via_jni would be more clear? > src/share/vm/utilities/debug.cpp > > Why are we exposing this debug code in a product build? We'll need an Apple person to jump in here... > src/share/vm/prims/jni.cpp > > The USDT2 ifdef changes are truly ugly especially in this file. Is > there no way to hide USDT1 vs USDT2 at a lower level so that the > top-level probe points are not affected? I know this is flagged for > "future work" but history shows such cleans ups rarely if ever happen > - and this current code really is pretty awful to look at. Yes, the #ifdef'ing makes the current code awful. I don't think anyone will dispute that observation. The better solution would be for Solaris to migrate to USDT2. I'm discussing that with Keith McGuigan. However, I don't want to take much of his time right now because he is hip deep in another alligator swamp at the moment. The best I can offer at the moment is filing a new bug to track the future work. Yes, I know that clean up type work rarely gets done, but this merge with the MacOS X port project needs to get into HSX-23 as soon as possible. Broken functionality in the other platforms is a stopper, but ugly is not a stopper. Thanks again for the thorough review. Dan > > Cheers, > David > > On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the Solaris >> Dtrace implementation to the newer version. However, that work will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX >> repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >> repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> From rhoover at apple.com Wed Oct 12 08:59:10 2011 From: rhoover at apple.com (roger hoover) Date: Wed, 12 Oct 2011 09:59:10 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E95B6C7.6000103@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> Message-ID: <69FEDCBF-206E-4899-8A31-2DBFC202FED1@apple.com> This is likely due to the fprintf format usage mess. The hotspot code had assumed that any 64-bit fprintf format could be used with any 64-bit value. Apple compilers give warnings if you print a long with "%lld", and insists upon "%ld" for a clean compile even though both are 64-bit values. Changing the type to long long allows the format to remain unchanged. The correct way to fix this mess is to insure that the formats exactly match the types used. We couldn't pull this off at apple since we didn't have the capabilities to build under all of the other os platforms to test the changes. roger On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: > David, > > Thanks for the thorough review (as always). Replies embedded below. > > > On 10/11/11 10:48 PM, David Holmes wrote: >> Hi Dan, >> >> src/cpu/x86/vm/jni_x86.h >> >> I don't understand why this change would be needed: >> >> ! #if defined(_LP64) && !defined(__APPLE__) >> typedef long jlong; >> #else >> typedef long long jlong; >> #endif >> >> this is saying that on "apple" under _LP64 a long is not 64-bits. But the very definition of LP64 is that longs and pointers are 64-bits. ??? > > $ cat sizes.c > #include > > int main() { > printf("Hello world! _LP64="); > #ifdef _LP64 > printf("%d\n", _LP64); > #else > printf("undefined\n"); > #endif > printf("sizeof(long) = %d\n", (int) sizeof(long)); > printf("sizeof(long long) = %d\n", (int) sizeof(long long)); > } > > Output on my MacOS 10.6.8 machine: > > Hello world! _LP64=1 > sizeof(long) = 8 > sizeof(long long) = 8 > > Output on my Solaris X86 machine: > > Hello world! _LP64=undefined > sizeof(long) = 4 > sizeof(long long) = 8 > > Output on my Solaris X86 machine when built with '-m64': > > Hello world! _LP64=1 > sizeof(long) = 8 > sizeof(long long) = 8 > > Since __APPLE__ machines have a 8 byte long, I don't understand > why the person thought that "long long jlong" was necessary... > > We need an Apple person to jump in here... > > >> src/os//vm/os_.cpp >> >> + void os::set_native_thread_name(const char *name) { >> + // Not yet implemented. >> + return; >> + } >> >> I hate seeing "shared" code that is not implemented on 3 out of 4 supported platforms. Though it seems Linux will also support pthread_setname_np as of March 2010 (not sure which kernel or glibc versions needed). If not for the fact this also adds an exported JVM method to set the native thread name, we could otherwise bury this in the platform specific native thread creation code (which might also obviate the need for the new _is_attached logic - see next point). I also wonder what Java code is using this new JVM API? > > I suspect that this new API is used by other pieces of the MacOS X > port project, but I don't know that for sure. Again, we need an > Apple person to jump in here. > > >> Also wondering where the "current thread only" restriction came about? > > If the API is restricted to the "current thread", then we don't have > to worry about races and locking. Also, I'm wondering why there is no > return code. > > >> src/share/vm/runtime/thread.hpp >> >> + // Remember whether or not we were attached >> + bool _is_attached; >> >> It took me a while to realize that _is_attached really means "was attached" ie that the Java thread came about due to a native thread attaching to the VM via JNI attachCurrentThread. Could I suggest this is renamed to was_attached? > > I was taking another look at this. The key user of the new flag is: > > src/share/vm/prims/jvm.cpp > > JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject jthread, jstring n > ame)) > JVMWrapper("JVM_SetNativeThreadName"); > ResourceMark rm(THREAD); > oop java_thread = JNIHandles::resolve_non_null(jthread); > JavaThread* thr = java_lang_Thread::thread(java_thread); > // Thread naming only supported for the current thread, doesn't work for > // target threads. > if (Thread::current() == thr && !thr->is_attached()) { > // we don't set the name of an attached thread to avoid stepping > // on other programs > const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::reso > lve_non_null(name)); > os::set_native_thread_name(thread_name); > } > JVM_END > > which is coded to not set the name of a thread that has been > attached. In the JavaThread(bool) constructor: > > _is_attached = _is_attaching = is_attaching; > > we set both flags to the "is_attaching" parameter (default false) > so if we're coming down the JNI attach path, that parameter > should be true so we set both flags to true. After the thread > has been properly attached, we call set_attached() which sets > the _is_attaching flag to false. Whew! > > In the JavaThread(ThreadFunction, size_t) constructor we set > both flags to false because we're not attaching... and we > didn't come down the JNI attach path. > > I don't like the "was attached" attribute and I no longer like > the "is attaching" and "is attached" attributes either. Sigh. > I think both fields need to be cleaned up and renamed. Perhaps > something like: > > is_attaching_via_jni > was_attached_via_jni > > would be more clear? > > >> src/share/vm/utilities/debug.cpp >> >> Why are we exposing this debug code in a product build? > > We'll need an Apple person to jump in here... > > >> src/share/vm/prims/jni.cpp >> >> The USDT2 ifdef changes are truly ugly especially in this file. Is there no way to hide USDT1 vs USDT2 at a lower level so that the top-level probe points are not affected? I know this is flagged for "future work" but history shows such cleans ups rarely if ever happen - and this current code really is pretty awful to look at. > > Yes, the #ifdef'ing makes the current code awful. I don't think > anyone will dispute that observation. > > The better solution would be for Solaris to migrate to USDT2. > I'm discussing that with Keith McGuigan. However, I don't want > to take much of his time right now because he is hip deep in > another alligator swamp at the moment. > > The best I can offer at the moment is filing a new bug to track > the future work. Yes, I know that clean up type work rarely gets > done, but this merge with the MacOS X port project needs to get > into HSX-23 as soon as possible. Broken functionality in the > other platforms is a stopper, but ugly is not a stopper. > > Thanks again for the thorough review. > > Dan > > >> >> Cheers, >> David >> >> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also contain >>> Dtrace related changes, but I decided it was better to include those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>> HotSpot style guidelines very consistently, but I decided not to fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the Solaris >>> Dtrace implementation to the newer version. However, that work will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> >>> The above webrev has all the infrastructure (e.g., Makefile) related >>> changes. Many/most folks aren't interested in Makefile stuff so I've >>> put these changes in their own subset. Of course, I need Kelly O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX >>> repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> From tom.rodriguez at oracle.com Wed Oct 12 11:27:43 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Oct 2011 11:27:43 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E947E11.6070004@oracle.com> References: <4E947E11.6070004@oracle.com> Message-ID: <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> I'm working on a review and this is what I have so far. I'll send more later. On the issue of the dtrace changes, couldn't we minimize later disruption by moving the USDT1/USDT2 distinction into a header file? For instance, instead of doing this: +#ifndef USDT2 HS_DTRACE_PROBE1(hotspot, thread__sleep__end,0); +#else /* USDT2 */ + HOTSPOT_THREAD_SLEEP_END( + 0); +#endif /* USDT2 */ Couldn't it just have HOTSPOT_THREAD_SLEEP_END(0); with this ifdef in a header somewhere? #ifndef USDT2 #define HOTSPOT_THREAD_SLEEP_END(arg) \ HS_DTRACE_PROBE1(hotspot, thread__sleep__end, (arg)) #endif /* USDT2 */ It minimizes the ugly until we resolve the real issue. I guess the PROBE_DECL stuff will have to be somewhere else too. Anyway, I'm fine with pushing it as is but I wanted to at least mention this. connode.cpp: why is ia64_double_zero being defined? There are no uses of it anywhere. os_bsd.cpp: there's a fix for a minor memory leak in there which should also be fixed in os_linux.cpp: if (v != NULL) { char *t = ld_library_path; /* That's +1 for the colon and +1 for the trailing '\0' */ ld_library_path = (char *) malloc(strlen(v) + 1 + strlen(t) + 1); sprintf(ld_library_path, "%s:%s", v, t); + free(t); } bsd_x86_32.s: This apple fix isn't needed since p2align is already aligning to 16 bytes. In the mac assembler .align is the same as .p2align which is why it's reducing it to 4. - .p2align 4,,15 +#ifdef __APPLE__ + .align 4 +#else + .align 16 +#endif The second alignment change isn't needed because of this: 82 ELF_TYPE(SafeFetch32, at function) 83 .p2align 4,,15 tom On Oct 11, 2011, at 10:34 AM, Daniel D. Daugherty wrote: > Greetings, > > Tom R shepherded the the BSD Port into HotSpot Express 23 using: > > 7089790 integrate bsd-port changes > > and I'm following up on that work using the following bug: > > 7098194 integrate macosx-port changes > > The synopsis is a bit off. In reality, the 7098194changeset will > include additional changes from the BSD Port in addition the deltas > made by the MacOS X Port. The bsd-port/hotspot tip changeset for > this resync is: > > changeset: 2729:f1a18ada5853 > tag: tip > user: Greg Lewis > date: Wed Sep 21 22:29:10 2011 -0700 > summary: . Finish removing hsearch_r. > > The macosx-port/hotspot changeset for this merge is: > > changeset: 2756:69de8d34a370 > tag: tip > user: swingler at apple.com > date: Thu Sep 29 18:10:16 2011 -0700 > summary: Adding JAVA_LIBRARY_PATH for bundled app launching > (avoids stomping DYLD_LIBRARY_PATH) > > The focus of 7098194 is to get the MacOS X port into HSX-23 without > regressing the non-MacOS X platforms. In other words, we're trying > to get HSX-23 caught up with the BSD Port and MacOS X Port projects. > Shaking out the MacOS X Port itself will be done with other changesets > on an as needed basis. > > Just to be clear, the push target for this changeset is the RT_Baseline > sub-repo of HotSpot Express (currently HSX-23): > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot > > Like what Tom did for 7089790, I'm posting multiple webrevs so folks > can review these changes in different ways. My primary focus here is > the common or shared code so I'm less worried about the BSD or MacOS X > specific changes. Obviously, if you see something I messed up in those > files, I'd like to know. > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ > > The order of the files in the above webrev is the same as for > for the subset webrevs below. > > Here's the webrevs for the changes in subsets: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ > > The above webrev has the changes to the bsd-port/hotspot repo made > after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ > > The above webrev has the non-Dtrace and non-infrastructure changes > made for the MacOS X port. There's a couple of files that also contain > Dtrace related changes, but I decided it was better to include those > files in this subset. > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ > > The above webrev has almost all of the changes to enable Dtrace on > MacOS X (a couple of files are in the macosx-other-code subset). > On MacOS X, a newer version of Dtrace is implemented than on Solaris > which is why the code is #ifdef'ed. I had to change the original > #ifdef'ing because the original implementation had put some non-Dtrace > code into #ifdef USDT1 ... #endif blocks so the code didn't build on > non-Solaris platforms. In order to be more clean with #ifdef'ing, I > redid all MacOS X Dtrace #ifdef'ing in the following forms: > > #ifndef USDT2 > > > > #else /* USDT2 */ > > #endif /* USDT2 */ > > #ifndef USDT2 > > > #endif /* ! USDT2 */ > > Yes, I realize that the MacOS X Dtrace implementation does not follow > HotSpot style guidelines very consistently, but I decided not to fix > that so I could diff against the macosx-port/hotspot more reliably. > > I have to consult with Keith McGuigan about how to migrate the Solaris > Dtrace implementation to the newer version. However, that work will be > done independently of this bug (7098194). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ > > The above webrev has all the infrastructure (e.g., Makefile) related > changes. Many/most folks aren't interested in Makefile stuff so I've > put these changes in their own subset. Of course, I need Kelly O'Hair > to bless these changes... > > Builds done so far: > > - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} > - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} > - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo > - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo > > Testing done so far: > > - Serviceability stack (25 subsuites): > VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, > logging, mm > SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, > mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, > misc_attach, misc_jvmstat, misc_tools > - Tested configs (8 configs) > {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} > > - MacOS X builds have only had minimal 'java -version' type testing, > i.e., did the build "work"? > > No regressions have been seen in the Solaris X86 testing and WinXP > testing should be finished later today. > > Things still to do (in no particular order): > > - gather the list of contributors for the changeset comment > - JPRT test jobs when the JPRT-hotspotwest queue settles down > - dtrace testing on Solaris X86 > - code review > - start bring up of more formal dev testing on MacOS X > > Thanks, in advance, for any review comments. > > Dan > From rhoover at apple.com Wed Oct 12 11:34:15 2011 From: rhoover at apple.com (roger hoover) Date: Wed, 12 Oct 2011 12:34:15 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E95B6C7.6000103@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> Message-ID: As I promised Dan earlier this morning....replies embedded: On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: > David, > > Thanks for the thorough review (as always). Replies embedded below. > > > On 10/11/11 10:48 PM, David Holmes wrote: >> Hi Dan, >> >> src/cpu/x86/vm/jni_x86.h >> >> I don't understand why this change would be needed: >> >> ! #if defined(_LP64) && !defined(__APPLE__) >> typedef long jlong; >> #else >> typedef long long jlong; >> #endif >> >> this is saying that on "apple" under _LP64 a long is not 64-bits. But the very definition of LP64 is that longs and pointers are 64-bits. ??? > > $ cat sizes.c > #include > > int main() { > printf("Hello world! _LP64="); > #ifdef _LP64 > printf("%d\n", _LP64); > #else > printf("undefined\n"); > #endif > printf("sizeof(long) = %d\n", (int) sizeof(long)); > printf("sizeof(long long) = %d\n", (int) sizeof(long long)); > } > > Output on my MacOS 10.6.8 machine: > > Hello world! _LP64=1 > sizeof(long) = 8 > sizeof(long long) = 8 > > Output on my Solaris X86 machine: > > Hello world! _LP64=undefined > sizeof(long) = 4 > sizeof(long long) = 8 > > Output on my Solaris X86 machine when built with '-m64': > > Hello world! _LP64=1 > sizeof(long) = 8 > sizeof(long long) = 8 > > Since __APPLE__ machines have a 8 byte long, I don't understand > why the person thought that "long long jlong" was necessary... > > We need an Apple person to jump in here... > (answered before, but here it is again): This is likely due to the fprintf format usage mess. The hotspot code had assumed that any 64-bit fprintf format could be used with any 64-bit value. Apple compilers give warnings if you print a long with "%lld", and insists upon "%ld" for a clean compile even though both are 64-bit values. Changing the type to long long allows the format to remain unchanged. The correct way to fix this mess is to insure that the formats exactly match the types used. We couldn't pull this off at apple since we didn't have the capabilities to build under all of the other os platforms to test the changes. > >> src/os//vm/os_.cpp >> >> + void os::set_native_thread_name(const char *name) { >> + // Not yet implemented. >> + return; >> + } >> >> I hate seeing "shared" code that is not implemented on 3 out of 4 supported platforms. Though it seems Linux will also support pthread_setname_np as of March 2010 (not sure which kernel or glibc versions needed). If not for the fact this also adds an exported JVM method to set the native thread name, we could otherwise bury this in the platform specific native thread creation code (which might also obviate the need for the new _is_attached logic - see next point). I also wonder what Java code is using this new JVM API? > > I suspect that this new API is used by other pieces of the MacOS X > port project, but I don't know that for sure. Again, we need an > Apple person to jump in here. The native thread name addition was a huge win, both for us debugging and for our developer customers. The only complaint we had was from other projects whose code attached to Java and (in initial revisions) had their threads renamed. It is exported so that Thread.java can set the native thread name. I have no explanation for the lack of a return code. I can only surmise that it is an oversight that was not caught by the compiler. The other pieces are: macosx-port/jdk/src/share/native/java/lang/Thread.c: {"getThreads", "()[" THD, (void *)&JVM_GetAllThreads}, {"dumpThreads", "([" THD ")[[" STE, (void *)&JVM_DumpThreads}, --> {"setNativeName", "(" STR ")V", (void *)&JVM_SetNativeThreadName}, }; -and- macosx-port/jdk/src/share/classes/java/lang/Thread.java /** * Changes the name of this thread to be equal to the argument * name. *

* First the checkAccess method of this thread is called * with no arguments. This may result in throwing a * SecurityException. * * @param name the new name for this thread. * @exception SecurityException if the current thread cannot modify this * thread. * @see #getName * @see #checkAccess() */ public final void setName(String name) { checkAccess(); this.name = name.toCharArray(); --> if (threadStatus != 0) { --> setNativeName(name); --> } } > > >> Also wondering where the "current thread only" restriction came about? > > If the API is restricted to the "current thread", then we don't have > to worry about races and locking. Also, I'm wondering why there is no > return code. > > >> src/share/vm/runtime/thread.hpp >> >> + // Remember whether or not we were attached >> + bool _is_attached; >> >> It took me a while to realize that _is_attached really means "was attached" ie that the Java thread came about due to a native thread attaching to the VM via JNI attachCurrentThread. Could I suggest this is renamed to was_attached? > > I was taking another look at this. The key user of the new flag is: > > src/share/vm/prims/jvm.cpp > > JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject jthread, jstring n > ame)) > JVMWrapper("JVM_SetNativeThreadName"); > ResourceMark rm(THREAD); > oop java_thread = JNIHandles::resolve_non_null(jthread); > JavaThread* thr = java_lang_Thread::thread(java_thread); > // Thread naming only supported for the current thread, doesn't work for > // target threads. > if (Thread::current() == thr && !thr->is_attached()) { > // we don't set the name of an attached thread to avoid stepping > // on other programs > const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::reso > lve_non_null(name)); > os::set_native_thread_name(thread_name); > } > JVM_END > > which is coded to not set the name of a thread that has been > attached. In the JavaThread(bool) constructor: > > _is_attached = _is_attaching = is_attaching; > > we set both flags to the "is_attaching" parameter (default false) > so if we're coming down the JNI attach path, that parameter > should be true so we set both flags to true. After the thread > has been properly attached, we call set_attached() which sets > the _is_attaching flag to false. Whew! > > In the JavaThread(ThreadFunction, size_t) constructor we set > both flags to false because we're not attaching... and we > didn't come down the JNI attach path. > > I don't like the "was attached" attribute and I no longer like > the "is attaching" and "is attached" attributes either. Sigh. > I think both fields need to be cleaned up and renamed. Perhaps > something like: > > is_attaching_via_jni > was_attached_via_jni > > would be more clear? > > >> src/share/vm/utilities/debug.cpp >> >> Why are we exposing this debug code in a product build? > > We'll need an Apple person to jump in here... > > It has been an Apple tradition (from long before I joined the Java team in 2004) to include a basic set of debugging routines in product builds. We call them from gdb while debugging problems that don't show up in debug builds, and we've told our developer customers about them. The rest of the Apple port does not depend on these and whether or not to continue Apple's tradition is totally up to Oracle. >> src/share/vm/prims/jni.cpp >> >> The USDT2 ifdef changes are truly ugly especially in this file. Is there no way to hide USDT1 vs USDT2 at a lower level so that the top-level probe points are not affected? I know this is flagged for "future work" but history shows such cleans ups rarely if ever happen - and this current code really is pretty awful to look at. > > Yes, the #ifdef'ing makes the current code awful. I don't think > anyone will dispute that observation. > > The better solution would be for Solaris to migrate to USDT2. > I'm discussing that with Keith McGuigan. However, I don't want > to take much of his time right now because he is hip deep in > another alligator swamp at the moment. > > The best I can offer at the moment is filing a new bug to track > the future work. Yes, I know that clean up type work rarely gets > done, but this merge with the MacOS X port project needs to get > into HSX-23 as soon as possible. Broken functionality in the > other platforms is a stopper, but ugly is not a stopper. > > Thanks again for the thorough review. > > Dan > > >> >> Cheers, >> David >> >> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also contain >>> Dtrace related changes, but I decided it was better to include those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>> HotSpot style guidelines very consistently, but I decided not to fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the Solaris >>> Dtrace implementation to the newer version. However, that work will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> >>> The above webrev has all the infrastructure (e.g., Makefile) related >>> changes. Many/most folks aren't interested in Makefile stuff so I've >>> put these changes in their own subset. Of course, I need Kelly O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX >>> repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> From tom.rodriguez at oracle.com Wed Oct 12 12:34:48 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Oct 2011 12:34:48 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> References: <4E947E11.6070004@oracle.com> <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> Message-ID: On Oct 12, 2011, at 11:27 AM, Tom Rodriguez wrote: > I'm working on a review and this is what I have so far. I'll send more later. Actually this is all I had. > connode.cpp: > > why is ia64_double_zero being defined? There are no uses of it anywhere. Vladimir pointed out that it's used in the existing sources so the change would fix an apparent compilation issue. The code using ia64_double_zero should just go away instead of reintroducing the definition. We can fix that as a separate bug if you like. tom > > os_bsd.cpp: > > there's a fix for a minor memory leak in there which should also be fixed in os_linux.cpp: > > if (v != NULL) { > char *t = ld_library_path; > /* That's +1 for the colon and +1 for the trailing '\0' */ > ld_library_path = (char *) malloc(strlen(v) + 1 + strlen(t) + 1); > sprintf(ld_library_path, "%s:%s", v, t); > + free(t); > } > > bsd_x86_32.s: > > This apple fix isn't needed since p2align is already aligning to 16 bytes. In the mac assembler .align is the same as .p2align which is why it's reducing it to 4. > > - .p2align 4,,15 > +#ifdef __APPLE__ > + .align 4 > +#else > + .align 16 > +#endif > > The second alignment change isn't needed because of this: > > 82 ELF_TYPE(SafeFetch32, at function) > 83 .p2align 4,,15 > > tom > > On Oct 11, 2011, at 10:34 AM, Daniel D. Daugherty wrote: > >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the Solaris >> Dtrace implementation to the newer version. However, that work will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> > From daniel.daugherty at oracle.com Wed Oct 12 13:12:26 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 14:12:26 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> References: <4E947E11.6070004@oracle.com> <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> Message-ID: <4E95F4AA.7050200@oracle.com> On 10/12/11 12:27 PM, Tom Rodriguez wrote: > I'm working on a review and this is what I have so far. I'll send more later. > > On the issue of the dtrace changes, couldn't we minimize later disruption by moving the USDT1/USDT2 distinction into a header file? For instance, instead of doing this: > > +#ifndef USDT2 > > HS_DTRACE_PROBE1(hotspot, thread__sleep__end,0); > > +#else /* USDT2 */ > + HOTSPOT_THREAD_SLEEP_END( > + 0); > +#endif /* USDT2 */ > > Couldn't it just have > > HOTSPOT_THREAD_SLEEP_END(0); > > with this ifdef in a header somewhere? > > #ifndef USDT2 > #define HOTSPOT_THREAD_SLEEP_END(arg) \ > HS_DTRACE_PROBE1(hotspot, thread__sleep__end, (arg)) > #endif /* USDT2 */ > > It minimizes the ugly until we resolve the real issue. I guess the PROBE_DECL stuff will have to be somewhere else too. Anyway, I'm fine with pushing it as is but I wanted to at least mention this. I'll include this in the new bug as a way to phase in the changes from USDT1 -> USDT2. I don't want to make that change now since it will make it more difficult to keep in sync with the MacOS X port project. > connode.cpp: > > why is ia64_double_zero being defined? There are no uses of it anywhere. I saw your newer posting. I'll file a bug for this also. > os_bsd.cpp: > > there's a fix for a minor memory leak in there which should also be fixed in os_linux.cpp: > > if (v != NULL) { > char *t = ld_library_path; > /* That's +1 for the colon and +1 for the trailing '\0' */ > ld_library_path = (char *) malloc(strlen(v) + 1 + strlen(t) + 1); > sprintf(ld_library_path, "%s:%s", v, t); > + free(t); > } Yup. It's on my notes list. > bsd_x86_32.s: > > This apple fix isn't needed since p2align is already aligning to 16 bytes. In the mac assembler .align is the same as .p2align which is why it's reducing it to 4. > > - .p2align 4,,15 > +#ifdef __APPLE__ > + .align 4 > +#else > + .align 16 > +#endif > > The second alignment change isn't needed because of this: > > 82 ELF_TYPE(SafeFetch32, at function) > 83 .p2align 4,,15 I noticed that I screwed that up just after I sent out the review request so it was discussed a bit earlier in this thread. Thanks for the thorough review. Dan > tom > > On Oct 11, 2011, at 10:34 AM, Daniel D. Daugherty wrote: > >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the Solaris >> Dtrace implementation to the newer version. However, that work will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> From daniel.daugherty at oracle.com Wed Oct 12 13:13:56 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 14:13:56 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> Message-ID: <4E95F504.8050405@oracle.com> Roger, Thanks for filling in the blanks! Dan On 10/12/11 12:34 PM, roger hoover wrote: > As I promised Dan earlier this morning....replies embedded: > > On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: > >> David, >> >> Thanks for the thorough review (as always). Replies embedded below. >> >> >> On 10/11/11 10:48 PM, David Holmes wrote: >>> Hi Dan, >>> >>> src/cpu/x86/vm/jni_x86.h >>> >>> I don't understand why this change would be needed: >>> >>> ! #if defined(_LP64)&& !defined(__APPLE__) >>> typedef long jlong; >>> #else >>> typedef long long jlong; >>> #endif >>> >>> this is saying that on "apple" under _LP64 a long is not 64-bits. But the very definition of LP64 is that longs and pointers are 64-bits. ??? >> $ cat sizes.c >> #include >> >> int main() { >> printf("Hello world! _LP64="); >> #ifdef _LP64 >> printf("%d\n", _LP64); >> #else >> printf("undefined\n"); >> #endif >> printf("sizeof(long) = %d\n", (int) sizeof(long)); >> printf("sizeof(long long) = %d\n", (int) sizeof(long long)); >> } >> >> Output on my MacOS 10.6.8 machine: >> >> Hello world! _LP64=1 >> sizeof(long) = 8 >> sizeof(long long) = 8 >> >> Output on my Solaris X86 machine: >> >> Hello world! _LP64=undefined >> sizeof(long) = 4 >> sizeof(long long) = 8 >> >> Output on my Solaris X86 machine when built with '-m64': >> >> Hello world! _LP64=1 >> sizeof(long) = 8 >> sizeof(long long) = 8 >> >> Since __APPLE__ machines have a 8 byte long, I don't understand >> why the person thought that "long long jlong" was necessary... >> >> We need an Apple person to jump in here... >> > (answered before, but here it is again): > This is likely due to the fprintf format usage mess. The hotspot code had assumed that any 64-bit fprintf format could be used with any 64-bit value. Apple compilers give warnings if you print a long with "%lld", and insists upon "%ld" for a clean compile even though both are 64-bit values. Changing the type to long long allows the format to remain unchanged. > > The correct way to fix this mess is to insure that the formats exactly match the types used. We couldn't pull this off at apple since we didn't have the capabilities to build under all of the other os platforms to test the changes. > >>> src/os//vm/os_.cpp >>> >>> + void os::set_native_thread_name(const char *name) { >>> + // Not yet implemented. >>> + return; >>> + } >>> >>> I hate seeing "shared" code that is not implemented on 3 out of 4 supported platforms. Though it seems Linux will also support pthread_setname_np as of March 2010 (not sure which kernel or glibc versions needed). If not for the fact this also adds an exported JVM method to set the native thread name, we could otherwise bury this in the platform specific native thread creation code (which might also obviate the need for the new _is_attached logic - see next point). I also wonder what Java code is using this new JVM API? >> I suspect that this new API is used by other pieces of the MacOS X >> port project, but I don't know that for sure. Again, we need an >> Apple person to jump in here. > The native thread name addition was a huge win, both for us debugging and for our developer customers. The only complaint we had was from other projects whose code attached to Java and (in initial revisions) had their threads renamed. It is exported so that Thread.java can set the native thread name. > > I have no explanation for the lack of a return code. I can only surmise that it is an oversight that was not caught by the compiler. > > The other pieces are: > macosx-port/jdk/src/share/native/java/lang/Thread.c: > {"getThreads", "()[" THD, (void *)&JVM_GetAllThreads}, > {"dumpThreads", "([" THD ")[[" STE, (void *)&JVM_DumpThreads}, > --> {"setNativeName", "(" STR ")V", (void *)&JVM_SetNativeThreadName}, > }; > -and- > macosx-port/jdk/src/share/classes/java/lang/Thread.java > /** > * Changes the name of this thread to be equal to the argument > *name. > *

> * First thecheckAccess method of this thread is called > * with no arguments. This may result in throwing a > *SecurityException. > * > * @param name the new name for this thread. > * @exception SecurityException if the current thread cannot modify this > * thread. > * @see #getName > * @see #checkAccess() > */ > public final void setName(String name) { > checkAccess(); > this.name = name.toCharArray(); > --> if (threadStatus != 0) { > --> setNativeName(name); > --> } > } >> >>> Also wondering where the "current thread only" restriction came about? >> If the API is restricted to the "current thread", then we don't have >> to worry about races and locking. Also, I'm wondering why there is no >> return code. >> >> >>> src/share/vm/runtime/thread.hpp >>> >>> + // Remember whether or not we were attached >>> + bool _is_attached; >>> >>> It took me a while to realize that _is_attached really means "was attached" ie that the Java thread came about due to a native thread attaching to the VM via JNI attachCurrentThread. Could I suggest this is renamed to was_attached? >> I was taking another look at this. The key user of the new flag is: >> >> src/share/vm/prims/jvm.cpp >> >> JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject jthread, jstring n >> ame)) >> JVMWrapper("JVM_SetNativeThreadName"); >> ResourceMark rm(THREAD); >> oop java_thread = JNIHandles::resolve_non_null(jthread); >> JavaThread* thr = java_lang_Thread::thread(java_thread); >> // Thread naming only supported for the current thread, doesn't work for >> // target threads. >> if (Thread::current() == thr&& !thr->is_attached()) { >> // we don't set the name of an attached thread to avoid stepping >> // on other programs >> const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::reso >> lve_non_null(name)); >> os::set_native_thread_name(thread_name); >> } >> JVM_END >> >> which is coded to not set the name of a thread that has been >> attached. In the JavaThread(bool) constructor: >> >> _is_attached = _is_attaching = is_attaching; >> >> we set both flags to the "is_attaching" parameter (default false) >> so if we're coming down the JNI attach path, that parameter >> should be true so we set both flags to true. After the thread >> has been properly attached, we call set_attached() which sets >> the _is_attaching flag to false. Whew! >> >> In the JavaThread(ThreadFunction, size_t) constructor we set >> both flags to false because we're not attaching... and we >> didn't come down the JNI attach path. >> >> I don't like the "was attached" attribute and I no longer like >> the "is attaching" and "is attached" attributes either. Sigh. >> I think both fields need to be cleaned up and renamed. Perhaps >> something like: >> >> is_attaching_via_jni >> was_attached_via_jni >> >> would be more clear? >> >> >>> src/share/vm/utilities/debug.cpp >>> >>> Why are we exposing this debug code in a product build? >> We'll need an Apple person to jump in here... >> >> > It has been an Apple tradition (from long before I joined the Java team in 2004) to include a basic set of debugging routines in product builds. We call them from gdb while debugging problems that don't show up in debug builds, and we've told our developer customers about them. The rest of the Apple port does not depend on these and whether or not to continue Apple's tradition is totally up to Oracle. > >>> src/share/vm/prims/jni.cpp >>> >>> The USDT2 ifdef changes are truly ugly especially in this file. Is there no way to hide USDT1 vs USDT2 at a lower level so that the top-level probe points are not affected? I know this is flagged for "future work" but history shows such cleans ups rarely if ever happen - and this current code really is pretty awful to look at. >> Yes, the #ifdef'ing makes the current code awful. I don't think >> anyone will dispute that observation. >> >> The better solution would be for Solaris to migrate to USDT2. >> I'm discussing that with Keith McGuigan. However, I don't want >> to take much of his time right now because he is hip deep in >> another alligator swamp at the moment. >> >> The best I can offer at the moment is filing a new bug to track >> the future work. Yes, I know that clean up type work rarely gets >> done, but this merge with the MacOS X port project needs to get >> into HSX-23 as soon as possible. Broken functionality in the >> other platforms is a stopper, but ugly is not a stopper. >> >> Thanks again for the thorough review. >> >> Dan >> >> >>> Cheers, >>> David >>> >>> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>> >>>> 7089790 integrate bsd-port changes >>>> >>>> and I'm following up on that work using the following bug: >>>> >>>> 7098194 integrate macosx-port changes >>>> >>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>> include additional changes from the BSD Port in addition the deltas >>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>> this resync is: >>>> >>>> changeset: 2729:f1a18ada5853 >>>> tag: tip >>>> user: Greg Lewis >>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>> summary: . Finish removing hsearch_r. >>>> >>>> The macosx-port/hotspot changeset for this merge is: >>>> >>>> changeset: 2756:69de8d34a370 >>>> tag: tip >>>> user: swingler at apple.com >>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>> (avoids stomping DYLD_LIBRARY_PATH) >>>> >>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>> regressing the non-MacOS X platforms. In other words, we're trying >>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>> Shaking out the MacOS X Port itself will be done with other changesets >>>> on an as needed basis. >>>> >>>> Just to be clear, the push target for this changeset is the RT_Baseline >>>> sub-repo of HotSpot Express (currently HSX-23): >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>> >>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>> can review these changes in different ways. My primary focus here is >>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>> specific changes. Obviously, if you see something I messed up in those >>>> files, I'd like to know. >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>> >>>> The order of the files in the above webrev is the same as for >>>> for the subset webrevs below. >>>> >>>> Here's the webrevs for the changes in subsets: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>> >>>> >>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>> >>>> >>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>> made for the MacOS X port. There's a couple of files that also contain >>>> Dtrace related changes, but I decided it was better to include those >>>> files in this subset. >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>> >>>> >>>> The above webrev has almost all of the changes to enable Dtrace on >>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>> which is why the code is #ifdef'ed. I had to change the original >>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> >>>> #else /* USDT2 */ >>>> >>>> #endif /* USDT2 */ >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> #endif /* ! USDT2 */ >>>> >>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>> HotSpot style guidelines very consistently, but I decided not to fix >>>> that so I could diff against the macosx-port/hotspot more reliably. >>>> >>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>> Dtrace implementation to the newer version. However, that work will be >>>> done independently of this bug (7098194). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>> >>>> >>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>> to bless these changes... >>>> >>>> Builds done so far: >>>> >>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX >>>> repo >>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>>> >>>> Testing done so far: >>>> >>>> - Serviceability stack (25 subsuites): >>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>> logging, mm >>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>> misc_attach, misc_jvmstat, misc_tools >>>> - Tested configs (8 configs) >>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>> >>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>> i.e., did the build "work"? >>>> >>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>> testing should be finished later today. >>>> >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>> - dtrace testing on Solaris X86 >>>> - code review >>>> - start bring up of more formal dev testing on MacOS X >>>> >>>> Thanks, in advance, for any review comments. >>>> >>>> Dan >>>> From paul.hohensee at oracle.com Wed Oct 12 13:56:35 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 12 Oct 2011 16:56:35 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> Message-ID: <4E95FF03.8090803@oracle.com> The printf format thing is handled in globalDefinitions.hpp via system-dependent macros named INTX_FORMAT, PTR_FORMAT, etc. There should be no direct uses of printf format specifiers in Hotspot code, so the change to jni_x86.h should go away and any uses of %lld and %ld should be replaced by the appropriate FORMAT macro. If needed, you can use the platform-specific extensions to globalDefinitions.hpp in the cpu and utilities directories. If set_native_thread_name() is an implementation of an extension to Thread, then I'd recommend leaving it and the supporting code out (and there's a lot of it, vis jvm.cpp as you point out) until the core libs people figure out how they want to handle it. Maybe file an RFE for the work. In debug.cpp, I'd make Debugging a product flag if you're going to make Command a product class. That way you don't need the #ifndef PRODUCT around its uses. There's a use of "%#p" at line 481 in the Old file (487 in the New one) that should be replaced by PTR_FORMAT. The comment on line 496 of the New version should be "!PRODUCT" rather than "PRODUCT". You might change pss() to read 577 extern "C" void pss() { // print all stacks 578 if (!Thread::current()) return; 579 Command c("pss"); 581 Threads::print(true, PRODUCT_ONLY(false) NOT_PRODUCT(true)); 585 } It's perhaps a bit neater. Re "!Thread::current()", the rule in hotspot is to make comparisons to null explicit, so you could use instead "Thread::current() != NULL", because what NULL is varies by platform. Paul On 10/12/11 2:34 PM, roger hoover wrote: > As I promised Dan earlier this morning....replies embedded: > > On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: > >> David, >> >> Thanks for the thorough review (as always). Replies embedded below. >> >> >> On 10/11/11 10:48 PM, David Holmes wrote: >>> Hi Dan, >>> >>> src/cpu/x86/vm/jni_x86.h >>> >>> I don't understand why this change would be needed: >>> >>> ! #if defined(_LP64)&& !defined(__APPLE__) >>> typedef long jlong; >>> #else >>> typedef long long jlong; >>> #endif >>> >>> this is saying that on "apple" under _LP64 a long is not 64-bits. But the very definition of LP64 is that longs and pointers are 64-bits. ??? >> $ cat sizes.c >> #include >> >> int main() { >> printf("Hello world! _LP64="); >> #ifdef _LP64 >> printf("%d\n", _LP64); >> #else >> printf("undefined\n"); >> #endif >> printf("sizeof(long) = %d\n", (int) sizeof(long)); >> printf("sizeof(long long) = %d\n", (int) sizeof(long long)); >> } >> >> Output on my MacOS 10.6.8 machine: >> >> Hello world! _LP64=1 >> sizeof(long) = 8 >> sizeof(long long) = 8 >> >> Output on my Solaris X86 machine: >> >> Hello world! _LP64=undefined >> sizeof(long) = 4 >> sizeof(long long) = 8 >> >> Output on my Solaris X86 machine when built with '-m64': >> >> Hello world! _LP64=1 >> sizeof(long) = 8 >> sizeof(long long) = 8 >> >> Since __APPLE__ machines have a 8 byte long, I don't understand >> why the person thought that "long long jlong" was necessary... >> >> We need an Apple person to jump in here... >> > (answered before, but here it is again): > This is likely due to the fprintf format usage mess. The hotspot code had assumed that any 64-bit fprintf format could be used with any 64-bit value. Apple compilers give warnings if you print a long with "%lld", and insists upon "%ld" for a clean compile even though both are 64-bit values. Changing the type to long long allows the format to remain unchanged. > > The correct way to fix this mess is to insure that the formats exactly match the types used. We couldn't pull this off at apple since we didn't have the capabilities to build under all of the other os platforms to test the changes. > >>> src/os//vm/os_.cpp >>> >>> + void os::set_native_thread_name(const char *name) { >>> + // Not yet implemented. >>> + return; >>> + } >>> >>> I hate seeing "shared" code that is not implemented on 3 out of 4 supported platforms. Though it seems Linux will also support pthread_setname_np as of March 2010 (not sure which kernel or glibc versions needed). If not for the fact this also adds an exported JVM method to set the native thread name, we could otherwise bury this in the platform specific native thread creation code (which might also obviate the need for the new _is_attached logic - see next point). I also wonder what Java code is using this new JVM API? >> I suspect that this new API is used by other pieces of the MacOS X >> port project, but I don't know that for sure. Again, we need an >> Apple person to jump in here. > The native thread name addition was a huge win, both for us debugging and for our developer customers. The only complaint we had was from other projects whose code attached to Java and (in initial revisions) had their threads renamed. It is exported so that Thread.java can set the native thread name. > > I have no explanation for the lack of a return code. I can only surmise that it is an oversight that was not caught by the compiler. > > The other pieces are: > macosx-port/jdk/src/share/native/java/lang/Thread.c: > {"getThreads", "()[" THD, (void *)&JVM_GetAllThreads}, > {"dumpThreads", "([" THD ")[[" STE, (void *)&JVM_DumpThreads}, > --> {"setNativeName", "(" STR ")V", (void *)&JVM_SetNativeThreadName}, > }; > -and- > macosx-port/jdk/src/share/classes/java/lang/Thread.java > /** > * Changes the name of this thread to be equal to the argument > *name. > *

> * First thecheckAccess method of this thread is called > * with no arguments. This may result in throwing a > *SecurityException. > * > * @param name the new name for this thread. > * @exception SecurityException if the current thread cannot modify this > * thread. > * @see #getName > * @see #checkAccess() > */ > public final void setName(String name) { > checkAccess(); > this.name = name.toCharArray(); > --> if (threadStatus != 0) { > --> setNativeName(name); > --> } > } >> >>> Also wondering where the "current thread only" restriction came about? >> If the API is restricted to the "current thread", then we don't have >> to worry about races and locking. Also, I'm wondering why there is no >> return code. >> >> >>> src/share/vm/runtime/thread.hpp >>> >>> + // Remember whether or not we were attached >>> + bool _is_attached; >>> >>> It took me a while to realize that _is_attached really means "was attached" ie that the Java thread came about due to a native thread attaching to the VM via JNI attachCurrentThread. Could I suggest this is renamed to was_attached? >> I was taking another look at this. The key user of the new flag is: >> >> src/share/vm/prims/jvm.cpp >> >> JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject jthread, jstring n >> ame)) >> JVMWrapper("JVM_SetNativeThreadName"); >> ResourceMark rm(THREAD); >> oop java_thread = JNIHandles::resolve_non_null(jthread); >> JavaThread* thr = java_lang_Thread::thread(java_thread); >> // Thread naming only supported for the current thread, doesn't work for >> // target threads. >> if (Thread::current() == thr&& !thr->is_attached()) { >> // we don't set the name of an attached thread to avoid stepping >> // on other programs >> const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::reso >> lve_non_null(name)); >> os::set_native_thread_name(thread_name); >> } >> JVM_END >> >> which is coded to not set the name of a thread that has been >> attached. In the JavaThread(bool) constructor: >> >> _is_attached = _is_attaching = is_attaching; >> >> we set both flags to the "is_attaching" parameter (default false) >> so if we're coming down the JNI attach path, that parameter >> should be true so we set both flags to true. After the thread >> has been properly attached, we call set_attached() which sets >> the _is_attaching flag to false. Whew! >> >> In the JavaThread(ThreadFunction, size_t) constructor we set >> both flags to false because we're not attaching... and we >> didn't come down the JNI attach path. >> >> I don't like the "was attached" attribute and I no longer like >> the "is attaching" and "is attached" attributes either. Sigh. >> I think both fields need to be cleaned up and renamed. Perhaps >> something like: >> >> is_attaching_via_jni >> was_attached_via_jni >> >> would be more clear? >> >> >>> src/share/vm/utilities/debug.cpp >>> >>> Why are we exposing this debug code in a product build? >> We'll need an Apple person to jump in here... >> >> > It has been an Apple tradition (from long before I joined the Java team in 2004) to include a basic set of debugging routines in product builds. We call them from gdb while debugging problems that don't show up in debug builds, and we've told our developer customers about them. The rest of the Apple port does not depend on these and whether or not to continue Apple's tradition is totally up to Oracle. > >>> src/share/vm/prims/jni.cpp >>> >>> The USDT2 ifdef changes are truly ugly especially in this file. Is there no way to hide USDT1 vs USDT2 at a lower level so that the top-level probe points are not affected? I know this is flagged for "future work" but history shows such cleans ups rarely if ever happen - and this current code really is pretty awful to look at. >> Yes, the #ifdef'ing makes the current code awful. I don't think >> anyone will dispute that observation. >> >> The better solution would be for Solaris to migrate to USDT2. >> I'm discussing that with Keith McGuigan. However, I don't want >> to take much of his time right now because he is hip deep in >> another alligator swamp at the moment. >> >> The best I can offer at the moment is filing a new bug to track >> the future work. Yes, I know that clean up type work rarely gets >> done, but this merge with the MacOS X port project needs to get >> into HSX-23 as soon as possible. Broken functionality in the >> other platforms is a stopper, but ugly is not a stopper. >> >> Thanks again for the thorough review. >> >> Dan >> >> >>> Cheers, >>> David >>> >>> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>> >>>> 7089790 integrate bsd-port changes >>>> >>>> and I'm following up on that work using the following bug: >>>> >>>> 7098194 integrate macosx-port changes >>>> >>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>> include additional changes from the BSD Port in addition the deltas >>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>> this resync is: >>>> >>>> changeset: 2729:f1a18ada5853 >>>> tag: tip >>>> user: Greg Lewis >>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>> summary: . Finish removing hsearch_r. >>>> >>>> The macosx-port/hotspot changeset for this merge is: >>>> >>>> changeset: 2756:69de8d34a370 >>>> tag: tip >>>> user: swingler at apple.com >>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>> (avoids stomping DYLD_LIBRARY_PATH) >>>> >>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>> regressing the non-MacOS X platforms. In other words, we're trying >>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>> Shaking out the MacOS X Port itself will be done with other changesets >>>> on an as needed basis. >>>> >>>> Just to be clear, the push target for this changeset is the RT_Baseline >>>> sub-repo of HotSpot Express (currently HSX-23): >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>> >>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>> can review these changes in different ways. My primary focus here is >>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>> specific changes. Obviously, if you see something I messed up in those >>>> files, I'd like to know. >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>> >>>> The order of the files in the above webrev is the same as for >>>> for the subset webrevs below. >>>> >>>> Here's the webrevs for the changes in subsets: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>> >>>> >>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>> >>>> >>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>> made for the MacOS X port. There's a couple of files that also contain >>>> Dtrace related changes, but I decided it was better to include those >>>> files in this subset. >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>> >>>> >>>> The above webrev has almost all of the changes to enable Dtrace on >>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>> which is why the code is #ifdef'ed. I had to change the original >>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> >>>> #else /* USDT2 */ >>>> >>>> #endif /* USDT2 */ >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> #endif /* ! USDT2 */ >>>> >>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>> HotSpot style guidelines very consistently, but I decided not to fix >>>> that so I could diff against the macosx-port/hotspot more reliably. >>>> >>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>> Dtrace implementation to the newer version. However, that work will be >>>> done independently of this bug (7098194). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>> >>>> >>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>> to bless these changes... >>>> >>>> Builds done so far: >>>> >>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX >>>> repo >>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>>> >>>> Testing done so far: >>>> >>>> - Serviceability stack (25 subsuites): >>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>> logging, mm >>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>> misc_attach, misc_jvmstat, misc_tools >>>> - Tested configs (8 configs) >>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>> >>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>> i.e., did the build "work"? >>>> >>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>> testing should be finished later today. >>>> >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>> - dtrace testing on Solaris X86 >>>> - code review >>>> - start bring up of more formal dev testing on MacOS X >>>> >>>> Thanks, in advance, for any review comments. >>>> >>>> Dan >>>> > From daniel.daugherty at oracle.com Wed Oct 12 13:58:38 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 14:58:38 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E950B62.8070504@oracle.com> References: <4E947E11.6070004@oracle.com> <4E950B62.8070504@oracle.com> Message-ID: <4E95FF7E.5020503@oracle.com> On 10/11/11 9:37 PM, Daniel D. Daugherty wrote: > On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment > > Here's the list of folks that Tom used for the BSD-port push: > > Kurt Miller > Greg Lewis > Jung-uk Kim > Christos Zoulas > Landon Fuller > The FreeBSD Foundation > Michael Franz > Roger Hoover > Alexander Strange > > Since I'm syncing with bsd-port/hotspot in addition to > merging in macosx-port/hotspot, should I use the same > list of folks? I still need to nail down the contributor list and no one replied to this part of the e-mail thread... Dan From tom.rodriguez at oracle.com Wed Oct 12 14:04:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Oct 2011 14:04:15 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E95FF7E.5020503@oracle.com> References: <4E947E11.6070004@oracle.com> <4E950B62.8070504@oracle.com> <4E95FF7E.5020503@oracle.com> Message-ID: <84E408E0-AC1D-4AF3-9515-8250AA1A60DD@oracle.com> On Oct 12, 2011, at 1:58 PM, Daniel D. Daugherty wrote: > On 10/11/11 9:37 PM, Daniel D. Daugherty wrote: >> On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >> >> Here's the list of folks that Tom used for the BSD-port push: >> >> Kurt Miller >> Greg Lewis >> Jung-uk Kim >> Christos Zoulas >> Landon Fuller >> The FreeBSD Foundation >> Michael Franz >> Roger Hoover >> Alexander Strange >> >> Since I'm syncing with bsd-port/hotspot in addition to >> merging in macosx-port/hotspot, should I use the same >> list of folks? > > I still need to nail down the contributor list and no one > replied to this part of the e-mail thread... I would assume Roger and Alexander of course and then only contributors to bsd-port since around the time of the sync, so I think it would this: Kurt Miller Greg Lewis Christos Zoulas Roger Hoover Alexander Strange tom > > Dan > From rhoover at apple.com Wed Oct 12 14:06:17 2011 From: rhoover at apple.com (roger hoover) Date: Wed, 12 Oct 2011 15:06:17 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E95FF7E.5020503@oracle.com> References: <4E947E11.6070004@oracle.com> <4E950B62.8070504@oracle.com> <4E95FF7E.5020503@oracle.com> Message-ID: On Oct 12, 2011, at 2:58 PM, Daniel D. Daugherty wrote: > On 10/11/11 9:37 PM, Daniel D. Daugherty wrote: >> On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >> >> Here's the list of folks that Tom used for the BSD-port push: >> >> Kurt Miller >> Greg Lewis >> Jung-uk Kim >> Christos Zoulas >> Landon Fuller >> The FreeBSD Foundation >> Michael Franz >> Roger Hoover >> Alexander Strange >> >> Since I'm syncing with bsd-port/hotspot in addition to >> merging in macosx-port/hotspot, should I use the same >> list of folks? > > I still need to nail down the contributor list and no one > replied to this part of the e-mail thread... > > Dan > The actual edits to the mac port were mostly done by Roger Hoover and Alexander Strange, but the changes themselves come from a whole host of people who have built the mac port at Apple over the last decade++. Perhaps you should attribute Apple, Inc. roger From tony.printezis at oracle.com Wed Oct 12 14:18:44 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Wed, 12 Oct 2011 21:18:44 +0000 Subject: hg: hsx/hsx22/hotspot: 12 new changesets Message-ID: <20111012211908.1022447FB6@hg.openjdk.java.net> Changeset: 8d4cd133d6a8 Author: tonyp Date: 2011-09-20 09:59 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/8d4cd133d6a8 7059019: G1: add G1 support to the SA Summary: Extend the SA to recognize the G1CollectedHeap and implement any code that's needed by our serviceability tools (jmap, jinfo, jstack, etc.) that depend on the SA. Reviewed-by: never, poonam, johnc ! agent/make/Makefile + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegion.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! make/sa.files ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 66db4a2fc13c Author: johnc Date: 2011-09-20 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/66db4a2fc13c 7092412: G1: Some roots not marked during an initial mark that gets an evacuation failure Summary: As a result of the changes for 7080389, an evacuation failure during an initial mark pause may result in some root objects not being marked. Pass whether the caller is a root scanning closure into the evacuation failure handling code so that the thread that successfully forwards an object to itself also marks the object. Reviewed-by: ysr, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 2115638addd2 Author: tonyp Date: 2011-09-21 01:27 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/2115638addd2 7045232: G1: pool names are inconsistent with other collectors (don't have 'Space') Summary: Make sure the eden and survivor pools have "Space" in their name. Reviewed-by: jmasa, ysr ! src/share/vm/services/g1MemoryPool.cpp Changeset: ce597819d5c6 Author: johnc Date: 2011-09-21 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/ce597819d5c6 7068215: G1: Print reference processing time during remark Summary: Displays the elapsed time taken to perform reference processing during remark as part of the PrintGCDetails output. Reviewed-by: ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: ac196b091535 Author: tonyp Date: 2011-09-21 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/ac196b091535 7091032: G1: assert failure when NewRatio is used Summary: The desired min / max heap sizes are miscalculated at initialization when NewRatio is used. The changeset also includes an additional small change to turn a print statement into a warning. Reviewed-by: johnc, jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e804fc7a831e Author: johnc Date: 2011-09-21 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/e804fc7a831e 7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header output Summary: Cast HeapRegion::GrainBytes to size_t in output statement. Reviewed-by: ysr, brutisso, pbk, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: c20e006ee26a Author: tonyp Date: 2011-09-22 07:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/c20e006ee26a 7092238: G1: Uninitialized field gc_efficiency in G1PrintRegionLivenessInfo output Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d320dd70ca40 Author: johnc Date: 2011-09-22 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/d320dd70ca40 6484982: G1: process references during evacuation pauses Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate. Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/thread.cpp Changeset: 39c57c097027 Author: tonyp Date: 2011-09-23 16:07 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/39c57c097027 7075646: G1: fix inconsistencies in the monitoring data Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat. Reviewed-by: jmasa, brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 9a9821a0bc8b Author: johnc Date: 2011-09-28 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/9a9821a0bc8b 7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835 Summary: Some objects may not be marked in the event of an evacuation failure in a partially young GC, during a marking cycle. Avoid this situation by not allowing partially young GCs during a marking cycle. Reviewed-by: tonyp, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 7afaeffa5d9b Author: johnc Date: 2011-10-03 12:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/7afaeffa5d9b 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: aade124d1b1d Author: tonyp Date: 2011-10-03 19:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/aade124d1b1d 7097048: G1: extend the G1 SA changes to print per-heap space information Reviewed-by: brutisso, johnc ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp From paul.hohensee at oracle.com Wed Oct 12 14:19:59 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 12 Oct 2011 17:19:59 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E95F4AA.7050200@oracle.com> References: <4E947E11.6070004@oracle.com> <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> <4E95F4AA.7050200@oracle.com> Message-ID: <4E96047F.1020205@oracle.com> Do we really need to keep in sync with the old macosx-port project? Afaic, we're just using that code as a starting point for this project. I second Tom's suggestion to move the USDT1/2 distinction into a header file. Doing so would make this changeset a whole lot smaller. Paul On 10/12/11 4:12 PM, Daniel D. Daugherty wrote: > On 10/12/11 12:27 PM, Tom Rodriguez wrote: >> I'm working on a review and this is what I have so far. I'll send >> more later. >> >> On the issue of the dtrace changes, couldn't we minimize later >> disruption by moving the USDT1/USDT2 distinction into a header file? >> For instance, instead of doing this: >> >> +#ifndef USDT2 >> >> HS_DTRACE_PROBE1(hotspot, thread__sleep__end,0); >> >> +#else /* USDT2 */ >> + HOTSPOT_THREAD_SLEEP_END( >> + 0); >> +#endif /* USDT2 */ >> >> Couldn't it just have >> >> HOTSPOT_THREAD_SLEEP_END(0); >> >> with this ifdef in a header somewhere? >> >> #ifndef USDT2 >> #define HOTSPOT_THREAD_SLEEP_END(arg) \ >> HS_DTRACE_PROBE1(hotspot, thread__sleep__end, (arg)) >> #endif /* USDT2 */ >> >> It minimizes the ugly until we resolve the real issue. I guess the >> PROBE_DECL stuff will have to be somewhere else too. Anyway, I'm >> fine with pushing it as is but I wanted to at least mention this. > > I'll include this in the new bug as a way to phase in the > changes from USDT1 -> USDT2. I don't want to make that > change now since it will make it more difficult to keep > in sync with the MacOS X port project. > > >> connode.cpp: >> >> why is ia64_double_zero being defined? There are no uses of it >> anywhere. > > I saw your newer posting. I'll file a bug for this also. > > >> os_bsd.cpp: >> >> there's a fix for a minor memory leak in there which should also be >> fixed in os_linux.cpp: >> >> if (v != NULL) { >> char *t = ld_library_path; >> /* That's +1 for the colon and +1 for the trailing '\0' */ >> ld_library_path = (char *) malloc(strlen(v) + 1 + >> strlen(t) + 1); >> sprintf(ld_library_path, "%s:%s", v, t); >> + free(t); >> } > > Yup. It's on my notes list. > > >> bsd_x86_32.s: >> >> This apple fix isn't needed since p2align is already aligning to 16 >> bytes. In the mac assembler .align is the same as .p2align which is >> why it's reducing it to 4. >> >> - .p2align 4,,15 >> +#ifdef __APPLE__ >> + .align 4 >> +#else >> + .align 16 >> +#endif >> >> The second alignment change isn't needed because of this: >> >> 82 ELF_TYPE(SafeFetch32, at function) >> 83 .p2align 4,,15 > > I noticed that I screwed that up just after I sent out the > review request so it was discussed a bit earlier in this > thread. > > Thanks for the thorough review. > > Dan > > >> tom >> >> On Oct 11, 2011, at 10:34 AM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also >>> contain >>> Dtrace related changes, but I decided it was better to include >>> those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on >>> Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some >>> non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>> build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not >>> follow >>> HotSpot style guidelines very consistently, but I decided not to >>> fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the >>> Solaris >>> Dtrace implementation to the newer version. However, that work >>> will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> >>> The above webrev has all the infrastructure (e.g., Makefile) >>> related >>> changes. Many/most folks aren't interested in Makefile stuff so >>> I've >>> put these changes in their own subset. Of course, I need Kelly >>> O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>> jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>> HSX repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>> HSX repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> > From daniel.daugherty at oracle.com Wed Oct 12 15:00:23 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 16:00:23 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E96047F.1020205@oracle.com> References: <4E947E11.6070004@oracle.com> <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> <4E95F4AA.7050200@oracle.com> <4E96047F.1020205@oracle.com> Message-ID: <4E960DF7.7070206@oracle.com> On 10/12/11 3:19 PM, Paul Hohensee wrote: > Do we really need to keep in sync with the old macosx-port project? Yes. That's one of the ways that I'm keeping this port project sane. As far as I know, the bsd-port/hotspot and macosx-port/hotspot repos have not yet been retired. If I have to resync with either of those repos again before they are retired, then I would like that to go smoothly. > Afaic, we're just using that code as a starting point for this project. 'Afaic' or 'Afaik'? (care or know?) Yes, we're using that code as a starting point for this project, but I don't yet have testing up and running on MacOS X so I don't want to make non-trivial MacOS X changes blind. > I second Tom's suggestion to move the USDT1/2 distinction into > a header file. Doing so would make this changeset a whole lot smaller. Not going to happen in this changeset. I will file another bug to do more work on USDT1/2 stuff, but I don't yet have a way to test making a change like that on MacOS X. Dan > > Paul > > On 10/12/11 4:12 PM, Daniel D. Daugherty wrote: >> On 10/12/11 12:27 PM, Tom Rodriguez wrote: >>> I'm working on a review and this is what I have so far. I'll send >>> more later. >>> >>> On the issue of the dtrace changes, couldn't we minimize later >>> disruption by moving the USDT1/USDT2 distinction into a header >>> file? For instance, instead of doing this: >>> >>> +#ifndef USDT2 >>> >>> HS_DTRACE_PROBE1(hotspot, thread__sleep__end,0); >>> >>> +#else /* USDT2 */ >>> + HOTSPOT_THREAD_SLEEP_END( >>> + 0); >>> +#endif /* USDT2 */ >>> >>> Couldn't it just have >>> >>> HOTSPOT_THREAD_SLEEP_END(0); >>> >>> with this ifdef in a header somewhere? >>> >>> #ifndef USDT2 >>> #define HOTSPOT_THREAD_SLEEP_END(arg) \ >>> HS_DTRACE_PROBE1(hotspot, thread__sleep__end, (arg)) >>> #endif /* USDT2 */ >>> >>> It minimizes the ugly until we resolve the real issue. I guess the >>> PROBE_DECL stuff will have to be somewhere else too. Anyway, I'm >>> fine with pushing it as is but I wanted to at least mention this. >> >> I'll include this in the new bug as a way to phase in the >> changes from USDT1 -> USDT2. I don't want to make that >> change now since it will make it more difficult to keep >> in sync with the MacOS X port project. >> >> >>> connode.cpp: >>> >>> why is ia64_double_zero being defined? There are no uses of it >>> anywhere. >> >> I saw your newer posting. I'll file a bug for this also. >> >> >>> os_bsd.cpp: >>> >>> there's a fix for a minor memory leak in there which should also be >>> fixed in os_linux.cpp: >>> >>> if (v != NULL) { >>> char *t = ld_library_path; >>> /* That's +1 for the colon and +1 for the trailing >>> '\0' */ >>> ld_library_path = (char *) malloc(strlen(v) + 1 + >>> strlen(t) + 1); >>> sprintf(ld_library_path, "%s:%s", v, t); >>> + free(t); >>> } >> >> Yup. It's on my notes list. >> >> >>> bsd_x86_32.s: >>> >>> This apple fix isn't needed since p2align is already aligning to 16 >>> bytes. In the mac assembler .align is the same as .p2align which is >>> why it's reducing it to 4. >>> >>> - .p2align 4,,15 >>> +#ifdef __APPLE__ >>> + .align 4 >>> +#else >>> + .align 16 >>> +#endif >>> >>> The second alignment change isn't needed because of this: >>> >>> 82 ELF_TYPE(SafeFetch32, at function) >>> 83 .p2align 4,,15 >> >> I noticed that I screwed that up just after I sent out the >> review request so it was discussed a bit earlier in this >> thread. >> >> Thanks for the thorough review. >> >> Dan >> >> >>> tom >>> >>> On Oct 11, 2011, at 10:34 AM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>> >>>> 7089790 integrate bsd-port changes >>>> >>>> and I'm following up on that work using the following bug: >>>> >>>> 7098194 integrate macosx-port changes >>>> >>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>> include additional changes from the BSD Port in addition the deltas >>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>> this resync is: >>>> >>>> changeset: 2729:f1a18ada5853 >>>> tag: tip >>>> user: Greg Lewis >>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>> summary: . Finish removing hsearch_r. >>>> >>>> The macosx-port/hotspot changeset for this merge is: >>>> >>>> changeset: 2756:69de8d34a370 >>>> tag: tip >>>> user: swingler at apple.com >>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>> (avoids stomping DYLD_LIBRARY_PATH) >>>> >>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>> regressing the non-MacOS X platforms. In other words, we're trying >>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>> Shaking out the MacOS X Port itself will be done with other changesets >>>> on an as needed basis. >>>> >>>> Just to be clear, the push target for this changeset is the >>>> RT_Baseline >>>> sub-repo of HotSpot Express (currently HSX-23): >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>> >>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>> can review these changes in different ways. My primary focus here is >>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>> specific changes. Obviously, if you see something I messed up in those >>>> files, I'd like to know. >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>> >>>> The order of the files in the above webrev is the same as for >>>> for the subset webrevs below. >>>> >>>> Here's the webrevs for the changes in subsets: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>> >>>> >>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>> >>>> >>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>> made for the MacOS X port. There's a couple of files that also >>>> contain >>>> Dtrace related changes, but I decided it was better to include >>>> those >>>> files in this subset. >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>> >>>> >>>> The above webrev has almost all of the changes to enable Dtrace on >>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>> On MacOS X, a newer version of Dtrace is implemented than on >>>> Solaris >>>> which is why the code is #ifdef'ed. I had to change the original >>>> #ifdef'ing because the original implementation had put some >>>> non-Dtrace >>>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>>> build on >>>> non-Solaris platforms. In order to be more clean with >>>> #ifdef'ing, I >>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> >>>> #else /* USDT2 */ >>>> >>>> #endif /* USDT2 */ >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> #endif /* ! USDT2 */ >>>> >>>> Yes, I realize that the MacOS X Dtrace implementation does not >>>> follow >>>> HotSpot style guidelines very consistently, but I decided not >>>> to fix >>>> that so I could diff against the macosx-port/hotspot more >>>> reliably. >>>> >>>> I have to consult with Keith McGuigan about how to migrate the >>>> Solaris >>>> Dtrace implementation to the newer version. However, that work >>>> will be >>>> done independently of this bug (7098194). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>> >>>> >>>> The above webrev has all the infrastructure (e.g., Makefile) >>>> related >>>> changes. Many/most folks aren't interested in Makefile stuff so >>>> I've >>>> put these changes in their own subset. Of course, I need Kelly >>>> O'Hair >>>> to bless these changes... >>>> >>>> Builds done so far: >>>> >>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>> jvmg} >>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>> HSX repo >>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>>> HSX repo >>>> >>>> Testing done so far: >>>> >>>> - Serviceability stack (25 subsuites): >>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>> logging, mm >>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>> misc_attach, misc_jvmstat, misc_tools >>>> - Tested configs (8 configs) >>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>> >>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>> i.e., did the build "work"? >>>> >>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>> testing should be finished later today. >>>> >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>> - dtrace testing on Solaris X86 >>>> - code review >>>> - start bring up of more formal dev testing on MacOS X >>>> >>>> Thanks, in advance, for any review comments. >>>> >>>> Dan >>>> >> > From paul.hohensee at oracle.com Wed Oct 12 15:07:57 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 12 Oct 2011 18:07:57 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E960DF7.7070206@oracle.com> References: <4E947E11.6070004@oracle.com> <6094018D-2AB3-49AB-801E-F6A9FB4E04C5@oracle.com> <4E95F4AA.7050200@oracle.com> <4E96047F.1020205@oracle.com> <4E960DF7.7070206@oracle.com> Message-ID: <4E960FBD.9050501@oracle.com> On 10/12/11 6:00 PM, Daniel D. Daugherty wrote: > On 10/12/11 3:19 PM, Paul Hohensee wrote: >> Do we really need to keep in sync with the old macosx-port project? > > Yes. That's one of the ways that I'm keeping this port project sane. > As far as I know, the bsd-port/hotspot and macosx-port/hotspot repos > have not yet been retired. If I have to resync with either of those > repos again before they are retired, then I would like that to go > smoothly. Ok. Maybe someone can tell me when they'll be retired, or if they're relevant to a jdk7 port. I see what I can find out. > > >> Afaic, we're just using that code as a starting point for this project. > > 'Afaic' or 'Afaik'? (care or know?) "concerned". :) > > Yes, we're using that code as a starting point for this project, but > I don't yet have testing up and running on MacOS X so I don't want to > make non-trivial MacOS X changes blind. > > >> I second Tom's suggestion to move the USDT1/2 distinction into >> a header file. Doing so would make this changeset a whole lot smaller. > > Not going to happen in this changeset. I will file another bug to do > more work on USDT1/2 stuff, but I don't yet have a way to test making > a change like that on MacOS X. Reluctantly, Ok. Paul > > Dan > > > >> >> Paul >> >> On 10/12/11 4:12 PM, Daniel D. Daugherty wrote: >>> On 10/12/11 12:27 PM, Tom Rodriguez wrote: >>>> I'm working on a review and this is what I have so far. I'll send >>>> more later. >>>> >>>> On the issue of the dtrace changes, couldn't we minimize later >>>> disruption by moving the USDT1/USDT2 distinction into a header >>>> file? For instance, instead of doing this: >>>> >>>> +#ifndef USDT2 >>>> >>>> HS_DTRACE_PROBE1(hotspot, thread__sleep__end,0); >>>> >>>> +#else /* USDT2 */ >>>> + HOTSPOT_THREAD_SLEEP_END( >>>> + 0); >>>> +#endif /* USDT2 */ >>>> >>>> Couldn't it just have >>>> >>>> HOTSPOT_THREAD_SLEEP_END(0); >>>> >>>> with this ifdef in a header somewhere? >>>> >>>> #ifndef USDT2 >>>> #define HOTSPOT_THREAD_SLEEP_END(arg) \ >>>> HS_DTRACE_PROBE1(hotspot, thread__sleep__end, (arg)) >>>> #endif /* USDT2 */ >>>> >>>> It minimizes the ugly until we resolve the real issue. I guess the >>>> PROBE_DECL stuff will have to be somewhere else too. Anyway, I'm >>>> fine with pushing it as is but I wanted to at least mention this. >>> >>> I'll include this in the new bug as a way to phase in the >>> changes from USDT1 -> USDT2. I don't want to make that >>> change now since it will make it more difficult to keep >>> in sync with the MacOS X port project. >>> >>> >>>> connode.cpp: >>>> >>>> why is ia64_double_zero being defined? There are no uses of it >>>> anywhere. >>> >>> I saw your newer posting. I'll file a bug for this also. >>> >>> >>>> os_bsd.cpp: >>>> >>>> there's a fix for a minor memory leak in there which should also be >>>> fixed in os_linux.cpp: >>>> >>>> if (v != NULL) { >>>> char *t = ld_library_path; >>>> /* That's +1 for the colon and +1 for the trailing >>>> '\0' */ >>>> ld_library_path = (char *) malloc(strlen(v) + 1 + >>>> strlen(t) + 1); >>>> sprintf(ld_library_path, "%s:%s", v, t); >>>> + free(t); >>>> } >>> >>> Yup. It's on my notes list. >>> >>> >>>> bsd_x86_32.s: >>>> >>>> This apple fix isn't needed since p2align is already aligning to 16 >>>> bytes. In the mac assembler .align is the same as .p2align which >>>> is why it's reducing it to 4. >>>> >>>> - .p2align 4,,15 >>>> +#ifdef __APPLE__ >>>> + .align 4 >>>> +#else >>>> + .align 16 >>>> +#endif >>>> >>>> The second alignment change isn't needed because of this: >>>> >>>> 82 ELF_TYPE(SafeFetch32, at function) >>>> 83 .p2align 4,,15 >>> >>> I noticed that I screwed that up just after I sent out the >>> review request so it was discussed a bit earlier in this >>> thread. >>> >>> Thanks for the thorough review. >>> >>> Dan >>> >>> >>>> tom >>>> >>>> On Oct 11, 2011, at 10:34 AM, Daniel D. Daugherty wrote: >>>> >>>>> Greetings, >>>>> >>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>> >>>>> 7089790 integrate bsd-port changes >>>>> >>>>> and I'm following up on that work using the following bug: >>>>> >>>>> 7098194 integrate macosx-port changes >>>>> >>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>> include additional changes from the BSD Port in addition the deltas >>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>> this resync is: >>>>> >>>>> changeset: 2729:f1a18ada5853 >>>>> tag: tip >>>>> user: Greg Lewis >>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>> summary: . Finish removing hsearch_r. >>>>> >>>>> The macosx-port/hotspot changeset for this merge is: >>>>> >>>>> changeset: 2756:69de8d34a370 >>>>> tag: tip >>>>> user: swingler at apple.com >>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>> >>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>>> Shaking out the MacOS X Port itself will be done with other >>>>> changesets >>>>> on an as needed basis. >>>>> >>>>> Just to be clear, the push target for this changeset is the >>>>> RT_Baseline >>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>> >>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>> >>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>>> can review these changes in different ways. My primary focus here is >>>>> the common or shared code so I'm less worried about the BSD or >>>>> MacOS X >>>>> specific changes. Obviously, if you see something I messed up in >>>>> those >>>>> files, I'd like to know. >>>>> >>>>> Here's the webrev for all the changes in one shot: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>> >>>>> >>>>> The order of the files in the above webrev is the same as for >>>>> for the subset webrevs below. >>>>> >>>>> Here's the webrevs for the changes in subsets: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>> >>>>> >>>>> The above webrev has the changes to the bsd-port/hotspot repo >>>>> made >>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>> >>>>> >>>>> The above webrev has the non-Dtrace and non-infrastructure >>>>> changes >>>>> made for the MacOS X port. There's a couple of files that also >>>>> contain >>>>> Dtrace related changes, but I decided it was better to include >>>>> those >>>>> files in this subset. >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>> >>>>> >>>>> The above webrev has almost all of the changes to enable >>>>> Dtrace on >>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>> On MacOS X, a newer version of Dtrace is implemented than on >>>>> Solaris >>>>> which is why the code is #ifdef'ed. I had to change the original >>>>> #ifdef'ing because the original implementation had put some >>>>> non-Dtrace >>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>>>> build on >>>>> non-Solaris platforms. In order to be more clean with >>>>> #ifdef'ing, I >>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>> >>>>> #ifndef USDT2 >>>>> >>>>> >>>>> >>>>> #else /* USDT2 */ >>>>> >>>>> #endif /* USDT2 */ >>>>> >>>>> #ifndef USDT2 >>>>> >>>>> >>>>> #endif /* ! USDT2 */ >>>>> >>>>> Yes, I realize that the MacOS X Dtrace implementation does not >>>>> follow >>>>> HotSpot style guidelines very consistently, but I decided not >>>>> to fix >>>>> that so I could diff against the macosx-port/hotspot more >>>>> reliably. >>>>> >>>>> I have to consult with Keith McGuigan about how to migrate the >>>>> Solaris >>>>> Dtrace implementation to the newer version. However, that work >>>>> will be >>>>> done independently of this bug (7098194). >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>> >>>>> >>>>> The above webrev has all the infrastructure (e.g., Makefile) >>>>> related >>>>> changes. Many/most folks aren't interested in Makefile stuff >>>>> so I've >>>>> put these changes in their own subset. Of course, I need Kelly >>>>> O'Hair >>>>> to bless these changes... >>>>> >>>>> Builds done so far: >>>>> >>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>>> jvmg} >>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with >>>>> new HSX repo >>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>>>> HSX repo >>>>> >>>>> Testing done so far: >>>>> >>>>> - Serviceability stack (25 subsuites): >>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>> logging, mm >>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>> misc_attach, misc_jvmstat, misc_tools >>>>> - Tested configs (8 configs) >>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>> >>>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>>> i.e., did the build "work"? >>>>> >>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>> testing should be finished later today. >>>>> >>>>> Things still to do (in no particular order): >>>>> >>>>> - gather the list of contributors for the changeset comment >>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>> - dtrace testing on Solaris X86 >>>>> - code review >>>>> - start bring up of more formal dev testing on MacOS X >>>>> >>>>> Thanks, in advance, for any review comments. >>>>> >>>>> Dan >>>>> >>> >> From daniel.daugherty at oracle.com Wed Oct 12 15:33:03 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 16:33:03 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E95FF03.8090803@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> <4E95FF03.8090803@oracle.com> Message-ID: <4E96159F.2090805@oracle.com> Paul, Thanks for the thorough review. Replies embedded below. On 10/12/11 2:56 PM, Paul Hohensee wrote: > The printf format thing is handled in globalDefinitions.hpp via > system-dependent > macros named INTX_FORMAT, PTR_FORMAT, etc. There should be no direct > uses of > printf format specifiers in Hotspot code, so the change to jni_x86.h > should go > away and any uses of %lld and %ld should be replaced by the > appropriate FORMAT > macro. If needed, you can use the platform-specific extensions to > globalDefinitions.hpp > in the cpu and utilities directories. Based on what Roger said, I suspect that if I remove the change to jni_x86.h (typedef long long jlong on __APPLE__), then I'll have some non-trivial amount of warnings fallout that I'll need to deal with. I'm willing to do that, but not right now and not with this changeset. The clock is ticking on getting this changeset pushed and I don't consider this a showstopper. > If set_native_thread_name() is an implementation of an extension to > Thread, > then I'd recommend leaving it and the supporting code out (and there's > a lot of > it, vis jvm.cpp as you point out) until the core libs people figure > out how > they want to handle it. Maybe file an RFE for the work. If I remove that support, then I won't be able to use the resulting VM with the rest of the macosx-port forest, right? Part of my bring up strategy relies on my being able to use the HSX-23 port bits with the rest of the macosx-port built bits... > In debug.cpp, I'd make Debugging a product flag if you're going to > make Command > a product class. That way you don't need the #ifndef PRODUCT around > its uses. Done. > There's a use of "%#p" at line 481 in the Old file (487 in the New > one) that should > be replaced by PTR_FORMAT. Fixed. > The comment on line 496 of the New version should > be "!PRODUCT" rather than "PRODUCT". Fixed there and in other places in the file. > You might change pss() to read > > 577 extern "C" void pss() { // print all stacks > 578 if (!Thread::current()) return; > 579 Command c("pss"); > 581 Threads::print(true, PRODUCT_ONLY(false) NOT_PRODUCT(true)); > 585 } > > > It's perhaps a bit neater. Fixed the print() call on line 581. > Re "!Thread::current()", the rule in hotspot is to make > comparisons to null explicit, so you could use instead > "Thread::current() != NULL", > because what NULL is varies by platform. Fixed both !current() uses in the file. Dan > > Paul > > On 10/12/11 2:34 PM, roger hoover wrote: >> As I promised Dan earlier this morning....replies embedded: >> >> On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: >> >>> David, >>> >>> Thanks for the thorough review (as always). Replies embedded below. >>> >>> >>> On 10/11/11 10:48 PM, David Holmes wrote: >>>> Hi Dan, >>>> >>>> src/cpu/x86/vm/jni_x86.h >>>> >>>> I don't understand why this change would be needed: >>>> >>>> ! #if defined(_LP64)&& !defined(__APPLE__) >>>> typedef long jlong; >>>> #else >>>> typedef long long jlong; >>>> #endif >>>> >>>> this is saying that on "apple" under _LP64 a long is not 64-bits. >>>> But the very definition of LP64 is that longs and pointers are >>>> 64-bits. ??? >>> $ cat sizes.c >>> #include >>> >>> int main() { >>> printf("Hello world! _LP64="); >>> #ifdef _LP64 >>> printf("%d\n", _LP64); >>> #else >>> printf("undefined\n"); >>> #endif >>> printf("sizeof(long) = %d\n", (int) sizeof(long)); >>> printf("sizeof(long long) = %d\n", (int) sizeof(long long)); >>> } >>> >>> Output on my MacOS 10.6.8 machine: >>> >>> Hello world! _LP64=1 >>> sizeof(long) = 8 >>> sizeof(long long) = 8 >>> >>> Output on my Solaris X86 machine: >>> >>> Hello world! _LP64=undefined >>> sizeof(long) = 4 >>> sizeof(long long) = 8 >>> >>> Output on my Solaris X86 machine when built with '-m64': >>> >>> Hello world! _LP64=1 >>> sizeof(long) = 8 >>> sizeof(long long) = 8 >>> >>> Since __APPLE__ machines have a 8 byte long, I don't understand >>> why the person thought that "long long jlong" was necessary... >>> >>> We need an Apple person to jump in here... >>> >> (answered before, but here it is again): >> This is likely due to the fprintf format usage mess. The hotspot >> code had assumed that any 64-bit fprintf format could be used with >> any 64-bit value. Apple compilers give warnings if you print a long >> with "%lld", and insists upon "%ld" for a clean compile even though >> both are 64-bit values. Changing the type to long long allows the >> format to remain unchanged. >> >> The correct way to fix this mess is to insure that the formats >> exactly match the types used. We couldn't pull this off at apple >> since we didn't have the capabilities to build under all of the other >> os platforms to test the changes. >> >>>> src/os//vm/os_.cpp >>>> >>>> + void os::set_native_thread_name(const char *name) { >>>> + // Not yet implemented. >>>> + return; >>>> + } >>>> >>>> I hate seeing "shared" code that is not implemented on 3 out of 4 >>>> supported platforms. Though it seems Linux will also support >>>> pthread_setname_np as of March 2010 (not sure which kernel or glibc >>>> versions needed). If not for the fact this also adds an exported >>>> JVM method to set the native thread name, we could otherwise bury >>>> this in the platform specific native thread creation code (which >>>> might also obviate the need for the new _is_attached logic - see >>>> next point). I also wonder what Java code is using this new JVM API? >>> I suspect that this new API is used by other pieces of the MacOS X >>> port project, but I don't know that for sure. Again, we need an >>> Apple person to jump in here. >> The native thread name addition was a huge win, both for us debugging >> and for our developer customers. The only complaint we had was from >> other projects whose code attached to Java and (in initial revisions) >> had their threads renamed. It is exported so that Thread.java can >> set the native thread name. >> >> I have no explanation for the lack of a return code. I can only >> surmise that it is an oversight that was not caught by the compiler. >> >> The other pieces are: >> macosx-port/jdk/src/share/native/java/lang/Thread.c: >> {"getThreads", "()[" THD, (void *)&JVM_GetAllThreads}, >> {"dumpThreads", "([" THD ")[[" STE, (void *)&JVM_DumpThreads}, >> --> {"setNativeName", "(" STR ")V", (void >> *)&JVM_SetNativeThreadName}, >> }; >> -and- >> macosx-port/jdk/src/share/classes/java/lang/Thread.java >> /** >> * Changes the name of this thread to be equal to the argument >> *name. >> *

>> * First thecheckAccess method of this thread is >> called >> * with no arguments. This may result in throwing a >> *SecurityException. >> * >> * @param name the new name for this thread. >> * @exception SecurityException if the current thread cannot >> modify this >> * thread. >> * @see #getName >> * @see #checkAccess() >> */ >> public final void setName(String name) { >> checkAccess(); >> this.name = name.toCharArray(); >> --> if (threadStatus != 0) { >> --> setNativeName(name); >> --> } >> } >>> >>>> Also wondering where the "current thread only" restriction came about? >>> If the API is restricted to the "current thread", then we don't have >>> to worry about races and locking. Also, I'm wondering why there is no >>> return code. >>> >>> >>>> src/share/vm/runtime/thread.hpp >>>> >>>> + // Remember whether or not we were attached >>>> + bool _is_attached; >>>> >>>> It took me a while to realize that _is_attached really means "was >>>> attached" ie that the Java thread came about due to a native thread >>>> attaching to the VM via JNI attachCurrentThread. Could I suggest >>>> this is renamed to was_attached? >>> I was taking another look at this. The key user of the new flag is: >>> >>> src/share/vm/prims/jvm.cpp >>> >>> JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject >>> jthread, jstring n >>> ame)) >>> JVMWrapper("JVM_SetNativeThreadName"); >>> ResourceMark rm(THREAD); >>> oop java_thread = JNIHandles::resolve_non_null(jthread); >>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>> // Thread naming only supported for the current thread, doesn't >>> work for >>> // target threads. >>> if (Thread::current() == thr&& !thr->is_attached()) { >>> // we don't set the name of an attached thread to avoid stepping >>> // on other programs >>> const char *thread_name = >>> java_lang_String::as_utf8_string(JNIHandles::reso >>> lve_non_null(name)); >>> os::set_native_thread_name(thread_name); >>> } >>> JVM_END >>> >>> which is coded to not set the name of a thread that has been >>> attached. In the JavaThread(bool) constructor: >>> >>> _is_attached = _is_attaching = is_attaching; >>> >>> we set both flags to the "is_attaching" parameter (default false) >>> so if we're coming down the JNI attach path, that parameter >>> should be true so we set both flags to true. After the thread >>> has been properly attached, we call set_attached() which sets >>> the _is_attaching flag to false. Whew! >>> >>> In the JavaThread(ThreadFunction, size_t) constructor we set >>> both flags to false because we're not attaching... and we >>> didn't come down the JNI attach path. >>> >>> I don't like the "was attached" attribute and I no longer like >>> the "is attaching" and "is attached" attributes either. Sigh. >>> I think both fields need to be cleaned up and renamed. Perhaps >>> something like: >>> >>> is_attaching_via_jni >>> was_attached_via_jni >>> >>> would be more clear? >>> >>> >>>> src/share/vm/utilities/debug.cpp >>>> >>>> Why are we exposing this debug code in a product build? >>> We'll need an Apple person to jump in here... >>> >>> >> It has been an Apple tradition (from long before I joined the Java >> team in 2004) to include a basic set of debugging routines in product >> builds. We call them from gdb while debugging problems that don't >> show up in debug builds, and we've told our developer customers about >> them. The rest of the Apple port does not depend on these and >> whether or not to continue Apple's tradition is totally up to Oracle. >> >>>> src/share/vm/prims/jni.cpp >>>> >>>> The USDT2 ifdef changes are truly ugly especially in this file. Is >>>> there no way to hide USDT1 vs USDT2 at a lower level so that the >>>> top-level probe points are not affected? I know this is flagged for >>>> "future work" but history shows such cleans ups rarely if ever >>>> happen - and this current code really is pretty awful to look at. >>> Yes, the #ifdef'ing makes the current code awful. I don't think >>> anyone will dispute that observation. >>> >>> The better solution would be for Solaris to migrate to USDT2. >>> I'm discussing that with Keith McGuigan. However, I don't want >>> to take much of his time right now because he is hip deep in >>> another alligator swamp at the moment. >>> >>> The best I can offer at the moment is filing a new bug to track >>> the future work. Yes, I know that clean up type work rarely gets >>> done, but this merge with the MacOS X port project needs to get >>> into HSX-23 as soon as possible. Broken functionality in the >>> other platforms is a stopper, but ugly is not a stopper. >>> >>> Thanks again for the thorough review. >>> >>> Dan >>> >>> >>>> Cheers, >>>> David >>>> >>>> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>> >>>>> 7089790 integrate bsd-port changes >>>>> >>>>> and I'm following up on that work using the following bug: >>>>> >>>>> 7098194 integrate macosx-port changes >>>>> >>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>> include additional changes from the BSD Port in addition the deltas >>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>> this resync is: >>>>> >>>>> changeset: 2729:f1a18ada5853 >>>>> tag: tip >>>>> user: Greg Lewis >>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>> summary: . Finish removing hsearch_r. >>>>> >>>>> The macosx-port/hotspot changeset for this merge is: >>>>> >>>>> changeset: 2756:69de8d34a370 >>>>> tag: tip >>>>> user: swingler at apple.com >>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>> >>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>>> Shaking out the MacOS X Port itself will be done with other >>>>> changesets >>>>> on an as needed basis. >>>>> >>>>> Just to be clear, the push target for this changeset is the >>>>> RT_Baseline >>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>> >>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>> >>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>>> can review these changes in different ways. My primary focus here is >>>>> the common or shared code so I'm less worried about the BSD or >>>>> MacOS X >>>>> specific changes. Obviously, if you see something I messed up in >>>>> those >>>>> files, I'd like to know. >>>>> >>>>> Here's the webrev for all the changes in one shot: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>> >>>>> >>>>> The order of the files in the above webrev is the same as for >>>>> for the subset webrevs below. >>>>> >>>>> Here's the webrevs for the changes in subsets: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>> >>>>> >>>>> >>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>> >>>>> >>>>> >>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>> made for the MacOS X port. There's a couple of files that also >>>>> contain >>>>> Dtrace related changes, but I decided it was better to include those >>>>> files in this subset. >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>> >>>>> >>>>> >>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>>> which is why the code is #ifdef'ed. I had to change the original >>>>> #ifdef'ing because the original implementation had put some >>>>> non-Dtrace >>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>> >>>>> #ifndef USDT2 >>>>> >>>>> >>>>> >>>>> #else /* USDT2 */ >>>>> >>>>> #endif /* USDT2 */ >>>>> >>>>> #ifndef USDT2 >>>>> >>>>> >>>>> #endif /* ! USDT2 */ >>>>> >>>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>>> HotSpot style guidelines very consistently, but I decided not to fix >>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>> >>>>> I have to consult with Keith McGuigan about how to migrate the >>>>> Solaris >>>>> Dtrace implementation to the newer version. However, that work >>>>> will be >>>>> done independently of this bug (7098194). >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>> >>>>> >>>>> >>>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>>> to bless these changes... >>>>> >>>>> Builds done so far: >>>>> >>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>>> jvmg} >>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with >>>>> new HSX >>>>> repo >>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>>>> HSX repo >>>>> >>>>> Testing done so far: >>>>> >>>>> - Serviceability stack (25 subsuites): >>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>> logging, mm >>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>> misc_attach, misc_jvmstat, misc_tools >>>>> - Tested configs (8 configs) >>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>> >>>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>>> i.e., did the build "work"? >>>>> >>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>> testing should be finished later today. >>>>> >>>>> Things still to do (in no particular order): >>>>> >>>>> - gather the list of contributors for the changeset comment >>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>> - dtrace testing on Solaris X86 >>>>> - code review >>>>> - start bring up of more formal dev testing on MacOS X >>>>> >>>>> Thanks, in advance, for any review comments. >>>>> >>>>> Dan >>>>> >> From paul.hohensee at oracle.com Wed Oct 12 15:47:36 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 12 Oct 2011 18:47:36 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E96159F.2090805@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> <4E95FF03.8090803@oracle.com> <4E96159F.2090805@oracle.com> Message-ID: <4E961908.6040601@oracle.com> On 10/12/11 6:33 PM, Daniel D. Daugherty wrote: > Paul, > > Thanks for the thorough review. Replies embedded below. > > On 10/12/11 2:56 PM, Paul Hohensee wrote: >> The printf format thing is handled in globalDefinitions.hpp via >> system-dependent >> macros named INTX_FORMAT, PTR_FORMAT, etc. There should be no direct >> uses of >> printf format specifiers in Hotspot code, so the change to jni_x86.h >> should go >> away and any uses of %lld and %ld should be replaced by the >> appropriate FORMAT >> macro. If needed, you can use the platform-specific extensions to >> globalDefinitions.hpp >> in the cpu and utilities directories. > > Based on what Roger said, I suspect that if I remove the change to > jni_x86.h (typedef long long jlong on __APPLE__), then I'll have > some non-trivial amount of warnings fallout that I'll need to > deal with. I'm willing to do that, but not right now and not with > this changeset. The clock is ticking on getting this changeset > pushed and I don't consider this a showstopper. Ok. Another RFE. > > >> If set_native_thread_name() is an implementation of an extension to >> Thread, >> then I'd recommend leaving it and the supporting code out (and >> there's a lot of >> it, vis jvm.cpp as you point out) until the core libs people figure >> out how >> they want to handle it. Maybe file an RFE for the work. > > If I remove that support, then I won't be able to use the resulting > VM with the rest of the macosx-port forest, right? Part of my > bring up strategy relies on my being able to use the HSX-23 port > bits with the rest of the macosx-port built bits... True. But it may not be used in it's current form. Thanks, Paul > > >> In debug.cpp, I'd make Debugging a product flag if you're going to >> make Command >> a product class. That way you don't need the #ifndef PRODUCT around >> its uses. > > Done. > > >> There's a use of "%#p" at line 481 in the Old file (487 in the New >> one) that should >> be replaced by PTR_FORMAT. > > Fixed. > > >> The comment on line 496 of the New version should >> be "!PRODUCT" rather than "PRODUCT". > > Fixed there and in other places in the file. > > >> You might change pss() to read >> >> 577 extern "C" void pss() { // print all stacks >> 578 if (!Thread::current()) return; >> 579 Command c("pss"); >> 581 Threads::print(true, PRODUCT_ONLY(false) NOT_PRODUCT(true)); >> 585 } >> >> >> It's perhaps a bit neater. > > Fixed the print() call on line 581. > > >> Re "!Thread::current()", the rule in hotspot is to make >> comparisons to null explicit, so you could use instead >> "Thread::current() != NULL", >> because what NULL is varies by platform. > > Fixed both !current() uses in the file. > > Dan > > >> >> Paul >> >> On 10/12/11 2:34 PM, roger hoover wrote: >>> As I promised Dan earlier this morning....replies embedded: >>> >>> On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: >>> >>>> David, >>>> >>>> Thanks for the thorough review (as always). Replies embedded below. >>>> >>>> >>>> On 10/11/11 10:48 PM, David Holmes wrote: >>>>> Hi Dan, >>>>> >>>>> src/cpu/x86/vm/jni_x86.h >>>>> >>>>> I don't understand why this change would be needed: >>>>> >>>>> ! #if defined(_LP64)&& !defined(__APPLE__) >>>>> typedef long jlong; >>>>> #else >>>>> typedef long long jlong; >>>>> #endif >>>>> >>>>> this is saying that on "apple" under _LP64 a long is not 64-bits. >>>>> But the very definition of LP64 is that longs and pointers are >>>>> 64-bits. ??? >>>> $ cat sizes.c >>>> #include >>>> >>>> int main() { >>>> printf("Hello world! _LP64="); >>>> #ifdef _LP64 >>>> printf("%d\n", _LP64); >>>> #else >>>> printf("undefined\n"); >>>> #endif >>>> printf("sizeof(long) = %d\n", (int) sizeof(long)); >>>> printf("sizeof(long long) = %d\n", (int) sizeof(long long)); >>>> } >>>> >>>> Output on my MacOS 10.6.8 machine: >>>> >>>> Hello world! _LP64=1 >>>> sizeof(long) = 8 >>>> sizeof(long long) = 8 >>>> >>>> Output on my Solaris X86 machine: >>>> >>>> Hello world! _LP64=undefined >>>> sizeof(long) = 4 >>>> sizeof(long long) = 8 >>>> >>>> Output on my Solaris X86 machine when built with '-m64': >>>> >>>> Hello world! _LP64=1 >>>> sizeof(long) = 8 >>>> sizeof(long long) = 8 >>>> >>>> Since __APPLE__ machines have a 8 byte long, I don't understand >>>> why the person thought that "long long jlong" was necessary... >>>> >>>> We need an Apple person to jump in here... >>>> >>> (answered before, but here it is again): >>> This is likely due to the fprintf format usage mess. The hotspot >>> code had assumed that any 64-bit fprintf format could be used with >>> any 64-bit value. Apple compilers give warnings if you print a long >>> with "%lld", and insists upon "%ld" for a clean compile even though >>> both are 64-bit values. Changing the type to long long allows the >>> format to remain unchanged. >>> >>> The correct way to fix this mess is to insure that the formats >>> exactly match the types used. We couldn't pull this off at apple >>> since we didn't have the capabilities to build under all of the >>> other os platforms to test the changes. >>> >>>>> src/os//vm/os_.cpp >>>>> >>>>> + void os::set_native_thread_name(const char *name) { >>>>> + // Not yet implemented. >>>>> + return; >>>>> + } >>>>> >>>>> I hate seeing "shared" code that is not implemented on 3 out of 4 >>>>> supported platforms. Though it seems Linux will also support >>>>> pthread_setname_np as of March 2010 (not sure which kernel or >>>>> glibc versions needed). If not for the fact this also adds an >>>>> exported JVM method to set the native thread name, we could >>>>> otherwise bury this in the platform specific native thread >>>>> creation code (which might also obviate the need for the new >>>>> _is_attached logic - see next point). I also wonder what Java code >>>>> is using this new JVM API? >>>> I suspect that this new API is used by other pieces of the MacOS X >>>> port project, but I don't know that for sure. Again, we need an >>>> Apple person to jump in here. >>> The native thread name addition was a huge win, both for us >>> debugging and for our developer customers. The only complaint we >>> had was from other projects whose code attached to Java and (in >>> initial revisions) had their threads renamed. It is exported so >>> that Thread.java can set the native thread name. >>> >>> I have no explanation for the lack of a return code. I can only >>> surmise that it is an oversight that was not caught by the compiler. >>> >>> The other pieces are: >>> macosx-port/jdk/src/share/native/java/lang/Thread.c: >>> {"getThreads", "()[" THD, (void *)&JVM_GetAllThreads}, >>> {"dumpThreads", "([" THD ")[[" STE, (void >>> *)&JVM_DumpThreads}, >>> --> {"setNativeName", "(" STR ")V", (void >>> *)&JVM_SetNativeThreadName}, >>> }; >>> -and- >>> macosx-port/jdk/src/share/classes/java/lang/Thread.java >>> /** >>> * Changes the name of this thread to be equal to the argument >>> *name. >>> *

>>> * First thecheckAccess method of this thread is >>> called >>> * with no arguments. This may result in throwing a >>> *SecurityException. >>> * >>> * @param name the new name for this thread. >>> * @exception SecurityException if the current thread cannot >>> modify this >>> * thread. >>> * @see #getName >>> * @see #checkAccess() >>> */ >>> public final void setName(String name) { >>> checkAccess(); >>> this.name = name.toCharArray(); >>> --> if (threadStatus != 0) { >>> --> setNativeName(name); >>> --> } >>> } >>>> >>>>> Also wondering where the "current thread only" restriction came >>>>> about? >>>> If the API is restricted to the "current thread", then we don't have >>>> to worry about races and locking. Also, I'm wondering why there is no >>>> return code. >>>> >>>> >>>>> src/share/vm/runtime/thread.hpp >>>>> >>>>> + // Remember whether or not we were attached >>>>> + bool _is_attached; >>>>> >>>>> It took me a while to realize that _is_attached really means "was >>>>> attached" ie that the Java thread came about due to a native >>>>> thread attaching to the VM via JNI attachCurrentThread. Could I >>>>> suggest this is renamed to was_attached? >>>> I was taking another look at this. The key user of the new flag is: >>>> >>>> src/share/vm/prims/jvm.cpp >>>> >>>> JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject >>>> jthread, jstring n >>>> ame)) >>>> JVMWrapper("JVM_SetNativeThreadName"); >>>> ResourceMark rm(THREAD); >>>> oop java_thread = JNIHandles::resolve_non_null(jthread); >>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>> // Thread naming only supported for the current thread, doesn't >>>> work for >>>> // target threads. >>>> if (Thread::current() == thr&& !thr->is_attached()) { >>>> // we don't set the name of an attached thread to avoid stepping >>>> // on other programs >>>> const char *thread_name = >>>> java_lang_String::as_utf8_string(JNIHandles::reso >>>> lve_non_null(name)); >>>> os::set_native_thread_name(thread_name); >>>> } >>>> JVM_END >>>> >>>> which is coded to not set the name of a thread that has been >>>> attached. In the JavaThread(bool) constructor: >>>> >>>> _is_attached = _is_attaching = is_attaching; >>>> >>>> we set both flags to the "is_attaching" parameter (default false) >>>> so if we're coming down the JNI attach path, that parameter >>>> should be true so we set both flags to true. After the thread >>>> has been properly attached, we call set_attached() which sets >>>> the _is_attaching flag to false. Whew! >>>> >>>> In the JavaThread(ThreadFunction, size_t) constructor we set >>>> both flags to false because we're not attaching... and we >>>> didn't come down the JNI attach path. >>>> >>>> I don't like the "was attached" attribute and I no longer like >>>> the "is attaching" and "is attached" attributes either. Sigh. >>>> I think both fields need to be cleaned up and renamed. Perhaps >>>> something like: >>>> >>>> is_attaching_via_jni >>>> was_attached_via_jni >>>> >>>> would be more clear? >>>> >>>> >>>>> src/share/vm/utilities/debug.cpp >>>>> >>>>> Why are we exposing this debug code in a product build? >>>> We'll need an Apple person to jump in here... >>>> >>>> >>> It has been an Apple tradition (from long before I joined the Java >>> team in 2004) to include a basic set of debugging routines in >>> product builds. We call them from gdb while debugging problems that >>> don't show up in debug builds, and we've told our developer >>> customers about them. The rest of the Apple port does not depend on >>> these and whether or not to continue Apple's tradition is totally up >>> to Oracle. >>> >>>>> src/share/vm/prims/jni.cpp >>>>> >>>>> The USDT2 ifdef changes are truly ugly especially in this file. Is >>>>> there no way to hide USDT1 vs USDT2 at a lower level so that the >>>>> top-level probe points are not affected? I know this is flagged >>>>> for "future work" but history shows such cleans ups rarely if ever >>>>> happen - and this current code really is pretty awful to look at. >>>> Yes, the #ifdef'ing makes the current code awful. I don't think >>>> anyone will dispute that observation. >>>> >>>> The better solution would be for Solaris to migrate to USDT2. >>>> I'm discussing that with Keith McGuigan. However, I don't want >>>> to take much of his time right now because he is hip deep in >>>> another alligator swamp at the moment. >>>> >>>> The best I can offer at the moment is filing a new bug to track >>>> the future work. Yes, I know that clean up type work rarely gets >>>> done, but this merge with the MacOS X port project needs to get >>>> into HSX-23 as soon as possible. Broken functionality in the >>>> other platforms is a stopper, but ugly is not a stopper. >>>> >>>> Thanks again for the thorough review. >>>> >>>> Dan >>>> >>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>>> >>>>>> 7089790 integrate bsd-port changes >>>>>> >>>>>> and I'm following up on that work using the following bug: >>>>>> >>>>>> 7098194 integrate macosx-port changes >>>>>> >>>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>>> include additional changes from the BSD Port in addition the deltas >>>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>>> this resync is: >>>>>> >>>>>> changeset: 2729:f1a18ada5853 >>>>>> tag: tip >>>>>> user: Greg Lewis >>>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>>> summary: . Finish removing hsearch_r. >>>>>> >>>>>> The macosx-port/hotspot changeset for this merge is: >>>>>> >>>>>> changeset: 2756:69de8d34a370 >>>>>> tag: tip >>>>>> user: swingler at apple.com >>>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>>> >>>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>>>> Shaking out the MacOS X Port itself will be done with other >>>>>> changesets >>>>>> on an as needed basis. >>>>>> >>>>>> Just to be clear, the push target for this changeset is the >>>>>> RT_Baseline >>>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>>> >>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>>> >>>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>>>> can review these changes in different ways. My primary focus here is >>>>>> the common or shared code so I'm less worried about the BSD or >>>>>> MacOS X >>>>>> specific changes. Obviously, if you see something I messed up in >>>>>> those >>>>>> files, I'd like to know. >>>>>> >>>>>> Here's the webrev for all the changes in one shot: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>>> >>>>>> >>>>>> The order of the files in the above webrev is the same as for >>>>>> for the subset webrevs below. >>>>>> >>>>>> Here's the webrevs for the changes in subsets: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>>> made for the MacOS X port. There's a couple of files that also >>>>>> contain >>>>>> Dtrace related changes, but I decided it was better to include those >>>>>> files in this subset. >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>>>> which is why the code is #ifdef'ed. I had to change the original >>>>>> #ifdef'ing because the original implementation had put some >>>>>> non-Dtrace >>>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>>> >>>>>> #ifndef USDT2 >>>>>> >>>>>> >>>>>> >>>>>> #else /* USDT2 */ >>>>>> >>>>>> #endif /* USDT2 */ >>>>>> >>>>>> #ifndef USDT2 >>>>>> >>>>>> >>>>>> #endif /* ! USDT2 */ >>>>>> >>>>>> Yes, I realize that the MacOS X Dtrace implementation does not >>>>>> follow >>>>>> HotSpot style guidelines very consistently, but I decided not to fix >>>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>>> >>>>>> I have to consult with Keith McGuigan about how to migrate the >>>>>> Solaris >>>>>> Dtrace implementation to the newer version. However, that work >>>>>> will be >>>>>> done independently of this bug (7098194). >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>>>> put these changes in their own subset. Of course, I need Kelly >>>>>> O'Hair >>>>>> to bless these changes... >>>>>> >>>>>> Builds done so far: >>>>>> >>>>>> - Solaris X86 builds of {Client, Server} VM * {product, >>>>>> fastdebug, jvmg} >>>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with >>>>>> new HSX >>>>>> repo >>>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>>>>> HSX repo >>>>>> >>>>>> Testing done so far: >>>>>> >>>>>> - Serviceability stack (25 subsuites): >>>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>>> logging, mm >>>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>>> misc_attach, misc_jvmstat, misc_tools >>>>>> - Tested configs (8 configs) >>>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>>> >>>>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>>>> i.e., did the build "work"? >>>>>> >>>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>>> testing should be finished later today. >>>>>> >>>>>> Things still to do (in no particular order): >>>>>> >>>>>> - gather the list of contributors for the changeset comment >>>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>>> - dtrace testing on Solaris X86 >>>>>> - code review >>>>>> - start bring up of more formal dev testing on MacOS X >>>>>> >>>>>> Thanks, in advance, for any review comments. >>>>>> >>>>>> Dan >>>>>> >>> From daniel.daugherty at oracle.com Wed Oct 12 15:53:38 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 16:53:38 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E961908.6040601@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> <4E95FF03.8090803@oracle.com> <4E96159F.2090805@oracle.com> <4E961908.6040601@oracle.com> Message-ID: <4E961A72.8000301@oracle.com> > On 10/12/11 6:33 PM, Daniel D. Daugherty wrote: >> Paul, >> >> Thanks for the thorough review. Replies embedded below. >> >> On 10/12/11 2:56 PM, Paul Hohensee wrote: >>> The printf format thing is handled in globalDefinitions.hpp via >>> system-dependent >>> macros named INTX_FORMAT, PTR_FORMAT, etc. There should be no >>> direct uses of >>> printf format specifiers in Hotspot code, so the change to jni_x86.h >>> should go >>> away and any uses of %lld and %ld should be replaced by the >>> appropriate FORMAT >>> macro. If needed, you can use the platform-specific extensions to >>> globalDefinitions.hpp >>> in the cpu and utilities directories. >> >> Based on what Roger said, I suspect that if I remove the change to >> jni_x86.h (typedef long long jlong on __APPLE__), then I'll have >> some non-trivial amount of warnings fallout that I'll need to >> deal with. I'm willing to do that, but not right now and not with >> this changeset. The clock is ticking on getting this changeset >> pushed and I don't consider this a showstopper. > > Ok. Another RFE. Yes. > >> >> >>> If set_native_thread_name() is an implementation of an extension to >>> Thread, >>> then I'd recommend leaving it and the supporting code out (and >>> there's a lot of >>> it, vis jvm.cpp as you point out) until the core libs people figure >>> out how >>> they want to handle it. Maybe file an RFE for the work. >> >> If I remove that support, then I won't be able to use the resulting >> VM with the rest of the macosx-port forest, right? Part of my >> bring up strategy relies on my being able to use the HSX-23 port >> bits with the rest of the macosx-port built bits... > > True. But it may not be used in it's current form. I think it is: jdk/src/share/javavm/export/jvm.h:JVM_SetNativeThreadName(JNIEnv *env, jobject jthread, jstring name); jdk/src/share/native/java/lang/Thread.c: {"setNativeName", "(" STR ")V", (void *)&JVM_SetNativeThreadName}, jdk/src/share/classes/java/lang/Thread.java: setNativeName(name); jdk/src/share/classes/java/lang/Thread.java: private native void setNativeName(String name); Dan > > Thanks, > > Paul > >> >> >>> In debug.cpp, I'd make Debugging a product flag if you're going to >>> make Command >>> a product class. That way you don't need the #ifndef PRODUCT around >>> its uses. >> >> Done. >> >> >>> There's a use of "%#p" at line 481 in the Old file (487 in the New >>> one) that should >>> be replaced by PTR_FORMAT. >> >> Fixed. >> >> >>> The comment on line 496 of the New version should >>> be "!PRODUCT" rather than "PRODUCT". >> >> Fixed there and in other places in the file. >> >> >>> You might change pss() to read >>> >>> 577 extern "C" void pss() { // print all stacks >>> 578 if (!Thread::current()) return; >>> 579 Command c("pss"); >>> 581 Threads::print(true, PRODUCT_ONLY(false) NOT_PRODUCT(true)); >>> 585 } >>> >>> >>> It's perhaps a bit neater. >> >> Fixed the print() call on line 581. >> >> >>> Re "!Thread::current()", the rule in hotspot is to make >>> comparisons to null explicit, so you could use instead >>> "Thread::current() != NULL", >>> because what NULL is varies by platform. >> >> Fixed both !current() uses in the file. >> >> Dan >> >> >>> >>> Paul >>> >>> On 10/12/11 2:34 PM, roger hoover wrote: >>>> As I promised Dan earlier this morning....replies embedded: >>>> >>>> On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: >>>> >>>>> David, >>>>> >>>>> Thanks for the thorough review (as always). Replies embedded below. >>>>> >>>>> >>>>> On 10/11/11 10:48 PM, David Holmes wrote: >>>>>> Hi Dan, >>>>>> >>>>>> src/cpu/x86/vm/jni_x86.h >>>>>> >>>>>> I don't understand why this change would be needed: >>>>>> >>>>>> ! #if defined(_LP64)&& !defined(__APPLE__) >>>>>> typedef long jlong; >>>>>> #else >>>>>> typedef long long jlong; >>>>>> #endif >>>>>> >>>>>> this is saying that on "apple" under _LP64 a long is not 64-bits. >>>>>> But the very definition of LP64 is that longs and pointers are >>>>>> 64-bits. ??? >>>>> $ cat sizes.c >>>>> #include >>>>> >>>>> int main() { >>>>> printf("Hello world! _LP64="); >>>>> #ifdef _LP64 >>>>> printf("%d\n", _LP64); >>>>> #else >>>>> printf("undefined\n"); >>>>> #endif >>>>> printf("sizeof(long) = %d\n", (int) sizeof(long)); >>>>> printf("sizeof(long long) = %d\n", (int) sizeof(long long)); >>>>> } >>>>> >>>>> Output on my MacOS 10.6.8 machine: >>>>> >>>>> Hello world! _LP64=1 >>>>> sizeof(long) = 8 >>>>> sizeof(long long) = 8 >>>>> >>>>> Output on my Solaris X86 machine: >>>>> >>>>> Hello world! _LP64=undefined >>>>> sizeof(long) = 4 >>>>> sizeof(long long) = 8 >>>>> >>>>> Output on my Solaris X86 machine when built with '-m64': >>>>> >>>>> Hello world! _LP64=1 >>>>> sizeof(long) = 8 >>>>> sizeof(long long) = 8 >>>>> >>>>> Since __APPLE__ machines have a 8 byte long, I don't understand >>>>> why the person thought that "long long jlong" was necessary... >>>>> >>>>> We need an Apple person to jump in here... >>>>> >>>> (answered before, but here it is again): >>>> This is likely due to the fprintf format usage mess. The hotspot >>>> code had assumed that any 64-bit fprintf format could be used with >>>> any 64-bit value. Apple compilers give warnings if you print a >>>> long with "%lld", and insists upon "%ld" for a clean compile even >>>> though both are 64-bit values. Changing the type to long long >>>> allows the format to remain unchanged. >>>> >>>> The correct way to fix this mess is to insure that the formats >>>> exactly match the types used. We couldn't pull this off at apple >>>> since we didn't have the capabilities to build under all of the >>>> other os platforms to test the changes. >>>> >>>>>> src/os//vm/os_.cpp >>>>>> >>>>>> + void os::set_native_thread_name(const char *name) { >>>>>> + // Not yet implemented. >>>>>> + return; >>>>>> + } >>>>>> >>>>>> I hate seeing "shared" code that is not implemented on 3 out of 4 >>>>>> supported platforms. Though it seems Linux will also support >>>>>> pthread_setname_np as of March 2010 (not sure which kernel or >>>>>> glibc versions needed). If not for the fact this also adds an >>>>>> exported JVM method to set the native thread name, we could >>>>>> otherwise bury this in the platform specific native thread >>>>>> creation code (which might also obviate the need for the new >>>>>> _is_attached logic - see next point). I also wonder what Java >>>>>> code is using this new JVM API? >>>>> I suspect that this new API is used by other pieces of the MacOS X >>>>> port project, but I don't know that for sure. Again, we need an >>>>> Apple person to jump in here. >>>> The native thread name addition was a huge win, both for us >>>> debugging and for our developer customers. The only complaint we >>>> had was from other projects whose code attached to Java and (in >>>> initial revisions) had their threads renamed. It is exported so >>>> that Thread.java can set the native thread name. >>>> >>>> I have no explanation for the lack of a return code. I can only >>>> surmise that it is an oversight that was not caught by the compiler. >>>> >>>> The other pieces are: >>>> macosx-port/jdk/src/share/native/java/lang/Thread.c: >>>> {"getThreads", "()[" THD, (void *)&JVM_GetAllThreads}, >>>> {"dumpThreads", "([" THD ")[[" STE, (void >>>> *)&JVM_DumpThreads}, >>>> --> {"setNativeName", "(" STR ")V", (void >>>> *)&JVM_SetNativeThreadName}, >>>> }; >>>> -and- >>>> macosx-port/jdk/src/share/classes/java/lang/Thread.java >>>> /** >>>> * Changes the name of this thread to be equal to the argument >>>> *name. >>>> *

>>>> * First thecheckAccess method of this thread is >>>> called >>>> * with no arguments. This may result in throwing a >>>> *SecurityException. >>>> * >>>> * @param name the new name for this thread. >>>> * @exception SecurityException if the current thread cannot >>>> modify this >>>> * thread. >>>> * @see #getName >>>> * @see #checkAccess() >>>> */ >>>> public final void setName(String name) { >>>> checkAccess(); >>>> this.name = name.toCharArray(); >>>> --> if (threadStatus != 0) { >>>> --> setNativeName(name); >>>> --> } >>>> } >>>>> >>>>>> Also wondering where the "current thread only" restriction came >>>>>> about? >>>>> If the API is restricted to the "current thread", then we don't have >>>>> to worry about races and locking. Also, I'm wondering why there is no >>>>> return code. >>>>> >>>>> >>>>>> src/share/vm/runtime/thread.hpp >>>>>> >>>>>> + // Remember whether or not we were attached >>>>>> + bool _is_attached; >>>>>> >>>>>> It took me a while to realize that _is_attached really means "was >>>>>> attached" ie that the Java thread came about due to a native >>>>>> thread attaching to the VM via JNI attachCurrentThread. Could I >>>>>> suggest this is renamed to was_attached? >>>>> I was taking another look at this. The key user of the new flag is: >>>>> >>>>> src/share/vm/prims/jvm.cpp >>>>> >>>>> JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject >>>>> jthread, jstring n >>>>> ame)) >>>>> JVMWrapper("JVM_SetNativeThreadName"); >>>>> ResourceMark rm(THREAD); >>>>> oop java_thread = JNIHandles::resolve_non_null(jthread); >>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>> // Thread naming only supported for the current thread, doesn't >>>>> work for >>>>> // target threads. >>>>> if (Thread::current() == thr&& !thr->is_attached()) { >>>>> // we don't set the name of an attached thread to avoid stepping >>>>> // on other programs >>>>> const char *thread_name = >>>>> java_lang_String::as_utf8_string(JNIHandles::reso >>>>> lve_non_null(name)); >>>>> os::set_native_thread_name(thread_name); >>>>> } >>>>> JVM_END >>>>> >>>>> which is coded to not set the name of a thread that has been >>>>> attached. In the JavaThread(bool) constructor: >>>>> >>>>> _is_attached = _is_attaching = is_attaching; >>>>> >>>>> we set both flags to the "is_attaching" parameter (default false) >>>>> so if we're coming down the JNI attach path, that parameter >>>>> should be true so we set both flags to true. After the thread >>>>> has been properly attached, we call set_attached() which sets >>>>> the _is_attaching flag to false. Whew! >>>>> >>>>> In the JavaThread(ThreadFunction, size_t) constructor we set >>>>> both flags to false because we're not attaching... and we >>>>> didn't come down the JNI attach path. >>>>> >>>>> I don't like the "was attached" attribute and I no longer like >>>>> the "is attaching" and "is attached" attributes either. Sigh. >>>>> I think both fields need to be cleaned up and renamed. Perhaps >>>>> something like: >>>>> >>>>> is_attaching_via_jni >>>>> was_attached_via_jni >>>>> >>>>> would be more clear? >>>>> >>>>> >>>>>> src/share/vm/utilities/debug.cpp >>>>>> >>>>>> Why are we exposing this debug code in a product build? >>>>> We'll need an Apple person to jump in here... >>>>> >>>>> >>>> It has been an Apple tradition (from long before I joined the Java >>>> team in 2004) to include a basic set of debugging routines in >>>> product builds. We call them from gdb while debugging problems >>>> that don't show up in debug builds, and we've told our developer >>>> customers about them. The rest of the Apple port does not depend >>>> on these and whether or not to continue Apple's tradition is >>>> totally up to Oracle. >>>> >>>>>> src/share/vm/prims/jni.cpp >>>>>> >>>>>> The USDT2 ifdef changes are truly ugly especially in this file. >>>>>> Is there no way to hide USDT1 vs USDT2 at a lower level so that >>>>>> the top-level probe points are not affected? I know this is >>>>>> flagged for "future work" but history shows such cleans ups >>>>>> rarely if ever happen - and this current code really is pretty >>>>>> awful to look at. >>>>> Yes, the #ifdef'ing makes the current code awful. I don't think >>>>> anyone will dispute that observation. >>>>> >>>>> The better solution would be for Solaris to migrate to USDT2. >>>>> I'm discussing that with Keith McGuigan. However, I don't want >>>>> to take much of his time right now because he is hip deep in >>>>> another alligator swamp at the moment. >>>>> >>>>> The best I can offer at the moment is filing a new bug to track >>>>> the future work. Yes, I know that clean up type work rarely gets >>>>> done, but this merge with the MacOS X port project needs to get >>>>> into HSX-23 as soon as possible. Broken functionality in the >>>>> other platforms is a stopper, but ugly is not a stopper. >>>>> >>>>> Thanks again for the thorough review. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>>>> >>>>>>> 7089790 integrate bsd-port changes >>>>>>> >>>>>>> and I'm following up on that work using the following bug: >>>>>>> >>>>>>> 7098194 integrate macosx-port changes >>>>>>> >>>>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>>>> include additional changes from the BSD Port in addition the deltas >>>>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>>>> this resync is: >>>>>>> >>>>>>> changeset: 2729:f1a18ada5853 >>>>>>> tag: tip >>>>>>> user: Greg Lewis >>>>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>>>> summary: . Finish removing hsearch_r. >>>>>>> >>>>>>> The macosx-port/hotspot changeset for this merge is: >>>>>>> >>>>>>> changeset: 2756:69de8d34a370 >>>>>>> tag: tip >>>>>>> user: swingler at apple.com >>>>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>>>> >>>>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port >>>>>>> projects. >>>>>>> Shaking out the MacOS X Port itself will be done with other >>>>>>> changesets >>>>>>> on an as needed basis. >>>>>>> >>>>>>> Just to be clear, the push target for this changeset is the >>>>>>> RT_Baseline >>>>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>>>> >>>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>>>> >>>>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so >>>>>>> folks >>>>>>> can review these changes in different ways. My primary focus >>>>>>> here is >>>>>>> the common or shared code so I'm less worried about the BSD or >>>>>>> MacOS X >>>>>>> specific changes. Obviously, if you see something I messed up in >>>>>>> those >>>>>>> files, I'd like to know. >>>>>>> >>>>>>> Here's the webrev for all the changes in one shot: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>>>> >>>>>>> >>>>>>> The order of the files in the above webrev is the same as for >>>>>>> for the subset webrevs below. >>>>>>> >>>>>>> Here's the webrevs for the changes in subsets: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>>>> made for the MacOS X port. There's a couple of files that also >>>>>>> contain >>>>>>> Dtrace related changes, but I decided it was better to include >>>>>>> those >>>>>>> files in this subset. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>>>> On MacOS X, a newer version of Dtrace is implemented than on >>>>>>> Solaris >>>>>>> which is why the code is #ifdef'ed. I had to change the original >>>>>>> #ifdef'ing because the original implementation had put some >>>>>>> non-Dtrace >>>>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>>>>>> build on >>>>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>>>> >>>>>>> #ifndef USDT2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> #else /* USDT2 */ >>>>>>> >>>>>>> #endif /* USDT2 */ >>>>>>> >>>>>>> #ifndef USDT2 >>>>>>> >>>>>>> >>>>>> equivalent> >>>>>>> #endif /* ! USDT2 */ >>>>>>> >>>>>>> Yes, I realize that the MacOS X Dtrace implementation does not >>>>>>> follow >>>>>>> HotSpot style guidelines very consistently, but I decided not to >>>>>>> fix >>>>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>>>> >>>>>>> I have to consult with Keith McGuigan about how to migrate the >>>>>>> Solaris >>>>>>> Dtrace implementation to the newer version. However, that work >>>>>>> will be >>>>>>> done independently of this bug (7098194). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has all the infrastructure (e.g., Makefile) >>>>>>> related >>>>>>> changes. Many/most folks aren't interested in Makefile stuff so >>>>>>> I've >>>>>>> put these changes in their own subset. Of course, I need Kelly >>>>>>> O'Hair >>>>>>> to bless these changes... >>>>>>> >>>>>>> Builds done so far: >>>>>>> >>>>>>> - Solaris X86 builds of {Client, Server} VM * {product, >>>>>>> fastdebug, jvmg} >>>>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with >>>>>>> new HSX >>>>>>> repo >>>>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with >>>>>>> new HSX repo >>>>>>> >>>>>>> Testing done so far: >>>>>>> >>>>>>> - Serviceability stack (25 subsuites): >>>>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>>>> logging, mm >>>>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>>>> misc_attach, misc_jvmstat, misc_tools >>>>>>> - Tested configs (8 configs) >>>>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>>>> >>>>>>> - MacOS X builds have only had minimal 'java -version' type >>>>>>> testing, >>>>>>> i.e., did the build "work"? >>>>>>> >>>>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>>>> testing should be finished later today. >>>>>>> >>>>>>> Things still to do (in no particular order): >>>>>>> >>>>>>> - gather the list of contributors for the changeset comment >>>>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>>>> - dtrace testing on Solaris X86 >>>>>>> - code review >>>>>>> - start bring up of more formal dev testing on MacOS X >>>>>>> >>>>>>> Thanks, in advance, for any review comments. >>>>>>> >>>>>>> Dan >>>>>>> >>>> From tom.rodriguez at oracle.com Wed Oct 12 16:39:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Oct 2011 16:39:28 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E961A72.8000301@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> <4E95FF03.8090803@oracle.com> <4E96159F.2090805@oracle.com> <4E961908.6040601@oracle.com> <4E961A72.8000301@oracle.com> Message-ID: <64CDAA16-3F29-49F1-96B8-3AB842D4F0DC@oracle.com> On Oct 12, 2011, at 3:53 PM, Daniel D. Daugherty wrote: >> On 10/12/11 6:33 PM, Daniel D. Daugherty wrote: >>> Paul, >>> >>> Thanks for the thorough review. Replies embedded below. >>> >>> On 10/12/11 2:56 PM, Paul Hohensee wrote: >>>> The printf format thing is handled in globalDefinitions.hpp via system-dependent >>>> macros named INTX_FORMAT, PTR_FORMAT, etc. There should be no direct uses of >>>> printf format specifiers in Hotspot code, so the change to jni_x86.h should go >>>> away and any uses of %lld and %ld should be replaced by the appropriate FORMAT >>>> macro. If needed, you can use the platform-specific extensions to globalDefinitions.hpp >>>> in the cpu and utilities directories. >>> >>> Based on what Roger said, I suspect that if I remove the change to >>> jni_x86.h (typedef long long jlong on __APPLE__), then I'll have >>> some non-trivial amount of warnings fallout that I'll need to >>> deal with. I'm willing to do that, but not right now and not with >>> this changeset. The clock is ticking on getting this changeset >>> pushed and I don't consider this a showstopper. >> >> Ok. Another RFE. > > Yes. > >> >>> >>> >>>> If set_native_thread_name() is an implementation of an extension to Thread, >>>> then I'd recommend leaving it and the supporting code out (and there's a lot of >>>> it, vis jvm.cpp as you point out) until the core libs people figure out how >>>> they want to handle it. Maybe file an RFE for the work. >>> >>> If I remove that support, then I won't be able to use the resulting >>> VM with the rest of the macosx-port forest, right? Part of my >>> bring up strategy relies on my being able to use the HSX-23 port >>> bits with the rest of the macosx-port built bits... >> >> True. But it may not be used in it's current form. > > I think it is: > > jdk/src/share/javavm/export/jvm.h:JVM_SetNativeThreadName(JNIEnv *env, jobject jthread, jstring name); > jdk/src/share/native/java/lang/Thread.c: {"setNativeName", "(" STR ")V", (void *)&JVM_SetNativeThreadName}, > jdk/src/share/classes/java/lang/Thread.java: setNativeName(name); > jdk/src/share/classes/java/lang/Thread.java: private native void setNativeName(String name); The important point is that it doesn't expose any new API. It's just a side effect of calling the regular setName. I was a bit dubious about its utility so I googled pthread_setname_np and found out it allows debuggers to report useful names for threads instead of just the thread number. On linux it's even accessible through /proc. Presumably the mac does something similar. It seems like a fairly cool feature. We might want to do it on linux as well and maybe even put proper names on our internal threads (eventually). tom > > Dan > > > >> >> Thanks, >> >> Paul >> >>> >>> >>>> In debug.cpp, I'd make Debugging a product flag if you're going to make Command >>>> a product class. That way you don't need the #ifndef PRODUCT around its uses. >>> >>> Done. >>> >>> >>>> There's a use of "%#p" at line 481 in the Old file (487 in the New one) that should >>>> be replaced by PTR_FORMAT. >>> >>> Fixed. >>> >>> >>>> The comment on line 496 of the New version should >>>> be "!PRODUCT" rather than "PRODUCT". >>> >>> Fixed there and in other places in the file. >>> >>> >>>> You might change pss() to read >>>> >>>> 577 extern "C" void pss() { // print all stacks >>>> 578 if (!Thread::current()) return; >>>> 579 Command c("pss"); >>>> 581 Threads::print(true, PRODUCT_ONLY(false) NOT_PRODUCT(true)); >>>> 585 } >>>> >>>> >>>> It's perhaps a bit neater. >>> >>> Fixed the print() call on line 581. >>> >>> >>>> Re "!Thread::current()", the rule in hotspot is to make >>>> comparisons to null explicit, so you could use instead "Thread::current() != NULL", >>>> because what NULL is varies by platform. >>> >>> Fixed both !current() uses in the file. >>> >>> Dan >>> >>> >>>> >>>> Paul >>>> >>>> On 10/12/11 2:34 PM, roger hoover wrote: >>>>> As I promised Dan earlier this morning....replies embedded: >>>>> >>>>> On Oct 12, 2011, at 9:48 AM, Daniel D. Daugherty wrote: >>>>> >>>>>> David, >>>>>> >>>>>> Thanks for the thorough review (as always). Replies embedded below. >>>>>> >>>>>> >>>>>> On 10/11/11 10:48 PM, David Holmes wrote: >>>>>>> Hi Dan, >>>>>>> >>>>>>> src/cpu/x86/vm/jni_x86.h >>>>>>> >>>>>>> I don't understand why this change would be needed: >>>>>>> >>>>>>> ! #if defined(_LP64)&& !defined(__APPLE__) >>>>>>> typedef long jlong; >>>>>>> #else >>>>>>> typedef long long jlong; >>>>>>> #endif >>>>>>> >>>>>>> this is saying that on "apple" under _LP64 a long is not 64-bits. But the very definition of LP64 is that longs and pointers are 64-bits. ??? >>>>>> $ cat sizes.c >>>>>> #include >>>>>> >>>>>> int main() { >>>>>> printf("Hello world! _LP64="); >>>>>> #ifdef _LP64 >>>>>> printf("%d\n", _LP64); >>>>>> #else >>>>>> printf("undefined\n"); >>>>>> #endif >>>>>> printf("sizeof(long) = %d\n", (int) sizeof(long)); >>>>>> printf("sizeof(long long) = %d\n", (int) sizeof(long long)); >>>>>> } >>>>>> >>>>>> Output on my MacOS 10.6.8 machine: >>>>>> >>>>>> Hello world! _LP64=1 >>>>>> sizeof(long) = 8 >>>>>> sizeof(long long) = 8 >>>>>> >>>>>> Output on my Solaris X86 machine: >>>>>> >>>>>> Hello world! _LP64=undefined >>>>>> sizeof(long) = 4 >>>>>> sizeof(long long) = 8 >>>>>> >>>>>> Output on my Solaris X86 machine when built with '-m64': >>>>>> >>>>>> Hello world! _LP64=1 >>>>>> sizeof(long) = 8 >>>>>> sizeof(long long) = 8 >>>>>> >>>>>> Since __APPLE__ machines have a 8 byte long, I don't understand >>>>>> why the person thought that "long long jlong" was necessary... >>>>>> >>>>>> We need an Apple person to jump in here... >>>>>> >>>>> (answered before, but here it is again): >>>>> This is likely due to the fprintf format usage mess. The hotspot code had assumed that any 64-bit fprintf format could be used with any 64-bit value. Apple compilers give warnings if you print a long with "%lld", and insists upon "%ld" for a clean compile even though both are 64-bit values. Changing the type to long long allows the format to remain unchanged. >>>>> >>>>> The correct way to fix this mess is to insure that the formats exactly match the types used. We couldn't pull this off at apple since we didn't have the capabilities to build under all of the other os platforms to test the changes. >>>>> >>>>>>> src/os//vm/os_.cpp >>>>>>> >>>>>>> + void os::set_native_thread_name(const char *name) { >>>>>>> + // Not yet implemented. >>>>>>> + return; >>>>>>> + } >>>>>>> >>>>>>> I hate seeing "shared" code that is not implemented on 3 out of 4 supported platforms. Though it seems Linux will also support pthread_setname_np as of March 2010 (not sure which kernel or glibc versions needed). If not for the fact this also adds an exported JVM method to set the native thread name, we could otherwise bury this in the platform specific native thread creation code (which might also obviate the need for the new _is_attached logic - see next point). I also wonder what Java code is using this new JVM API? >>>>>> I suspect that this new API is used by other pieces of the MacOS X >>>>>> port project, but I don't know that for sure. Again, we need an >>>>>> Apple person to jump in here. >>>>> The native thread name addition was a huge win, both for us debugging and for our developer customers. The only complaint we had was from other projects whose code attached to Java and (in initial revisions) had their threads renamed. It is exported so that Thread.java can set the native thread name. >>>>> >>>>> I have no explanation for the lack of a return code. I can only surmise that it is an oversight that was not caught by the compiler. >>>>> >>>>> The other pieces are: >>>>> macosx-port/jdk/src/share/native/java/lang/Thread.c: >>>>> {"getThreads", "()[" THD, (void *)&JVM_GetAllThreads}, >>>>> {"dumpThreads", "([" THD ")[[" STE, (void *)&JVM_DumpThreads}, >>>>> --> {"setNativeName", "(" STR ")V", (void *)&JVM_SetNativeThreadName}, >>>>> }; >>>>> -and- >>>>> macosx-port/jdk/src/share/classes/java/lang/Thread.java >>>>> /** >>>>> * Changes the name of this thread to be equal to the argument >>>>> *name. >>>>> *

>>>>> * First thecheckAccess method of this thread is called >>>>> * with no arguments. This may result in throwing a >>>>> *SecurityException. >>>>> * >>>>> * @param name the new name for this thread. >>>>> * @exception SecurityException if the current thread cannot modify this >>>>> * thread. >>>>> * @see #getName >>>>> * @see #checkAccess() >>>>> */ >>>>> public final void setName(String name) { >>>>> checkAccess(); >>>>> this.name = name.toCharArray(); >>>>> --> if (threadStatus != 0) { >>>>> --> setNativeName(name); >>>>> --> } >>>>> } >>>>>> >>>>>>> Also wondering where the "current thread only" restriction came about? >>>>>> If the API is restricted to the "current thread", then we don't have >>>>>> to worry about races and locking. Also, I'm wondering why there is no >>>>>> return code. >>>>>> >>>>>> >>>>>>> src/share/vm/runtime/thread.hpp >>>>>>> >>>>>>> + // Remember whether or not we were attached >>>>>>> + bool _is_attached; >>>>>>> >>>>>>> It took me a while to realize that _is_attached really means "was attached" ie that the Java thread came about due to a native thread attaching to the VM via JNI attachCurrentThread. Could I suggest this is renamed to was_attached? >>>>>> I was taking another look at this. The key user of the new flag is: >>>>>> >>>>>> src/share/vm/prims/jvm.cpp >>>>>> >>>>>> JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject jthread, jstring n >>>>>> ame)) >>>>>> JVMWrapper("JVM_SetNativeThreadName"); >>>>>> ResourceMark rm(THREAD); >>>>>> oop java_thread = JNIHandles::resolve_non_null(jthread); >>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>> // Thread naming only supported for the current thread, doesn't work for >>>>>> // target threads. >>>>>> if (Thread::current() == thr&& !thr->is_attached()) { >>>>>> // we don't set the name of an attached thread to avoid stepping >>>>>> // on other programs >>>>>> const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::reso >>>>>> lve_non_null(name)); >>>>>> os::set_native_thread_name(thread_name); >>>>>> } >>>>>> JVM_END >>>>>> >>>>>> which is coded to not set the name of a thread that has been >>>>>> attached. In the JavaThread(bool) constructor: >>>>>> >>>>>> _is_attached = _is_attaching = is_attaching; >>>>>> >>>>>> we set both flags to the "is_attaching" parameter (default false) >>>>>> so if we're coming down the JNI attach path, that parameter >>>>>> should be true so we set both flags to true. After the thread >>>>>> has been properly attached, we call set_attached() which sets >>>>>> the _is_attaching flag to false. Whew! >>>>>> >>>>>> In the JavaThread(ThreadFunction, size_t) constructor we set >>>>>> both flags to false because we're not attaching... and we >>>>>> didn't come down the JNI attach path. >>>>>> >>>>>> I don't like the "was attached" attribute and I no longer like >>>>>> the "is attaching" and "is attached" attributes either. Sigh. >>>>>> I think both fields need to be cleaned up and renamed. Perhaps >>>>>> something like: >>>>>> >>>>>> is_attaching_via_jni >>>>>> was_attached_via_jni >>>>>> >>>>>> would be more clear? >>>>>> >>>>>> >>>>>>> src/share/vm/utilities/debug.cpp >>>>>>> >>>>>>> Why are we exposing this debug code in a product build? >>>>>> We'll need an Apple person to jump in here... >>>>>> >>>>>> >>>>> It has been an Apple tradition (from long before I joined the Java team in 2004) to include a basic set of debugging routines in product builds. We call them from gdb while debugging problems that don't show up in debug builds, and we've told our developer customers about them. The rest of the Apple port does not depend on these and whether or not to continue Apple's tradition is totally up to Oracle. >>>>> >>>>>>> src/share/vm/prims/jni.cpp >>>>>>> >>>>>>> The USDT2 ifdef changes are truly ugly especially in this file. Is there no way to hide USDT1 vs USDT2 at a lower level so that the top-level probe points are not affected? I know this is flagged for "future work" but history shows such cleans ups rarely if ever happen - and this current code really is pretty awful to look at. >>>>>> Yes, the #ifdef'ing makes the current code awful. I don't think >>>>>> anyone will dispute that observation. >>>>>> >>>>>> The better solution would be for Solaris to migrate to USDT2. >>>>>> I'm discussing that with Keith McGuigan. However, I don't want >>>>>> to take much of his time right now because he is hip deep in >>>>>> another alligator swamp at the moment. >>>>>> >>>>>> The best I can offer at the moment is filing a new bug to track >>>>>> the future work. Yes, I know that clean up type work rarely gets >>>>>> done, but this merge with the MacOS X port project needs to get >>>>>> into HSX-23 as soon as possible. Broken functionality in the >>>>>> other platforms is a stopper, but ugly is not a stopper. >>>>>> >>>>>> Thanks again for the thorough review. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 12/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>>>>> >>>>>>>> 7089790 integrate bsd-port changes >>>>>>>> >>>>>>>> and I'm following up on that work using the following bug: >>>>>>>> >>>>>>>> 7098194 integrate macosx-port changes >>>>>>>> >>>>>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>>>>> include additional changes from the BSD Port in addition the deltas >>>>>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>>>>> this resync is: >>>>>>>> >>>>>>>> changeset: 2729:f1a18ada5853 >>>>>>>> tag: tip >>>>>>>> user: Greg Lewis >>>>>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>>>>> summary: . Finish removing hsearch_r. >>>>>>>> >>>>>>>> The macosx-port/hotspot changeset for this merge is: >>>>>>>> >>>>>>>> changeset: 2756:69de8d34a370 >>>>>>>> tag: tip >>>>>>>> user: swingler at apple.com >>>>>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>>>>> >>>>>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>>>>>> Shaking out the MacOS X Port itself will be done with other changesets >>>>>>>> on an as needed basis. >>>>>>>> >>>>>>>> Just to be clear, the push target for this changeset is the RT_Baseline >>>>>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>>>>> >>>>>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>>>>>> can review these changes in different ways. My primary focus here is >>>>>>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>>>>>> specific changes. Obviously, if you see something I messed up in those >>>>>>>> files, I'd like to know. >>>>>>>> >>>>>>>> Here's the webrev for all the changes in one shot: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>>>>> >>>>>>>> The order of the files in the above webrev is the same as for >>>>>>>> for the subset webrevs below. >>>>>>>> >>>>>>>> Here's the webrevs for the changes in subsets: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>>>>> made for the MacOS X port. There's a couple of files that also contain >>>>>>>> Dtrace related changes, but I decided it was better to include those >>>>>>>> files in this subset. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>>>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>>>>>> which is why the code is #ifdef'ed. I had to change the original >>>>>>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>>>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>>>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>>>>> >>>>>>>> #ifndef USDT2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> #else /* USDT2 */ >>>>>>>> >>>>>>>> #endif /* USDT2 */ >>>>>>>> >>>>>>>> #ifndef USDT2 >>>>>>>> >>>>>>>> >>>>>>>> #endif /* ! USDT2 */ >>>>>>>> >>>>>>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>>>>>> HotSpot style guidelines very consistently, but I decided not to fix >>>>>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>>>>> >>>>>>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>>>>>> Dtrace implementation to the newer version. However, that work will be >>>>>>>> done independently of this bug (7098194). >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>>>>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>>>>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>>>>>> to bless these changes... >>>>>>>> >>>>>>>> Builds done so far: >>>>>>>> >>>>>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>>>>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX >>>>>>>> repo >>>>>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>>>>>>> >>>>>>>> Testing done so far: >>>>>>>> >>>>>>>> - Serviceability stack (25 subsuites): >>>>>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>>>>> logging, mm >>>>>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>>>>> misc_attach, misc_jvmstat, misc_tools >>>>>>>> - Tested configs (8 configs) >>>>>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>>>>> >>>>>>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>>>>>> i.e., did the build "work"? >>>>>>>> >>>>>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>>>>> testing should be finished later today. >>>>>>>> >>>>>>>> Things still to do (in no particular order): >>>>>>>> >>>>>>>> - gather the list of contributors for the changeset comment >>>>>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>>>>> - dtrace testing on Solaris X86 >>>>>>>> - code review >>>>>>>> - start bring up of more formal dev testing on MacOS X >>>>>>>> >>>>>>>> Thanks, in advance, for any review comments. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>> From john.pampuch at oracle.com Wed Oct 12 16:47:22 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Wed, 12 Oct 2011 16:47:22 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: References: <4E947E11.6070004@oracle.com> <4E950B62.8070504@oracle.com> <4E95FF7E.5020503@oracle.com> Message-ID: <4E96270A.2020904@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111012/e45ad6a3/attachment.html From rhoover at apple.com Wed Oct 12 16:49:09 2011 From: rhoover at apple.com (roger hoover) Date: Wed, 12 Oct 2011 17:49:09 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <64CDAA16-3F29-49F1-96B8-3AB842D4F0DC@oracle.com> References: <4E947E11.6070004@oracle.com> <4E951C0E.2060900@oracle.com> <4E95B6C7.6000103@oracle.com> <4E95FF03.8090803@oracle.com> <4E96159F.2090805@oracle.com> <4E961908.6040601@oracle.com> <4E961A72.8000301@oracle.com> <64CDAA16-3F29-49F1-96B8-3AB842D4F0DC@oracle.com> Message-ID: <154B0AFA-1E32-4C55-B970-B40EC55BC6B3@apple.com> On Oct 12, 2011, at 5:39 PM, Tom Rodriguez wrote: > > On Oct 12, 2011, at 3:53 PM, Daniel D. Daugherty wrote: > >>> On 10/12/11 6:33 PM, Daniel D. Daugherty wrote: >>> >>>> >>>> >>>>> If set_native_thread_name() is an implementation of an extension to Thread, >>>>> then I'd recommend leaving it and the supporting code out (and there's a lot of >>>>> it, vis jvm.cpp as you point out) until the core libs people figure out how >>>>> they want to handle it. Maybe file an RFE for the work. >>>> >>>> If I remove that support, then I won't be able to use the resulting >>>> VM with the rest of the macosx-port forest, right? Part of my >>>> bring up strategy relies on my being able to use the HSX-23 port >>>> bits with the rest of the macosx-port built bits... >>> >>> True. But it may not be used in it's current form. >> >> I think it is: >> >> jdk/src/share/javavm/export/jvm.h:JVM_SetNativeThreadName(JNIEnv *env, jobject jthread, jstring name); >> jdk/src/share/native/java/lang/Thread.c: {"setNativeName", "(" STR ")V", (void *)&JVM_SetNativeThreadName}, >> jdk/src/share/classes/java/lang/Thread.java: setNativeName(name); >> jdk/src/share/classes/java/lang/Thread.java: private native void setNativeName(String name); > > The important point is that it doesn't expose any new API. It's just a side effect of calling the regular setName. > > I was a bit dubious about its utility so I googled pthread_setname_np and found out it allows debuggers to report useful names for threads instead of just the thread number. On linux it's even accessible through /proc. Presumably the mac does something similar. It seems like a fairly cool feature. We might want to do it on linux as well and maybe even put proper names on our internal threads (eventually). > > tom It makes a big difference. gdb tells you what the threads are, and we get that info as well in native crash dumps. Here is a snippet from a crash dump on our jdk6 implementation. This also helps JNI developers because they can understand in which thread their code is crashing: Thread 14: Java: VM Thread 0 libSystem.B.dylib 0x00007fff802abd7a mach_msg_trap + 10 1 libSystem.B.dylib 0x00007fff802ac3ed mach_msg + 59 2 libclient64.dylib 0x000000010100d8f5 jio_snprintf + 37807 3 libclient64.dylib 0x000000010102c4aa jio_vsnprintf + 26334 4 libclient64.dylib 0x000000010100d25d jio_snprintf + 36119 5 libclient64.dylib 0x000000010100d103 jio_snprintf + 35773 6 libclient64.dylib 0x00000001010a3ef7 JVM_Lseek + 188645 7 libclient64.dylib 0x00000001010a3c47 JVM_Lseek + 187957 8 libclient64.dylib 0x000000010100d1c4 jio_snprintf + 35966 9 libSystem.B.dylib 0x00007fff802e4fd6 _pthread_start + 331 10 libSystem.B.dylib 0x00007fff802e4e89 thread_start + 13 Thread 15: Java: Reference Handler 0 libSystem.B.dylib 0x00007fff802abd7a mach_msg_trap + 10 1 libSystem.B.dylib 0x00007fff802ac3ed mach_msg + 59 2 libclient64.dylib 0x000000010100d863 jio_snprintf + 37661 3 libclient64.dylib 0x000000010100d723 jio_snprintf + 37341 4 libclient64.dylib 0x00000001010b24ff JVM_MonitorWait + 3999 5 libclient64.dylib 0x00000001010b198c JVM_MonitorWait + 1068 6 libclient64.dylib 0x00000001010b15fa JVM_MonitorWait + 154 7 libjvmlinkage.dylib 0x0000000100093b9b JVM_MonitorWait + 59 8 ??? 0x0000000104011d6e 0 + 4362149230 9 ??? 0x000000010400685a 0 + 4362102874 10 ??? 0x000000010400685a 0 + 4362102874 11 ??? 0x0000000104001438 0 + 4362081336 12 libclient64.dylib 0x00000001010a50ba JVM_Lseek + 193192 13 libclient64.dylib 0x00000001010b1148 JVM_StartThread + 2565 14 libclient64.dylib 0x00000001010b103e JVM_StartThread + 2299 15 libclient64.dylib 0x00000001010b0fde JVM_StartThread + 2203 16 libclient64.dylib 0x00000001010b0e80 JVM_StartThread + 1853 17 libclient64.dylib 0x00000001010b0c95 JVM_StartThread + 1362 18 libclient64.dylib 0x000000010100d1c4 jio_snprintf + 35966 19 libSystem.B.dylib 0x00007fff802e4fd6 _pthread_start + 331 20 libSystem.B.dylib 0x00007fff802e4e89 thread_start + 13 Thread 16: Java: Finalizer 0 libSystem.B.dylib 0x00007fff802abd7a mach_msg_trap + 10 1 libSystem.B.dylib 0x00007fff802ac3ed mach_msg + 59 2 libclient64.dylib 0x000000010100d863 jio_snprintf + 37661 3 libclient64.dylib 0x000000010100d723 jio_snprintf + 37341 4 libclient64.dylib 0x00000001010b24ff JVM_MonitorWait + 3999 5 libclient64.dylib 0x00000001010b198c JVM_MonitorWait + 1068 6 libclient64.dylib 0x00000001010b15fa JVM_MonitorWait + 154 7 libjvmlinkage.dylib 0x0000000100093b9b JVM_MonitorWait + 59 8 ??? 0x0000000104011d6e 0 + 4362149230 9 ??? 0x000000010400685a 0 + 4362102874 10 ??? 0x00000001040069b3 0 + 4362103219 11 ??? 0x00000001040069b3 0 + 4362103219 12 ??? 0x0000000104001438 0 + 4362081336 13 libclient64.dylib 0x00000001010a50ba JVM_Lseek + 193192 14 libclient64.dylib 0x00000001010b1148 JVM_StartThread + 2565 15 libclient64.dylib 0x00000001010b103e JVM_StartThread + 2299 16 libclient64.dylib 0x00000001010b0fde JVM_StartThread + 2203 17 libclient64.dylib 0x00000001010b0e80 JVM_StartThread + 1853 18 libclient64.dylib 0x00000001010b0c95 JVM_StartThread + 1362 19 libclient64.dylib 0x000000010100d1c4 jio_snprintf + 35966 20 libSystem.B.dylib 0x00007fff802e4fd6 _pthread_start + 331 21 libSystem.B.dylib 0x00007fff802e4e89 thread_start + 13 Thread 17: Dispatch queue: com.apple.libdispatch-manager From rhoover at apple.com Wed Oct 12 17:54:02 2011 From: rhoover at apple.com (roger hoover) Date: Wed, 12 Oct 2011 18:54:02 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E96270A.2020904@oracle.com> References: <4E947E11.6070004@oracle.com> <4E950B62.8070504@oracle.com> <4E95FF7E.5020503@oracle.com> <4E96270A.2020904@oracle.com> Message-ID: <14BAB60A-4DC7-4D82-90F4-504B24078A75@apple.com> I asked the apple hotspot team members who worked on jdk6 if they wanted to be credited. Please add: Victor Hernandez Pratik Solanki On Oct 12, 2011, at 5:47 PM, John Pampuch wrote: > For those that are interested, it is important to get a record of the significant contributors as it will count on their behalf to get commit privileges into the OpenJDK. > > -John > > On 10/12/11 2:06 PM, roger hoover wrote: >> >> On Oct 12, 2011, at 2:58 PM, Daniel D. Daugherty wrote: >> >>> On 10/11/11 9:37 PM, Daniel D. Daugherty wrote: >>>> On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: >>>>> Things still to do (in no particular order): >>>>> >>>>> - gather the list of contributors for the changeset comment >>>> Here's the list of folks that Tom used for the BSD-port push: >>>> >>>> Kurt Miller >>>> Greg Lewis >>>> Jung-uk Kim >>>> Christos Zoulas >>>> Landon Fuller >>>> The FreeBSD Foundation >>>> Michael Franz >>>> Roger Hoover >>>> Alexander Strange >>>> >>>> Since I'm syncing with bsd-port/hotspot in addition to >>>> merging in macosx-port/hotspot, should I use the same >>>> list of folks? >>> I still need to nail down the contributor list and no one >>> replied to this part of the e-mail thread... >>> >>> Dan >>> >> The actual edits to the mac port were mostly done by Roger Hoover and Alexander Strange, but the changes themselves come from a whole host of people who have built the mac port at Apple over the last decade++. Perhaps you should attribute Apple, Inc. >> >> roger >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111012/3673995a/attachment.html From daniel.daugherty at oracle.com Wed Oct 12 17:55:02 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 18:55:02 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <84E408E0-AC1D-4AF3-9515-8250AA1A60DD@oracle.com> References: <4E947E11.6070004@oracle.com> <4E950B62.8070504@oracle.com> <4E95FF7E.5020503@oracle.com> <84E408E0-AC1D-4AF3-9515-8250AA1A60DD@oracle.com> Message-ID: <4E9636E6.1030808@oracle.com> On 10/12/11 3:04 PM, Tom Rodriguez wrote: > On Oct 12, 2011, at 1:58 PM, Daniel D. Daugherty wrote: > >> On 10/11/11 9:37 PM, Daniel D. Daugherty wrote: >>> On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>> Here's the list of folks that Tom used for the BSD-port push: >>> >>> Kurt Miller >>> Greg Lewis >>> Jung-uk Kim >>> Christos Zoulas >>> Landon Fuller >>> The FreeBSD Foundation >>> Michael Franz >>> Roger Hoover >>> Alexander Strange >>> >>> Since I'm syncing with bsd-port/hotspot in addition to >>> merging in macosx-port/hotspot, should I use the same >>> list of folks? >> I still need to nail down the contributor list and no one >> replied to this part of the e-mail thread... > I would assume Roger and Alexander of course and then only contributors to bsd-port since around the time of the sync, so I think it would this: > > Kurt Miller > Greg Lewis > Christos Zoulas > Roger Hoover > Alexander Strange Tom, I think you and I are on a similar page. I have the same three folks pushing changesets to bsd-port/hotspot after your initial snapshot work: Christos Zoulas Greg Lewis Kurt Miller and I have the following for Apple: Alexander Strange Mike Swingler Roger Hoover so that's my list unless someone else sends me corrections... Dan From daniel.daugherty at oracle.com Wed Oct 12 17:56:22 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 18:56:22 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E947E11.6070004@oracle.com> References: <4E947E11.6070004@oracle.com> Message-ID: <4E963736.6010202@oracle.com> Greetings, I've closed out Code Review Round 0 and I'm posting new webrevs for Code Review Round 1: Here's the webrev for just the deltas between Code Review Round 0 and Code Review Round 1: http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only Here's the webrev for all the changes in one shot: http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ And here are the same subset webrevs: http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ Here's my current commit message: > 7098194: integrate macosx-port changes > Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. > Reviewed-by: kvn, dholmes, never, phh > Contributed-by: Christos Zoulas , Greg Lewis > , Kurt Miller , > Alexander Strange , Mike Swingler > , Roger Hoover Thanks, in advance, for any final feedback for this changeset. Dan > Greetings, > > Tom R shepherded the the BSD Port into HotSpot Express 23 using: > > 7089790 integrate bsd-port changes > > and I'm following up on that work using the following bug: > > 7098194 integrate macosx-port changes > > The synopsis is a bit off. In reality, the 7098194changeset will > include additional changes from the BSD Port in addition the deltas > made by the MacOS X Port. The bsd-port/hotspot tip changeset for > this resync is: > > changeset: 2729:f1a18ada5853 > tag: tip > user: Greg Lewis > date: Wed Sep 21 22:29:10 2011 -0700 > summary: . Finish removing hsearch_r. > > The macosx-port/hotspot changeset for this merge is: > > changeset: 2756:69de8d34a370 > tag: tip > user: swingler at apple.com > date: Thu Sep 29 18:10:16 2011 -0700 > summary: Adding JAVA_LIBRARY_PATH for bundled app launching > (avoids stomping DYLD_LIBRARY_PATH) > > The focus of 7098194 is to get the MacOS X port into HSX-23 without > regressing the non-MacOS X platforms. In other words, we're trying > to get HSX-23 caught up with the BSD Port and MacOS X Port projects. > Shaking out the MacOS X Port itself will be done with other changesets > on an as needed basis. > > Just to be clear, the push target for this changeset is the RT_Baseline > sub-repo of HotSpot Express (currently HSX-23): > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot > > Like what Tom did for 7089790, I'm posting multiple webrevs so folks > can review these changes in different ways. My primary focus here is > the common or shared code so I'm less worried about the BSD or MacOS X > specific changes. Obviously, if you see something I messed up in those > files, I'd like to know. > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ > > The order of the files in the above webrev is the same as for > for the subset webrevs below. > > Here's the webrevs for the changes in subsets: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ > > > The above webrev has the changes to the bsd-port/hotspot repo made > after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ > > > The above webrev has the non-Dtrace and non-infrastructure changes > made for the MacOS X port. There's a couple of files that also > contain > Dtrace related changes, but I decided it was better to include those > files in this subset. > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ > > > The above webrev has almost all of the changes to enable Dtrace on > MacOS X (a couple of files are in the macosx-other-code subset). > On MacOS X, a newer version of Dtrace is implemented than on Solaris > which is why the code is #ifdef'ed. I had to change the original > #ifdef'ing because the original implementation had put some > non-Dtrace > code into #ifdef USDT1 ... #endif blocks so the code didn't build on > non-Solaris platforms. In order to be more clean with #ifdef'ing, I > redid all MacOS X Dtrace #ifdef'ing in the following forms: > > #ifndef USDT2 > > > > #else /* USDT2 */ > > #endif /* USDT2 */ > > #ifndef USDT2 > > > #endif /* ! USDT2 */ > > Yes, I realize that the MacOS X Dtrace implementation does not follow > HotSpot style guidelines very consistently, but I decided not to fix > that so I could diff against the macosx-port/hotspot more reliably. > > I have to consult with Keith McGuigan about how to migrate the > Solaris > Dtrace implementation to the newer version. However, that work > will be > done independently of this bug (7098194). > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ > > > The above webrev has all the infrastructure (e.g., Makefile) related > changes. Many/most folks aren't interested in Makefile stuff so I've > put these changes in their own subset. Of course, I need Kelly O'Hair > to bless these changes... > > Builds done so far: > > - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} > - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} > - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new > HSX repo > - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX > repo > > Testing done so far: > > - Serviceability stack (25 subsuites): > VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, > logging, mm > SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, > mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, > misc_attach, misc_jvmstat, misc_tools > - Tested configs (8 configs) > {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} > > - MacOS X builds have only had minimal 'java -version' type testing, > i.e., did the build "work"? > > No regressions have been seen in the Solaris X86 testing and WinXP > testing should be finished later today. > > Things still to do (in no particular order): > > - gather the list of contributors for the changeset comment > - JPRT test jobs when the JPRT-hotspotwest queue settles down > - dtrace testing on Solaris X86 > - code review > - start bring up of more formal dev testing on MacOS X > > Thanks, in advance, for any review comments. > > Dan > > From daniel.daugherty at oracle.com Wed Oct 12 18:07:03 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2011 19:07:03 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <14BAB60A-4DC7-4D82-90F4-504B24078A75@apple.com> References: <4E947E11.6070004@oracle.com> <4E950B62.8070504@oracle.com> <4E95FF7E.5020503@oracle.com> <4E96270A.2020904@oracle.com> <14BAB60A-4DC7-4D82-90F4-504B24078A75@apple.com> Message-ID: <4E9639B7.3030407@oracle.com> Done! Dan On 10/12/11 6:54 PM, roger hoover wrote: > I asked the apple hotspot team members who worked on jdk6 if they > wanted to be credited. Please add: > > Victor Hernandez > > Pratik Solanki > > > On Oct 12, 2011, at 5:47 PM, John Pampuch wrote: > >> For those that are interested, it is important to get a record of the >> significant contributors as it will count on their behalf to get >> commit privileges into the OpenJDK. >> >> -John >> >> On 10/12/11 2:06 PM, roger hoover wrote: >>> On Oct 12, 2011, at 2:58 PM, Daniel D. Daugherty wrote: >>> >>>> On 10/11/11 9:37 PM, Daniel D. Daugherty wrote: >>>>> On 10/11/11 11:34 AM, Daniel D. Daugherty wrote: >>>>>> Things still to do (in no particular order): >>>>>> >>>>>> - gather the list of contributors for the changeset comment >>>>> Here's the list of folks that Tom used for the BSD-port push: >>>>> >>>>> Kurt Miller >>>>> Greg Lewis >>>>> Jung-uk Kim >>>>> Christos Zoulas >>>>> Landon Fuller >>>>> The FreeBSD Foundation >>>>> Michael Franz >>>>> Roger Hoover >>>>> Alexander Strange >>>>> >>>>> Since I'm syncing with bsd-port/hotspot in addition to >>>>> merging in macosx-port/hotspot, should I use the same >>>>> list of folks? >>>> I still need to nail down the contributor list and no one >>>> replied to this part of the e-mail thread... >>>> >>>> Dan >>>> >>> The actual edits to the mac port were mostly done by Roger Hoover and Alexander Strange, but the changes themselves come from a whole host of people who have built the mac port at Apple over the last decade++. Perhaps you should attribute Apple, Inc. >>> >>> roger >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111012/2eff414b/attachment-0001.html From david.holmes at oracle.com Wed Oct 12 18:59:48 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Oct 2011 11:59:48 +1000 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E963736.6010202@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> Message-ID: <4E964614.9060406@oracle.com> Okay, I won't respond to all the past emails concerning my first round comments, but will start afresh here utilising the additional information that has been provided. But first a new comment: src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp (and probably elsewhere) fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, rslt)); It is far more informative to provide the error string "strerror(rslt)" than the decimal value of the error code. (We're probably guilty of this in many places but lets not propagate bad habits.) --- src/share/vm/prims/jni.cpp + thread.* ! thread->set_done_attaching_via_jni(); I think the naming has gotten overly verbose here. The only way to attach is by definition via JNI. I don't think there was anything wrong with the existing _is_attaching logic (yes I added it! ;-) ) and my only complaint was that the new _is_attached should really be _was_attached. Perhaps a better/simpler/cleaer approach here would have been to have a field: can_set_native_thread_name, and only set it to true in the non-attaching case. Another cleanup RFE perhaps. --- src/share/vm/utilities/debug.cpp Normally if we propose to move something into a product build there is a discussion about what we are moving, why, and what the impact is on build size and runtime performance. I don't see any of that here. :( --- - set_native_thread_name: Ok so I have to go back to earlier emails here. Makes sense that Thread.setName is augmented to call JVM_SetNativeThreadName. However I don't like the semantics of this particular addition. setName has no usage restrictions on it, but set_native_thread_name is a no-op unless called by the current thread. By restricting it to the current thread it simplifies synchronization logic, but it seems a somewhat arbitrary restriction in terms of the functionality, given the more general nature of the setName API. I guess this is Yet Another RFE: set_native_thread_name should not be restricted to only the current thread. BTW: are the JDK changes associated with this also being pushed at some stage? If so are the hotspot changes being pushed first? Cheers, David On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: > Greetings, > > I've closed out Code Review Round 0 and I'm posting new webrevs > for Code Review Round 1: > > Here's the webrev for just the deltas between Code Review Round 0 > and Code Review Round 1: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only > > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ > > And here are the same subset webrevs: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ > > > > Here's my current commit message: > >> 7098194: integrate macosx-port changes >> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >> Reviewed-by: kvn, dholmes, never, phh >> Contributed-by: Christos Zoulas , Greg Lewis >> , Kurt Miller , >> Alexander Strange , Mike Swingler >> , Roger Hoover > > Thanks, in advance, for any final feedback for this changeset. > > Dan > > >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the Solaris >> Dtrace implementation to the newer version. However, that work will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >> HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >> repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> >> From daniel.daugherty at oracle.com Thu Oct 13 07:07:08 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Oct 2011 08:07:08 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E964614.9060406@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> Message-ID: <4E96F08C.9060600@oracle.com> On 10/12/11 7:59 PM, David Holmes wrote: > Okay, I won't respond to all the past emails concerning my first round > comments, but will start afresh here utilising the additional > information that has been provided. Thanks. I appreciate that since this review has taken more time than anyone predicted. > But first a new comment: > > src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp (and probably elsewhere) > > fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, > rslt)); > > It is far more informative to provide the error string > "strerror(rslt)" than the decimal value of the error code. (We're > probably guilty of this in many places but lets not propagate bad > habits.) Changing the format string from "%d" to INT32_FORMAT was done because Paul pointed out that HotSpot isn't supposed to use format specifiers like "%d" directly. That is different than changing the output from a decimal to string which I think is beyond the scope of this changeset. It does raise interesting questions about error diagnostics and, if memory serves me correctly, there is an open bug for improving error diagnostics... And, yes, I'll have to check the equivalent Linux code to see if the format strings need to be fixed there also. I suspect they do, but I already have plans (and a script) to make a pass at sync'ing BSD improvements back to Linux. > src/share/vm/prims/jni.cpp + thread.* > > ! thread->set_done_attaching_via_jni(); > > I think the naming has gotten overly verbose here. The only way to > attach is by definition via JNI. I don't think there was anything > wrong with the existing _is_attaching logic (yes I added it! ;-) ) and > my only complaint was that the new _is_attached should really be > _was_attached. Perhaps a better/simpler/cleaer approach here would > have been to have a field: can_set_native_thread_name, and only set it > to true in the non-attaching case. Another cleanup RFE perhaps. On several occasions I have fielded questions about the difference between "attach on demand" and "JNI attach" so there is definitely confusion out there. I think the renaming adds clarity and I had thought you would like the reduction in number of fields. I also think the new JNIAttachStates is cleaner and more clear. I think that adding a field called can_set_native_thread_name is going to cause some confusion with JVM/TI capabilities since all of those are named in the style of can_do_this and can_do_that. > src/share/vm/utilities/debug.cpp > > Normally if we propose to move something into a product build there is > a discussion about what we are moving, why, and what the impact is on > build size and runtime performance. I don't see any of that here. :( I've only recently joined the MacOS Port project so I have no idea what was discussed before I arrived. I have difficulty imagining that the changes to debug.cpp will add much to the size and I don't think they will affect runtime performance unless they are used. Compared to what I just added via Full Debug Symbols, this has got to be a drop in the bucket :-) > - set_native_thread_name: > > Ok so I have to go back to earlier emails here. Makes sense that > Thread.setName is augmented to call JVM_SetNativeThreadName. However I > don't like the semantics of this particular addition. setName has no > usage restrictions on it, but set_native_thread_name is a no-op unless > called by the current thread. By restricting it to the current thread > it simplifies synchronization logic, but it seems a somewhat arbitrary > restriction in terms of the functionality, given the more general > nature of the setName API. I guess this is Yet Another RFE: > set_native_thread_name should not be restricted to only the current > thread. We definitely need to get some clarity about the addition of JVM_SetNativeThreadName(). I'm not fond of APIs without return values so that's one thing to log in the new bug. The "must be current thread" semantic should also be hashed out/clarified. Like any API between the JDK and HotSpot, changing it will be a pain and require coordination. > BTW: are the JDK changes associated with this also being pushed at > some stage? Yes, but the exact process has not been finalized. Since there are changes being made/coordinated by multiple teams, I'm not sure which JDK8 sub-repos will be used. > If so are the hotspot changes being pushed first? I'm planning to push this changeset to RT_Baseline today. I don't know if there is an HSX-B23-B02 snapshot this week, but I think I've missed the window by one day. Normally changes have to hit RT_Baseline by Wednesday nightly cut-off to be included in the RT_Baseline -> Main_Baseline push for a given week... However, I don't know your plans for gatekeeping this week so maybe you aren't planning to push until Friday morning. Strangely enough, because I'm pushing to HSX-23 via RT_Baseline, my repo coordination life is much easier. HSX-23 will get to JDK7u via a bulk update so I don't have to juggle too much... Dan > > Cheers, > David > > On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I've closed out Code Review Round 0 and I'm posting new webrevs >> for Code Review Round 1: >> >> Here's the webrev for just the deltas between Code Review Round 0 >> and Code Review Round 1: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >> >> >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >> >> And here are the same subset webrevs: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >> >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >> >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >> >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >> >> >> >> >> Here's my current commit message: >> >>> 7098194: integrate macosx-port changes >>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>> Reviewed-by: kvn, dholmes, never, phh >>> Contributed-by: Christos Zoulas , Greg Lewis >>> , Kurt Miller , >>> Alexander Strange , Mike Swingler >>> , Roger Hoover >> >> Thanks, in advance, for any final feedback for this changeset. >> >> Dan >> >> >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also contain >>> Dtrace related changes, but I decided it was better to include those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>> HotSpot style guidelines very consistently, but I decided not to fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the Solaris >>> Dtrace implementation to the newer version. However, that work will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> >>> >>> The above webrev has all the infrastructure (e.g., Makefile) related >>> changes. Many/most folks aren't interested in Makefile stuff so I've >>> put these changes in their own subset. Of course, I need Kelly O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>> jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>> HSX repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >>> repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> >>> From daniel.daugherty at oracle.com Thu Oct 13 07:53:04 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Oct 2011 08:53:04 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E963736.6010202@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> Message-ID: <4E96FB50.6000001@oracle.com> Paul, Tom, and Vladimir, I made changes based on your code reviews. When you get the chance, can you please verify that I got it right: http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only David H. has already re-reviewed and I think Paul said something about going on vacation... Dan On 10/12/11 6:56 PM, Daniel D. Daugherty wrote: > Greetings, > > I've closed out Code Review Round 0 and I'm posting new webrevs > for Code Review Round 1: > > Here's the webrev for just the deltas between Code Review Round 0 > and Code Review Round 1: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only > > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ > > And here are the same subset webrevs: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ > > > > Here's my current commit message: > >> 7098194: integrate macosx-port changes >> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >> Reviewed-by: kvn, dholmes, never, phh >> Contributed-by: Christos Zoulas , Greg Lewis >> , Kurt Miller , >> Alexander Strange , Mike Swingler >> , Roger Hoover > > Thanks, in advance, for any final feedback for this changeset. > > Dan > > >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also >> contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some >> non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not >> follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the >> Solaris >> Dtrace implementation to the newer version. However, that work >> will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly >> O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >> HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >> repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> >> > From tom.rodriguez at oracle.com Thu Oct 13 09:01:05 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 13 Oct 2011 09:01:05 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E96FB50.6000001@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E96FB50.6000001@oracle.com> Message-ID: <7773AE2D-E7AC-44D9-9B7C-EAA8D794557F@oracle.com> Looks good. tom On Oct 13, 2011, at 7:53 AM, Daniel D. Daugherty wrote: > Paul, Tom, and Vladimir, > > I made changes based on your code reviews. When you get the chance, > can you please verify that I got it right: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only > > David H. has already re-reviewed and I think Paul said something about > going on vacation... > > Dan > > > On 10/12/11 6:56 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I've closed out Code Review Round 0 and I'm posting new webrevs >> for Code Review Round 1: >> >> Here's the webrev for just the deltas between Code Review Round 0 >> and Code Review Round 1: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >> >> And here are the same subset webrevs: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >> >> >> Here's my current commit message: >> >>> 7098194: integrate macosx-port changes >>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>> Reviewed-by: kvn, dholmes, never, phh >>> Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller , Alexander Strange , Mike Swingler , Roger Hoover >> >> Thanks, in advance, for any final feedback for this changeset. >> >> Dan >> >> >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also contain >>> Dtrace related changes, but I decided it was better to include those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>> HotSpot style guidelines very consistently, but I decided not to fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the Solaris >>> Dtrace implementation to the newer version. However, that work will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> The above webrev has all the infrastructure (e.g., Makefile) related >>> changes. Many/most folks aren't interested in Makefile stuff so I've >>> put these changes in their own subset. Of course, I need Kelly O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> >>> >> From daniel.daugherty at oracle.com Thu Oct 13 09:02:04 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Oct 2011 10:02:04 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <7773AE2D-E7AC-44D9-9B7C-EAA8D794557F@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E96FB50.6000001@oracle.com> <7773AE2D-E7AC-44D9-9B7C-EAA8D794557F@oracle.com> Message-ID: <4E970B7C.1040708@oracle.com> Thanks Tom! Dan On 10/13/11 10:01 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 13, 2011, at 7:53 AM, Daniel D. Daugherty wrote: > >> Paul, Tom, and Vladimir, >> >> I made changes based on your code reviews. When you get the chance, >> can you please verify that I got it right: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >> >> David H. has already re-reviewed and I think Paul said something about >> going on vacation... >> >> Dan >> >> >> On 10/12/11 6:56 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I've closed out Code Review Round 0 and I'm posting new webrevs >>> for Code Review Round 1: >>> >>> Here's the webrev for just the deltas between Code Review Round 0 >>> and Code Review Round 1: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>> >>> And here are the same subset webrevs: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>> >>> >>> Here's my current commit message: >>> >>>> 7098194: integrate macosx-port changes >>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>> Reviewed-by: kvn, dholmes, never, phh >>>> Contributed-by: Christos Zoulas, Greg Lewis, Kurt Miller, Alexander Strange, Mike Swingler, Roger Hoover >>> Thanks, in advance, for any final feedback for this changeset. >>> >>> Dan >>> >>> >>>> Greetings, >>>> >>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>> >>>> 7089790 integrate bsd-port changes >>>> >>>> and I'm following up on that work using the following bug: >>>> >>>> 7098194 integrate macosx-port changes >>>> >>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>> include additional changes from the BSD Port in addition the deltas >>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>> this resync is: >>>> >>>> changeset: 2729:f1a18ada5853 >>>> tag: tip >>>> user: Greg Lewis >>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>> summary: . Finish removing hsearch_r. >>>> >>>> The macosx-port/hotspot changeset for this merge is: >>>> >>>> changeset: 2756:69de8d34a370 >>>> tag: tip >>>> user: swingler at apple.com >>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>> (avoids stomping DYLD_LIBRARY_PATH) >>>> >>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>> regressing the non-MacOS X platforms. In other words, we're trying >>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>> Shaking out the MacOS X Port itself will be done with other changesets >>>> on an as needed basis. >>>> >>>> Just to be clear, the push target for this changeset is the RT_Baseline >>>> sub-repo of HotSpot Express (currently HSX-23): >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>> >>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>> can review these changes in different ways. My primary focus here is >>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>> specific changes. Obviously, if you see something I messed up in those >>>> files, I'd like to know. >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>> >>>> The order of the files in the above webrev is the same as for >>>> for the subset webrevs below. >>>> >>>> Here's the webrevs for the changes in subsets: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>> >>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>> >>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>> made for the MacOS X port. There's a couple of files that also contain >>>> Dtrace related changes, but I decided it was better to include those >>>> files in this subset. >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>> >>>> The above webrev has almost all of the changes to enable Dtrace on >>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>> which is why the code is #ifdef'ed. I had to change the original >>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> >>>> #else /* USDT2 */ >>>> >>>> #endif /* USDT2 */ >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> #endif /* ! USDT2 */ >>>> >>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>> HotSpot style guidelines very consistently, but I decided not to fix >>>> that so I could diff against the macosx-port/hotspot more reliably. >>>> >>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>> Dtrace implementation to the newer version. However, that work will be >>>> done independently of this bug (7098194). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>> >>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>> to bless these changes... >>>> >>>> Builds done so far: >>>> >>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo >>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>>> >>>> Testing done so far: >>>> >>>> - Serviceability stack (25 subsuites): >>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>> logging, mm >>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>> misc_attach, misc_jvmstat, misc_tools >>>> - Tested configs (8 configs) >>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>> >>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>> i.e., did the build "work"? >>>> >>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>> testing should be finished later today. >>>> >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>> - dtrace testing on Solaris X86 >>>> - code review >>>> - start bring up of more formal dev testing on MacOS X >>>> >>>> Thanks, in advance, for any review comments. >>>> >>>> Dan >>>> >>>> From vladimir.kozlov at oracle.com Thu Oct 13 09:28:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Oct 2011 09:28:21 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E96FB50.6000001@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E96FB50.6000001@oracle.com> Message-ID: <4E9711A5.40906@oracle.com> Good. Vladimir On 10/13/11 7:53 AM, Daniel D. Daugherty wrote: > Paul, Tom, and Vladimir, > > I made changes based on your code reviews. When you get the chance, > can you please verify that I got it right: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only > > David H. has already re-reviewed and I think Paul said something about > going on vacation... > > Dan > > > On 10/12/11 6:56 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I've closed out Code Review Round 0 and I'm posting new webrevs >> for Code Review Round 1: >> >> Here's the webrev for just the deltas between Code Review Round 0 >> and Code Review Round 1: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >> >> And here are the same subset webrevs: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >> >> >> Here's my current commit message: >> >>> 7098194: integrate macosx-port changes >>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>> Reviewed-by: kvn, dholmes, never, phh >>> Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller >>> , Alexander Strange , Mike Swingler , Roger >>> Hoover >> >> Thanks, in advance, for any final feedback for this changeset. >> >> Dan >> >> >>> Greetings, >>> >>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>> >>> 7089790 integrate bsd-port changes >>> >>> and I'm following up on that work using the following bug: >>> >>> 7098194 integrate macosx-port changes >>> >>> The synopsis is a bit off. In reality, the 7098194changeset will >>> include additional changes from the BSD Port in addition the deltas >>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>> this resync is: >>> >>> changeset: 2729:f1a18ada5853 >>> tag: tip >>> user: Greg Lewis >>> date: Wed Sep 21 22:29:10 2011 -0700 >>> summary: . Finish removing hsearch_r. >>> >>> The macosx-port/hotspot changeset for this merge is: >>> >>> changeset: 2756:69de8d34a370 >>> tag: tip >>> user: swingler at apple.com >>> date: Thu Sep 29 18:10:16 2011 -0700 >>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>> (avoids stomping DYLD_LIBRARY_PATH) >>> >>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>> regressing the non-MacOS X platforms. In other words, we're trying >>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>> Shaking out the MacOS X Port itself will be done with other changesets >>> on an as needed basis. >>> >>> Just to be clear, the push target for this changeset is the RT_Baseline >>> sub-repo of HotSpot Express (currently HSX-23): >>> >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>> >>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>> can review these changes in different ways. My primary focus here is >>> the common or shared code so I'm less worried about the BSD or MacOS X >>> specific changes. Obviously, if you see something I messed up in those >>> files, I'd like to know. >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>> >>> The order of the files in the above webrev is the same as for >>> for the subset webrevs below. >>> >>> Here's the webrevs for the changes in subsets: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>> >>> The above webrev has the changes to the bsd-port/hotspot repo made >>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>> >>> The above webrev has the non-Dtrace and non-infrastructure changes >>> made for the MacOS X port. There's a couple of files that also contain >>> Dtrace related changes, but I decided it was better to include those >>> files in this subset. >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>> >>> The above webrev has almost all of the changes to enable Dtrace on >>> MacOS X (a couple of files are in the macosx-other-code subset). >>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>> which is why the code is #ifdef'ed. I had to change the original >>> #ifdef'ing because the original implementation had put some non-Dtrace >>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>> >>> #ifndef USDT2 >>> >>> >>> >>> #else /* USDT2 */ >>> >>> #endif /* USDT2 */ >>> >>> #ifndef USDT2 >>> >>> >>> #endif /* ! USDT2 */ >>> >>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>> HotSpot style guidelines very consistently, but I decided not to fix >>> that so I could diff against the macosx-port/hotspot more reliably. >>> >>> I have to consult with Keith McGuigan about how to migrate the Solaris >>> Dtrace implementation to the newer version. However, that work will be >>> done independently of this bug (7098194). >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>> >>> The above webrev has all the infrastructure (e.g., Makefile) related >>> changes. Many/most folks aren't interested in Makefile stuff so I've >>> put these changes in their own subset. Of course, I need Kelly O'Hair >>> to bless these changes... >>> >>> Builds done so far: >>> >>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new HSX repo >>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX repo >>> >>> Testing done so far: >>> >>> - Serviceability stack (25 subsuites): >>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>> logging, mm >>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>> misc_attach, misc_jvmstat, misc_tools >>> - Tested configs (8 configs) >>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>> >>> - MacOS X builds have only had minimal 'java -version' type testing, >>> i.e., did the build "work"? >>> >>> No regressions have been seen in the Solaris X86 testing and WinXP >>> testing should be finished later today. >>> >>> Things still to do (in no particular order): >>> >>> - gather the list of contributors for the changeset comment >>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>> - dtrace testing on Solaris X86 >>> - code review >>> - start bring up of more formal dev testing on MacOS X >>> >>> Thanks, in advance, for any review comments. >>> >>> Dan >>> >>> >> From daniel.daugherty at oracle.com Thu Oct 13 09:30:34 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Oct 2011 10:30:34 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E9711A5.40906@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E96FB50.6000001@oracle.com> <4E9711A5.40906@oracle.com> Message-ID: <4E97122A.2020109@oracle.com> Thanks Vladimir! Dan On 10/13/11 10:28 AM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/13/11 7:53 AM, Daniel D. Daugherty wrote: >> Paul, Tom, and Vladimir, >> >> I made changes based on your code reviews. When you get the chance, >> can you please verify that I got it right: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >> >> >> David H. has already re-reviewed and I think Paul said something about >> going on vacation... >> >> Dan >> >> >> On 10/12/11 6:56 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I've closed out Code Review Round 0 and I'm posting new webrevs >>> for Code Review Round 1: >>> >>> Here's the webrev for just the deltas between Code Review Round 0 >>> and Code Review Round 1: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>> >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>> >>> And here are the same subset webrevs: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>> >>> >>> >>> Here's my current commit message: >>> >>>> 7098194: integrate macosx-port changes >>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>> Reviewed-by: kvn, dholmes, never, phh >>>> Contributed-by: Christos Zoulas , Greg Lewis >>>> , Kurt Miller >>>> , Alexander Strange >>>> , Mike Swingler , Roger >>>> Hoover >>> >>> Thanks, in advance, for any final feedback for this changeset. >>> >>> Dan >>> >>> >>>> Greetings, >>>> >>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>> >>>> 7089790 integrate bsd-port changes >>>> >>>> and I'm following up on that work using the following bug: >>>> >>>> 7098194 integrate macosx-port changes >>>> >>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>> include additional changes from the BSD Port in addition the deltas >>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>> this resync is: >>>> >>>> changeset: 2729:f1a18ada5853 >>>> tag: tip >>>> user: Greg Lewis >>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>> summary: . Finish removing hsearch_r. >>>> >>>> The macosx-port/hotspot changeset for this merge is: >>>> >>>> changeset: 2756:69de8d34a370 >>>> tag: tip >>>> user: swingler at apple.com >>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>> (avoids stomping DYLD_LIBRARY_PATH) >>>> >>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>> regressing the non-MacOS X platforms. In other words, we're trying >>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>> Shaking out the MacOS X Port itself will be done with other changesets >>>> on an as needed basis. >>>> >>>> Just to be clear, the push target for this changeset is the >>>> RT_Baseline >>>> sub-repo of HotSpot Express (currently HSX-23): >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>> >>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>> can review these changes in different ways. My primary focus here is >>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>> specific changes. Obviously, if you see something I messed up in those >>>> files, I'd like to know. >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>> >>>> The order of the files in the above webrev is the same as for >>>> for the subset webrevs below. >>>> >>>> Here's the webrevs for the changes in subsets: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>> >>>> >>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>> >>>> >>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>> made for the MacOS X port. There's a couple of files that also contain >>>> Dtrace related changes, but I decided it was better to include those >>>> files in this subset. >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>> >>>> >>>> The above webrev has almost all of the changes to enable Dtrace on >>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>> which is why the code is #ifdef'ed. I had to change the original >>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> >>>> #else /* USDT2 */ >>>> >>>> #endif /* USDT2 */ >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> #endif /* ! USDT2 */ >>>> >>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>> HotSpot style guidelines very consistently, but I decided not to fix >>>> that so I could diff against the macosx-port/hotspot more reliably. >>>> >>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>> Dtrace implementation to the newer version. However, that work will be >>>> done independently of this bug (7098194). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>> >>>> >>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>> to bless these changes... >>>> >>>> Builds done so far: >>>> >>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>> jvmg} >>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>> HSX repo >>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new >>>> HSX repo >>>> >>>> Testing done so far: >>>> >>>> - Serviceability stack (25 subsuites): >>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>> logging, mm >>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>> misc_attach, misc_jvmstat, misc_tools >>>> - Tested configs (8 configs) >>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>> >>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>> i.e., did the build "work"? >>>> >>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>> testing should be finished later today. >>>> >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>> - dtrace testing on Solaris X86 >>>> - code review >>>> - start bring up of more formal dev testing on MacOS X >>>> >>>> Thanks, in advance, for any review comments. >>>> >>>> Dan >>>> >>>> >>> From tom.rodriguez at oracle.com Thu Oct 13 10:32:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 13 Oct 2011 10:32:59 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E96F08C.9060600@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> Message-ID: <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> On Oct 13, 2011, at 7:07 AM, Daniel D. Daugherty wrote: > On 10/12/11 7:59 PM, David Holmes wrote: >> Okay, I won't respond to all the past emails concerning my first round comments, but will start afresh here utilising the additional information that has been provided. > > Thanks. I appreciate that since this review has taken more time > than anyone predicted. > > >> But first a new comment: >> >> src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp (and probably elsewhere) >> >> fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, rslt)); >> >> It is far more informative to provide the error string "strerror(rslt)" than the decimal value of the error code. (We're probably guilty of this in many places but lets not propagate bad habits.) > > Changing the format string from "%d" to INT32_FORMAT was done > because Paul pointed out that HotSpot isn't supposed to use > format specifiers like "%d" directly. I don't think that's true. %d is the format for the int type and is broadly used in hotspot. Replacing %d with INT32_FORMAT seems more obfuscating than anything. The _FORMAT types are mainly there to deal with the inconsistent handling of longs and pointer sized values in format strings not to hide all formats. Personally I would eradicate INT32_FORMAT from the source since it doesn't add value and is rarely used. tom > > That is different than changing the output from a decimal to > string which I think is beyond the scope of this changeset. It > does raise interesting questions about error diagnostics and, > if memory serves me correctly, there is an open bug for improving > error diagnostics... > > And, yes, I'll have to check the equivalent Linux code to see if > the format strings need to be fixed there also. I suspect they do, > but I already have plans (and a script) to make a pass at sync'ing > BSD improvements back to Linux. > > >> src/share/vm/prims/jni.cpp + thread.* >> >> ! thread->set_done_attaching_via_jni(); >> >> I think the naming has gotten overly verbose here. The only way to attach is by definition via JNI. I don't think there was anything wrong with the existing _is_attaching logic (yes I added it! ;-) ) and my only complaint was that the new _is_attached should really be _was_attached. Perhaps a better/simpler/cleaer approach here would have been to have a field: can_set_native_thread_name, and only set it to true in the non-attaching case. Another cleanup RFE perhaps. > > On several occasions I have fielded questions about the difference > between "attach on demand" and "JNI attach" so there is definitely > confusion out there. I think the renaming adds clarity and I had > thought you would like the reduction in number of fields. I also > think the new JNIAttachStates is cleaner and more clear. I think > that adding a field called can_set_native_thread_name is going to > cause some confusion with JVM/TI capabilities since all of those > are named in the style of can_do_this and can_do_that. > > >> src/share/vm/utilities/debug.cpp >> >> Normally if we propose to move something into a product build there is a discussion about what we are moving, why, and what the impact is on build size and runtime performance. I don't see any of that here. :( > > I've only recently joined the MacOS Port project so I have no idea > what was discussed before I arrived. I have difficulty imagining > that the changes to debug.cpp will add much to the size and I don't > think they will affect runtime performance unless they are used. > Compared to what I just added via Full Debug Symbols, this has got > to be a drop in the bucket :-) > > >> - set_native_thread_name: >> >> Ok so I have to go back to earlier emails here. Makes sense that Thread.setName is augmented to call JVM_SetNativeThreadName. However I don't like the semantics of this particular addition. setName has no usage restrictions on it, but set_native_thread_name is a no-op unless called by the current thread. By restricting it to the current thread it simplifies synchronization logic, but it seems a somewhat arbitrary restriction in terms of the functionality, given the more general nature of the setName API. I guess this is Yet Another RFE: set_native_thread_name should not be restricted to only the current thread. > > We definitely need to get some clarity about the addition of > JVM_SetNativeThreadName(). I'm not fond of APIs without return > values so that's one thing to log in the new bug. The "must be > current thread" semantic should also be hashed out/clarified. > > Like any API between the JDK and HotSpot, changing it will be a > pain and require coordination. > >> BTW: are the JDK changes associated with this also being pushed at some stage? > > Yes, but the exact process has not been finalized. Since there > are changes being made/coordinated by multiple teams, I'm not > sure which JDK8 sub-repos will be used. > > >> If so are the hotspot changes being pushed first? > > I'm planning to push this changeset to RT_Baseline today. I don't > know if there is an HSX-B23-B02 snapshot this week, but I think > I've missed the window by one day. Normally changes have to hit > RT_Baseline by Wednesday nightly cut-off to be included in the > RT_Baseline -> Main_Baseline push for a given week... > > However, I don't know your plans for gatekeeping this week so > maybe you aren't planning to push until Friday morning. > > Strangely enough, because I'm pushing to HSX-23 via RT_Baseline, > my repo coordination life is much easier. HSX-23 will get to > JDK7u via a bulk update so I don't have to juggle too much... > > Dan > > > > >> >> Cheers, >> David >> >> On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I've closed out Code Review Round 0 and I'm posting new webrevs >>> for Code Review Round 1: >>> >>> Here's the webrev for just the deltas between Code Review Round 0 >>> and Code Review Round 1: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>> >>> >>> Here's the webrev for all the changes in one shot: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>> >>> And here are the same subset webrevs: >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>> >>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>> >>> >>> >>> Here's my current commit message: >>> >>>> 7098194: integrate macosx-port changes >>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>> Reviewed-by: kvn, dholmes, never, phh >>>> Contributed-by: Christos Zoulas , Greg Lewis >>>> , Kurt Miller , >>>> Alexander Strange , Mike Swingler >>>> , Roger Hoover >>> >>> Thanks, in advance, for any final feedback for this changeset. >>> >>> Dan >>> >>> >>>> Greetings, >>>> >>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>> >>>> 7089790 integrate bsd-port changes >>>> >>>> and I'm following up on that work using the following bug: >>>> >>>> 7098194 integrate macosx-port changes >>>> >>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>> include additional changes from the BSD Port in addition the deltas >>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>> this resync is: >>>> >>>> changeset: 2729:f1a18ada5853 >>>> tag: tip >>>> user: Greg Lewis >>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>> summary: . Finish removing hsearch_r. >>>> >>>> The macosx-port/hotspot changeset for this merge is: >>>> >>>> changeset: 2756:69de8d34a370 >>>> tag: tip >>>> user: swingler at apple.com >>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>> (avoids stomping DYLD_LIBRARY_PATH) >>>> >>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>> regressing the non-MacOS X platforms. In other words, we're trying >>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>> Shaking out the MacOS X Port itself will be done with other changesets >>>> on an as needed basis. >>>> >>>> Just to be clear, the push target for this changeset is the RT_Baseline >>>> sub-repo of HotSpot Express (currently HSX-23): >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>> >>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>> can review these changes in different ways. My primary focus here is >>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>> specific changes. Obviously, if you see something I messed up in those >>>> files, I'd like to know. >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>> >>>> The order of the files in the above webrev is the same as for >>>> for the subset webrevs below. >>>> >>>> Here's the webrevs for the changes in subsets: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>> >>>> >>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>> >>>> >>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>> made for the MacOS X port. There's a couple of files that also contain >>>> Dtrace related changes, but I decided it was better to include those >>>> files in this subset. >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>> >>>> >>>> The above webrev has almost all of the changes to enable Dtrace on >>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>> which is why the code is #ifdef'ed. I had to change the original >>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> >>>> #else /* USDT2 */ >>>> >>>> #endif /* USDT2 */ >>>> >>>> #ifndef USDT2 >>>> >>>> >>>> #endif /* ! USDT2 */ >>>> >>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>> HotSpot style guidelines very consistently, but I decided not to fix >>>> that so I could diff against the macosx-port/hotspot more reliably. >>>> >>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>> Dtrace implementation to the newer version. However, that work will be >>>> done independently of this bug (7098194). >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>> >>>> >>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>> to bless these changes... >>>> >>>> Builds done so far: >>>> >>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>> HSX repo >>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >>>> repo >>>> >>>> Testing done so far: >>>> >>>> - Serviceability stack (25 subsuites): >>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>> logging, mm >>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>> misc_attach, misc_jvmstat, misc_tools >>>> - Tested configs (8 configs) >>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>> >>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>> i.e., did the build "work"? >>>> >>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>> testing should be finished later today. >>>> >>>> Things still to do (in no particular order): >>>> >>>> - gather the list of contributors for the changeset comment >>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>> - dtrace testing on Solaris X86 >>>> - code review >>>> - start bring up of more formal dev testing on MacOS X >>>> >>>> Thanks, in advance, for any review comments. >>>> >>>> Dan >>>> >>>> From daniel.daugherty at oracle.com Thu Oct 13 10:34:58 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Oct 2011 11:34:58 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> Message-ID: <4E972142.8050503@oracle.com> On 10/13/11 11:32 AM, Tom Rodriguez wrote: > On Oct 13, 2011, at 7:07 AM, Daniel D. Daugherty wrote: > >> On 10/12/11 7:59 PM, David Holmes wrote: >>> Okay, I won't respond to all the past emails concerning my first round comments, but will start afresh here utilising the additional information that has been provided. >> Thanks. I appreciate that since this review has taken more time >> than anyone predicted. >> >> >>> But first a new comment: >>> >>> src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp (and probably elsewhere) >>> >>> fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, rslt)); >>> >>> It is far more informative to provide the error string "strerror(rslt)" than the decimal value of the error code. (We're probably guilty of this in many places but lets not propagate bad habits.) >> Changing the format string from "%d" to INT32_FORMAT was done >> because Paul pointed out that HotSpot isn't supposed to use >> format specifiers like "%d" directly. > I don't think that's true. %d is the format for the int type and is broadly used in hotspot. Replacing %d with INT32_FORMAT seems more obfuscating than anything. The _FORMAT types are mainly there to deal with the inconsistent handling of longs and pointer sized values in format strings not to hide all formats. Personally I would eradicate INT32_FORMAT from the source since it doesn't add value and is rarely used. I'll let you and Paul hash that out when he gets back from vacation. Dan > tom > >> That is different than changing the output from a decimal to >> string which I think is beyond the scope of this changeset. It >> does raise interesting questions about error diagnostics and, >> if memory serves me correctly, there is an open bug for improving >> error diagnostics... >> >> And, yes, I'll have to check the equivalent Linux code to see if >> the format strings need to be fixed there also. I suspect they do, >> but I already have plans (and a script) to make a pass at sync'ing >> BSD improvements back to Linux. >> >> >>> src/share/vm/prims/jni.cpp + thread.* >>> >>> ! thread->set_done_attaching_via_jni(); >>> >>> I think the naming has gotten overly verbose here. The only way to attach is by definition via JNI. I don't think there was anything wrong with the existing _is_attaching logic (yes I added it! ;-) ) and my only complaint was that the new _is_attached should really be _was_attached. Perhaps a better/simpler/cleaer approach here would have been to have a field: can_set_native_thread_name, and only set it to true in the non-attaching case. Another cleanup RFE perhaps. >> On several occasions I have fielded questions about the difference >> between "attach on demand" and "JNI attach" so there is definitely >> confusion out there. I think the renaming adds clarity and I had >> thought you would like the reduction in number of fields. I also >> think the new JNIAttachStates is cleaner and more clear. I think >> that adding a field called can_set_native_thread_name is going to >> cause some confusion with JVM/TI capabilities since all of those >> are named in the style of can_do_this and can_do_that. >> >> >>> src/share/vm/utilities/debug.cpp >>> >>> Normally if we propose to move something into a product build there is a discussion about what we are moving, why, and what the impact is on build size and runtime performance. I don't see any of that here. :( >> I've only recently joined the MacOS Port project so I have no idea >> what was discussed before I arrived. I have difficulty imagining >> that the changes to debug.cpp will add much to the size and I don't >> think they will affect runtime performance unless they are used. >> Compared to what I just added via Full Debug Symbols, this has got >> to be a drop in the bucket :-) >> >> >>> - set_native_thread_name: >>> >>> Ok so I have to go back to earlier emails here. Makes sense that Thread.setName is augmented to call JVM_SetNativeThreadName. However I don't like the semantics of this particular addition. setName has no usage restrictions on it, but set_native_thread_name is a no-op unless called by the current thread. By restricting it to the current thread it simplifies synchronization logic, but it seems a somewhat arbitrary restriction in terms of the functionality, given the more general nature of the setName API. I guess this is Yet Another RFE: set_native_thread_name should not be restricted to only the current thread. >> We definitely need to get some clarity about the addition of >> JVM_SetNativeThreadName(). I'm not fond of APIs without return >> values so that's one thing to log in the new bug. The "must be >> current thread" semantic should also be hashed out/clarified. >> >> Like any API between the JDK and HotSpot, changing it will be a >> pain and require coordination. >> >>> BTW: are the JDK changes associated with this also being pushed at some stage? >> Yes, but the exact process has not been finalized. Since there >> are changes being made/coordinated by multiple teams, I'm not >> sure which JDK8 sub-repos will be used. >> >> >>> If so are the hotspot changes being pushed first? >> I'm planning to push this changeset to RT_Baseline today. I don't >> know if there is an HSX-B23-B02 snapshot this week, but I think >> I've missed the window by one day. Normally changes have to hit >> RT_Baseline by Wednesday nightly cut-off to be included in the >> RT_Baseline -> Main_Baseline push for a given week... >> >> However, I don't know your plans for gatekeeping this week so >> maybe you aren't planning to push until Friday morning. >> >> Strangely enough, because I'm pushing to HSX-23 via RT_Baseline, >> my repo coordination life is much easier. HSX-23 will get to >> JDK7u via a bulk update so I don't have to juggle too much... >> >> Dan >> >> >> >> >>> Cheers, >>> David >>> >>> On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I've closed out Code Review Round 0 and I'm posting new webrevs >>>> for Code Review Round 1: >>>> >>>> Here's the webrev for just the deltas between Code Review Round 0 >>>> and Code Review Round 1: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>>> >>>> >>>> Here's the webrev for all the changes in one shot: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>>> >>>> And here are the same subset webrevs: >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>>> >>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>>> >>>> >>>> >>>> Here's my current commit message: >>>> >>>>> 7098194: integrate macosx-port changes >>>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>>> Reviewed-by: kvn, dholmes, never, phh >>>>> Contributed-by: Christos Zoulas, Greg Lewis >>>>> , Kurt Miller, >>>>> Alexander Strange, Mike Swingler >>>>> , Roger Hoover >>>> Thanks, in advance, for any final feedback for this changeset. >>>> >>>> Dan >>>> >>>> >>>>> Greetings, >>>>> >>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>> >>>>> 7089790 integrate bsd-port changes >>>>> >>>>> and I'm following up on that work using the following bug: >>>>> >>>>> 7098194 integrate macosx-port changes >>>>> >>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>> include additional changes from the BSD Port in addition the deltas >>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>> this resync is: >>>>> >>>>> changeset: 2729:f1a18ada5853 >>>>> tag: tip >>>>> user: Greg Lewis >>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>> summary: . Finish removing hsearch_r. >>>>> >>>>> The macosx-port/hotspot changeset for this merge is: >>>>> >>>>> changeset: 2756:69de8d34a370 >>>>> tag: tip >>>>> user: swingler at apple.com >>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>> >>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>>> Shaking out the MacOS X Port itself will be done with other changesets >>>>> on an as needed basis. >>>>> >>>>> Just to be clear, the push target for this changeset is the RT_Baseline >>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>> >>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>> >>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>>> can review these changes in different ways. My primary focus here is >>>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>>> specific changes. Obviously, if you see something I messed up in those >>>>> files, I'd like to know. >>>>> >>>>> Here's the webrev for all the changes in one shot: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>> >>>>> The order of the files in the above webrev is the same as for >>>>> for the subset webrevs below. >>>>> >>>>> Here's the webrevs for the changes in subsets: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>> >>>>> >>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>> >>>>> >>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>> made for the MacOS X port. There's a couple of files that also contain >>>>> Dtrace related changes, but I decided it was better to include those >>>>> files in this subset. >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>> >>>>> >>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>>> which is why the code is #ifdef'ed. I had to change the original >>>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>> >>>>> #ifndef USDT2 >>>>> >>>>> >>>>> >>>>> #else /* USDT2 */ >>>>> >>>>> #endif /* USDT2 */ >>>>> >>>>> #ifndef USDT2 >>>>> >>>>> >>>>> #endif /* ! USDT2 */ >>>>> >>>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>>> HotSpot style guidelines very consistently, but I decided not to fix >>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>> >>>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>>> Dtrace implementation to the newer version. However, that work will be >>>>> done independently of this bug (7098194). >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>> >>>>> >>>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>>> to bless these changes... >>>>> >>>>> Builds done so far: >>>>> >>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>>> HSX repo >>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >>>>> repo >>>>> >>>>> Testing done so far: >>>>> >>>>> - Serviceability stack (25 subsuites): >>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>> logging, mm >>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>> misc_attach, misc_jvmstat, misc_tools >>>>> - Tested configs (8 configs) >>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>> >>>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>>> i.e., did the build "work"? >>>>> >>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>> testing should be finished later today. >>>>> >>>>> Things still to do (in no particular order): >>>>> >>>>> - gather the list of contributors for the changeset comment >>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>> - dtrace testing on Solaris X86 >>>>> - code review >>>>> - start bring up of more formal dev testing on MacOS X >>>>> >>>>> Thanks, in advance, for any review comments. >>>>> >>>>> Dan >>>>> >>>>> From tom.rodriguez at oracle.com Thu Oct 13 10:38:31 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 13 Oct 2011 17:38:31 +0000 Subject: hg: hsx/hsx22/hotspot: 2 new changesets Message-ID: <20111013173838.9DBE947FE1@hg.openjdk.java.net> Changeset: 953ffc48897d Author: never Date: 2011-09-20 23:50 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/953ffc48897d 7092236: java/util/EnumSet/EnumSetBash.java fails Reviewed-by: kvn, twisti, jrose ! src/share/vm/ci/ciEnv.cpp Changeset: 34d69affce86 Author: never Date: 2011-09-29 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/34d69affce86 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/vmStructs.cpp From rhoover at apple.com Thu Oct 13 10:46:16 2011 From: rhoover at apple.com (roger hoover) Date: Thu, 13 Oct 2011 11:46:16 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E972142.8050503@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> <4E972142.8050503@oracle.com> Message-ID: On Oct 13, 2011, at 11:34 AM, Daniel D. Daugherty wrote: > On 10/13/11 11:32 AM, Tom Rodriguez wrote: >> On Oct 13, 2011, at 7:07 AM, Daniel D. Daugherty wrote: >> >>> On 10/12/11 7:59 PM, David Holmes wrote: >>>> Okay, I won't respond to all the past emails concerning my first round comments, but will start afresh here utilising the additional information that has been provided. >>> Thanks. I appreciate that since this review has taken more time >>> than anyone predicted. >>> >>> >>>> But first a new comment: >>>> >>>> src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp (and probably elsewhere) >>>> >>>> fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, rslt)); >>>> >>>> It is far more informative to provide the error string "strerror(rslt)" than the decimal value of the error code. (We're probably guilty of this in many places but lets not propagate bad habits.) >>> Changing the format string from "%d" to INT32_FORMAT was done >>> because Paul pointed out that HotSpot isn't supposed to use >>> format specifiers like "%d" directly. >> I don't think that's true. %d is the format for the int type and is broadly used in hotspot. Replacing %d with INT32_FORMAT seems more obfuscating than anything. The _FORMAT types are mainly there to deal with the inconsistent handling of longs and pointer sized values in format strings not to hide all formats. Personally I would eradicate INT32_FORMAT from the source since it doesn't add value and is rarely used. > > I'll let you and Paul hash that out when he gets back from vacation. The Apple problem with macros like INT32_FORMAT is that they were being used to print all 32-bit values without respect to the underlying type. For example, on 32-bit builds, long int was being printed with INT32_format. Printing a 32-bit long int with "%d" instead of "%ld" produces a warning on Apple compilers. > > Dan > > >> tom >> >>> That is different than changing the output from a decimal to >>> string which I think is beyond the scope of this changeset. It >>> does raise interesting questions about error diagnostics and, >>> if memory serves me correctly, there is an open bug for improving >>> error diagnostics... >>> >>> And, yes, I'll have to check the equivalent Linux code to see if >>> the format strings need to be fixed there also. I suspect they do, >>> but I already have plans (and a script) to make a pass at sync'ing >>> BSD improvements back to Linux. >>> >>> >>>> src/share/vm/prims/jni.cpp + thread.* >>>> >>>> ! thread->set_done_attaching_via_jni(); >>>> >>>> I think the naming has gotten overly verbose here. The only way to attach is by definition via JNI. I don't think there was anything wrong with the existing _is_attaching logic (yes I added it! ;-) ) and my only complaint was that the new _is_attached should really be _was_attached. Perhaps a better/simpler/cleaer approach here would have been to have a field: can_set_native_thread_name, and only set it to true in the non-attaching case. Another cleanup RFE perhaps. >>> On several occasions I have fielded questions about the difference >>> between "attach on demand" and "JNI attach" so there is definitely >>> confusion out there. I think the renaming adds clarity and I had >>> thought you would like the reduction in number of fields. I also >>> think the new JNIAttachStates is cleaner and more clear. I think >>> that adding a field called can_set_native_thread_name is going to >>> cause some confusion with JVM/TI capabilities since all of those >>> are named in the style of can_do_this and can_do_that. >>> >>> >>>> src/share/vm/utilities/debug.cpp >>>> >>>> Normally if we propose to move something into a product build there is a discussion about what we are moving, why, and what the impact is on build size and runtime performance. I don't see any of that here. :( >>> I've only recently joined the MacOS Port project so I have no idea >>> what was discussed before I arrived. I have difficulty imagining >>> that the changes to debug.cpp will add much to the size and I don't >>> think they will affect runtime performance unless they are used. >>> Compared to what I just added via Full Debug Symbols, this has got >>> to be a drop in the bucket :-) >>> >>> >>>> - set_native_thread_name: >>>> >>>> Ok so I have to go back to earlier emails here. Makes sense that Thread.setName is augmented to call JVM_SetNativeThreadName. However I don't like the semantics of this particular addition. setName has no usage restrictions on it, but set_native_thread_name is a no-op unless called by the current thread. By restricting it to the current thread it simplifies synchronization logic, but it seems a somewhat arbitrary restriction in terms of the functionality, given the more general nature of the setName API. I guess this is Yet Another RFE: set_native_thread_name should not be restricted to only the current thread. >>> We definitely need to get some clarity about the addition of >>> JVM_SetNativeThreadName(). I'm not fond of APIs without return >>> values so that's one thing to log in the new bug. The "must be >>> current thread" semantic should also be hashed out/clarified. >>> >>> Like any API between the JDK and HotSpot, changing it will be a >>> pain and require coordination. >>> >>>> BTW: are the JDK changes associated with this also being pushed at some stage? >>> Yes, but the exact process has not been finalized. Since there >>> are changes being made/coordinated by multiple teams, I'm not >>> sure which JDK8 sub-repos will be used. >>> >>> >>>> If so are the hotspot changes being pushed first? >>> I'm planning to push this changeset to RT_Baseline today. I don't >>> know if there is an HSX-B23-B02 snapshot this week, but I think >>> I've missed the window by one day. Normally changes have to hit >>> RT_Baseline by Wednesday nightly cut-off to be included in the >>> RT_Baseline -> Main_Baseline push for a given week... >>> >>> However, I don't know your plans for gatekeeping this week so >>> maybe you aren't planning to push until Friday morning. >>> >>> Strangely enough, because I'm pushing to HSX-23 via RT_Baseline, >>> my repo coordination life is much easier. HSX-23 will get to >>> JDK7u via a bulk update so I don't have to juggle too much... >>> >>> Dan >>> >>> >>> >>> >>>> Cheers, >>>> David >>>> >>>> On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I've closed out Code Review Round 0 and I'm posting new webrevs >>>>> for Code Review Round 1: >>>>> >>>>> Here's the webrev for just the deltas between Code Review Round 0 >>>>> and Code Review Round 1: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>>>> >>>>> >>>>> Here's the webrev for all the changes in one shot: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>>>> >>>>> And here are the same subset webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>>>> >>>>> >>>>> >>>>> Here's my current commit message: >>>>> >>>>>> 7098194: integrate macosx-port changes >>>>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>>>> Reviewed-by: kvn, dholmes, never, phh >>>>>> Contributed-by: Christos Zoulas, Greg Lewis >>>>>> , Kurt Miller, >>>>>> Alexander Strange, Mike Swingler >>>>>> , Roger Hoover >>>>> Thanks, in advance, for any final feedback for this changeset. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> Greetings, >>>>>> >>>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>>> >>>>>> 7089790 integrate bsd-port changes >>>>>> >>>>>> and I'm following up on that work using the following bug: >>>>>> >>>>>> 7098194 integrate macosx-port changes >>>>>> >>>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>>> include additional changes from the BSD Port in addition the deltas >>>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>>> this resync is: >>>>>> >>>>>> changeset: 2729:f1a18ada5853 >>>>>> tag: tip >>>>>> user: Greg Lewis >>>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>>> summary: . Finish removing hsearch_r. >>>>>> >>>>>> The macosx-port/hotspot changeset for this merge is: >>>>>> >>>>>> changeset: 2756:69de8d34a370 >>>>>> tag: tip >>>>>> user: swingler at apple.com >>>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>>> >>>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>>>> Shaking out the MacOS X Port itself will be done with other changesets >>>>>> on an as needed basis. >>>>>> >>>>>> Just to be clear, the push target for this changeset is the RT_Baseline >>>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>>> >>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>>> >>>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>>>> can review these changes in different ways. My primary focus here is >>>>>> the common or shared code so I'm less worried about the BSD or MacOS X >>>>>> specific changes. Obviously, if you see something I messed up in those >>>>>> files, I'd like to know. >>>>>> >>>>>> Here's the webrev for all the changes in one shot: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>>> >>>>>> The order of the files in the above webrev is the same as for >>>>>> for the subset webrevs below. >>>>>> >>>>>> Here's the webrevs for the changes in subsets: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>>> >>>>>> >>>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>>> >>>>>> >>>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>>> made for the MacOS X port. There's a couple of files that also contain >>>>>> Dtrace related changes, but I decided it was better to include those >>>>>> files in this subset. >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>>> >>>>>> >>>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>>>> which is why the code is #ifdef'ed. I had to change the original >>>>>> #ifdef'ing because the original implementation had put some non-Dtrace >>>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>>> >>>>>> #ifndef USDT2 >>>>>> >>>>>> >>>>>> >>>>>> #else /* USDT2 */ >>>>>> >>>>>> #endif /* USDT2 */ >>>>>> >>>>>> #ifndef USDT2 >>>>>> >>>>>> >>>>>> #endif /* ! USDT2 */ >>>>>> >>>>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>>>> HotSpot style guidelines very consistently, but I decided not to fix >>>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>>> >>>>>> I have to consult with Keith McGuigan about how to migrate the Solaris >>>>>> Dtrace implementation to the newer version. However, that work will be >>>>>> done independently of this bug (7098194). >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>>> >>>>>> >>>>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>>>> to bless these changes... >>>>>> >>>>>> Builds done so far: >>>>>> >>>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >>>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>>>> HSX repo >>>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >>>>>> repo >>>>>> >>>>>> Testing done so far: >>>>>> >>>>>> - Serviceability stack (25 subsuites): >>>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>>> logging, mm >>>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>>> misc_attach, misc_jvmstat, misc_tools >>>>>> - Tested configs (8 configs) >>>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>>> >>>>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>>>> i.e., did the build "work"? >>>>>> >>>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>>> testing should be finished later today. >>>>>> >>>>>> Things still to do (in no particular order): >>>>>> >>>>>> - gather the list of contributors for the changeset comment >>>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>>> - dtrace testing on Solaris X86 >>>>>> - code review >>>>>> - start bring up of more formal dev testing on MacOS X >>>>>> >>>>>> Thanks, in advance, for any review comments. >>>>>> >>>>>> Dan >>>>>> >>>>>> From david.holmes at oracle.com Thu Oct 13 14:53:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Oct 2011 07:53:12 +1000 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E972142.8050503@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> <4E972142.8050503@oracle.com> Message-ID: <4E975DC8.3010400@oracle.com> On 14/10/2011 3:34 AM, Daniel D. Daugherty wrote: > On 10/13/11 11:32 AM, Tom Rodriguez wrote: >> On Oct 13, 2011, at 7:07 AM, Daniel D. Daugherty wrote: >> >>> Changing the format string from "%d" to INT32_FORMAT was done >>> because Paul pointed out that HotSpot isn't supposed to use >>> format specifiers like "%d" directly. >> I don't think that's true. %d is the format for the int type and is >> broadly used in hotspot. Replacing %d with INT32_FORMAT seems more >> obfuscating than anything. The _FORMAT types are mainly there to deal >> with the inconsistent handling of longs and pointer sized values in >> format strings not to hide all formats. Personally I would eradicate >> INT32_FORMAT from the source since it doesn't add value and is rarely >> used. > > I'll let you and Paul hash that out when he gets back from vacation. Paul mis-spoke when he said "There should be no direct uses of printf format specifiers in Hotspot code," as the code is absolutely full of them, as you would expect. We should always use %d for int and jint types, %ld for longs, and should only need macros for typedef'd types (pointers, jlongs, potentially unsigned values) that might be different on different platforms/compilers.. On a different note, there was no runtime snapshot this week as there were no changes. Next snapshot will be next week as per the regular schedule. David ----- > Dan > > >> tom >> >>> That is different than changing the output from a decimal to >>> string which I think is beyond the scope of this changeset. It >>> does raise interesting questions about error diagnostics and, >>> if memory serves me correctly, there is an open bug for improving >>> error diagnostics... >>> >>> And, yes, I'll have to check the equivalent Linux code to see if >>> the format strings need to be fixed there also. I suspect they do, >>> but I already have plans (and a script) to make a pass at sync'ing >>> BSD improvements back to Linux. >>> >>> >>>> src/share/vm/prims/jni.cpp + thread.* >>>> >>>> ! thread->set_done_attaching_via_jni(); >>>> >>>> I think the naming has gotten overly verbose here. The only way to >>>> attach is by definition via JNI. I don't think there was anything >>>> wrong with the existing _is_attaching logic (yes I added it! ;-) ) >>>> and my only complaint was that the new _is_attached should really be >>>> _was_attached. Perhaps a better/simpler/cleaer approach here would >>>> have been to have a field: can_set_native_thread_name, and only set >>>> it to true in the non-attaching case. Another cleanup RFE perhaps. >>> On several occasions I have fielded questions about the difference >>> between "attach on demand" and "JNI attach" so there is definitely >>> confusion out there. I think the renaming adds clarity and I had >>> thought you would like the reduction in number of fields. I also >>> think the new JNIAttachStates is cleaner and more clear. I think >>> that adding a field called can_set_native_thread_name is going to >>> cause some confusion with JVM/TI capabilities since all of those >>> are named in the style of can_do_this and can_do_that. >>> >>> >>>> src/share/vm/utilities/debug.cpp >>>> >>>> Normally if we propose to move something into a product build there >>>> is a discussion about what we are moving, why, and what the impact >>>> is on build size and runtime performance. I don't see any of that >>>> here. :( >>> I've only recently joined the MacOS Port project so I have no idea >>> what was discussed before I arrived. I have difficulty imagining >>> that the changes to debug.cpp will add much to the size and I don't >>> think they will affect runtime performance unless they are used. >>> Compared to what I just added via Full Debug Symbols, this has got >>> to be a drop in the bucket :-) >>> >>> >>>> - set_native_thread_name: >>>> >>>> Ok so I have to go back to earlier emails here. Makes sense that >>>> Thread.setName is augmented to call JVM_SetNativeThreadName. However >>>> I don't like the semantics of this particular addition. setName has >>>> no usage restrictions on it, but set_native_thread_name is a no-op >>>> unless called by the current thread. By restricting it to the >>>> current thread it simplifies synchronization logic, but it seems a >>>> somewhat arbitrary restriction in terms of the functionality, given >>>> the more general nature of the setName API. I guess this is Yet >>>> Another RFE: set_native_thread_name should not be restricted to only >>>> the current thread. >>> We definitely need to get some clarity about the addition of >>> JVM_SetNativeThreadName(). I'm not fond of APIs without return >>> values so that's one thing to log in the new bug. The "must be >>> current thread" semantic should also be hashed out/clarified. >>> >>> Like any API between the JDK and HotSpot, changing it will be a >>> pain and require coordination. >>> >>>> BTW: are the JDK changes associated with this also being pushed at >>>> some stage? >>> Yes, but the exact process has not been finalized. Since there >>> are changes being made/coordinated by multiple teams, I'm not >>> sure which JDK8 sub-repos will be used. >>> >>> >>>> If so are the hotspot changes being pushed first? >>> I'm planning to push this changeset to RT_Baseline today. I don't >>> know if there is an HSX-B23-B02 snapshot this week, but I think >>> I've missed the window by one day. Normally changes have to hit >>> RT_Baseline by Wednesday nightly cut-off to be included in the >>> RT_Baseline -> Main_Baseline push for a given week... >>> >>> However, I don't know your plans for gatekeeping this week so >>> maybe you aren't planning to push until Friday morning. >>> >>> Strangely enough, because I'm pushing to HSX-23 via RT_Baseline, >>> my repo coordination life is much easier. HSX-23 will get to >>> JDK7u via a bulk update so I don't have to juggle too much... >>> >>> Dan >>> >>> >>> >>> >>>> Cheers, >>>> David >>>> >>>> On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I've closed out Code Review Round 0 and I'm posting new webrevs >>>>> for Code Review Round 1: >>>>> >>>>> Here's the webrev for just the deltas between Code Review Round 0 >>>>> and Code Review Round 1: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>>>> >>>>> >>>>> >>>>> Here's the webrev for all the changes in one shot: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>>>> >>>>> And here are the same subset webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>>>> >>>>> >>>>> >>>>> >>>>> Here's my current commit message: >>>>> >>>>>> 7098194: integrate macosx-port changes >>>>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>>>> Reviewed-by: kvn, dholmes, never, phh >>>>>> Contributed-by: Christos Zoulas, Greg Lewis >>>>>> , Kurt Miller, >>>>>> Alexander Strange, Mike Swingler >>>>>> , Roger Hoover >>>>> Thanks, in advance, for any final feedback for this changeset. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> Greetings, >>>>>> >>>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>>> >>>>>> 7089790 integrate bsd-port changes >>>>>> >>>>>> and I'm following up on that work using the following bug: >>>>>> >>>>>> 7098194 integrate macosx-port changes >>>>>> >>>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>>> include additional changes from the BSD Port in addition the deltas >>>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>>> this resync is: >>>>>> >>>>>> changeset: 2729:f1a18ada5853 >>>>>> tag: tip >>>>>> user: Greg Lewis >>>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>>> summary: . Finish removing hsearch_r. >>>>>> >>>>>> The macosx-port/hotspot changeset for this merge is: >>>>>> >>>>>> changeset: 2756:69de8d34a370 >>>>>> tag: tip >>>>>> user: swingler at apple.com >>>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>>> >>>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >>>>>> Shaking out the MacOS X Port itself will be done with other >>>>>> changesets >>>>>> on an as needed basis. >>>>>> >>>>>> Just to be clear, the push target for this changeset is the >>>>>> RT_Baseline >>>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>>> >>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>>> >>>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >>>>>> can review these changes in different ways. My primary focus here is >>>>>> the common or shared code so I'm less worried about the BSD or >>>>>> MacOS X >>>>>> specific changes. Obviously, if you see something I messed up in >>>>>> those >>>>>> files, I'd like to know. >>>>>> >>>>>> Here's the webrev for all the changes in one shot: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>>> >>>>>> >>>>>> The order of the files in the above webrev is the same as for >>>>>> for the subset webrevs below. >>>>>> >>>>>> Here's the webrevs for the changes in subsets: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>>> made for the MacOS X port. There's a couple of files that also >>>>>> contain >>>>>> Dtrace related changes, but I decided it was better to include those >>>>>> files in this subset. >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>>> On MacOS X, a newer version of Dtrace is implemented than on Solaris >>>>>> which is why the code is #ifdef'ed. I had to change the original >>>>>> #ifdef'ing because the original implementation had put some >>>>>> non-Dtrace >>>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >>>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>>> >>>>>> #ifndef USDT2 >>>>>> >>>>>> >>>>>> >>>>>> #else /* USDT2 */ >>>>>> >>>>>> #endif /* USDT2 */ >>>>>> >>>>>> #ifndef USDT2 >>>>>> >>>>>> >>>>>> #endif /* ! USDT2 */ >>>>>> >>>>>> Yes, I realize that the MacOS X Dtrace implementation does not follow >>>>>> HotSpot style guidelines very consistently, but I decided not to fix >>>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>>> >>>>>> I have to consult with Keith McGuigan about how to migrate the >>>>>> Solaris >>>>>> Dtrace implementation to the newer version. However, that work >>>>>> will be >>>>>> done independently of this bug (7098194). >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>>> >>>>>> >>>>>> >>>>>> The above webrev has all the infrastructure (e.g., Makefile) related >>>>>> changes. Many/most folks aren't interested in Makefile stuff so I've >>>>>> put these changes in their own subset. Of course, I need Kelly O'Hair >>>>>> to bless these changes... >>>>>> >>>>>> Builds done so far: >>>>>> >>>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>>>> jvmg} >>>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>>>> HSX repo >>>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >>>>>> repo >>>>>> >>>>>> Testing done so far: >>>>>> >>>>>> - Serviceability stack (25 subsuites): >>>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>>> logging, mm >>>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>>> misc_attach, misc_jvmstat, misc_tools >>>>>> - Tested configs (8 configs) >>>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>>> >>>>>> - MacOS X builds have only had minimal 'java -version' type testing, >>>>>> i.e., did the build "work"? >>>>>> >>>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>>> testing should be finished later today. >>>>>> >>>>>> Things still to do (in no particular order): >>>>>> >>>>>> - gather the list of contributors for the changeset comment >>>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>>> - dtrace testing on Solaris X86 >>>>>> - code review >>>>>> - start bring up of more formal dev testing on MacOS X >>>>>> >>>>>> Thanks, in advance, for any review comments. >>>>>> >>>>>> Dan >>>>>> >>>>>> From john.r.rose at oracle.com Thu Oct 13 16:50:43 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Oct 2011 16:50:43 -0700 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E975DC8.3010400@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> <4E972142.8050503@oracle.com> <4E975DC8.3010400@oracle.com> Message-ID: <576A6751-2995-4D68-B213-8ED688D90CEE@oracle.com> On Oct 13, 2011, at 2:53 PM, David Holmes wrote: > Paul mis-spoke when he said "There should be no direct uses of > printf format specifiers in Hotspot code," as the code is absolutely full of them, as you would expect. We should always use %d for int and jint types, %ld for longs, and should only need macros for typedef'd types (pointers, jlongs, potentially unsigned values) that might be different on different platforms/compilers.. I agree about %d, %s, etc. But let's make a distinction about %ld. Naked use of the C type "long" is a portability trap, and should not be in our code unless there is strong requirement. (The old style pages say something about this, FWIW.) In Hotspot code there are approximately 30 uses of print format strings of the form %ld. That qualifies as a rarity, compared with the corresponding 2000 uses of the string %d. (See below.) Let's continue to make "long" and "%ld" be rare in our source base. -- John -------- grep -n 'print.*%ld' $(hg loc -I src) | wc 34 255 4004 -------- grep -n 'print.*%d' $(hg loc -I src) | wc 2086 15753 236821 -------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111013/351af94a/attachment.html From david.holmes at oracle.com Thu Oct 13 17:43:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Oct 2011 10:43:23 +1000 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <576A6751-2995-4D68-B213-8ED688D90CEE@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> <4E972142.8050503@oracle.com> <4E975DC8.3010400@oracle.com> <576A6751-2995-4D68-B213-8ED688D90CEE@oracle.com> Message-ID: <4E9785AB.4080103@oracle.com> On 14/10/2011 9:50 AM, John Rose wrote: > On Oct 13, 2011, at 2:53 PM, David Holmes wrote: > >> Paul mis-spoke when he said "There should be no direct uses of >> printf format specifiers in Hotspot code," as the code is absolutely >> full of them, as you would expect. We should always use %d for int and >> jint types, %ld for longs, and should only need macros for typedef'd >> types (pointers, jlongs, potentially unsigned values) that might be >> different on different platforms/compilers.. > > I agree about %d, %s, etc. > > But let's make a distinction about %ld. Naked use of the C type "long" > is a portability trap, and should not be in our code unless there is > strong requirement. (The old style pages say something about this, FWIW.) Yes you are absolutely right. We shouldn't be using "long" types in the first place. David > In Hotspot code there are approximately 30 uses of print format strings > of the form %ld. That qualifies as a rarity, compared with the > corresponding 2000 uses of the string %d. (See below.) Let's continue to > make "long" and "%ld" be rare in our source base. > > -- John > > -------- > grep -n 'print.*%ld' $(hg loc -I src) | wc > 34 255 4004 > -------- > grep -n 'print.*%d' $(hg loc -I src) | wc > 2086 15753 236821 > -------- > > From bertrand.delsart at oracle.com Fri Oct 14 07:51:28 2011 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Fri, 14 Oct 2011 14:51:28 +0000 Subject: hg: hsx/hsx22/hotspot: 7096366: PPC: corruption of floating-point values with DeoptimizeALot Message-ID: <20111014145135.8BB2647FFE@hg.openjdk.java.net> Changeset: 876f4a66bd71 Author: bdelsart Date: 2011-10-07 13:28 +0200 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/876f4a66bd71 7096366: PPC: corruption of floating-point values with DeoptimizeALot Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms Reviewed-by: roland, dholmes ! src/share/vm/c1/c1_LinearScan.cpp From tony.printezis at oracle.com Fri Oct 14 11:04:53 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 14 Oct 2011 18:04:53 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20111014180510.660E047001@hg.openjdk.java.net> Changeset: 246daf2c601d Author: brutisso Date: 2011-09-28 08:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/246daf2c601d 7005808: G1: re-enable ReduceInitialCardMarks for G1 Summary: Remove the extra guard to allow G1 to use ReduceInitialCardMarks Reviewed-by: jmasa, tonyp, johnc, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: b9390528617c Author: ysr Date: 2011-10-06 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b9390528617c 7095236: G1: _markedRegions never contains NULL regions Summary: Removed the code for skipping over NULL regions in _markedRegions, replacing it with an assertion that a NULL region is never encountered; removed dead methods, remove() and remove_region(), and inlined a simplified addRegion() directly into fillCache(). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp Changeset: f32dae5d5677 Author: ysr Date: 2011-10-10 08:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f32dae5d5677 Merge Changeset: 3f24f946bc2d Author: brutisso Date: 2011-10-11 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3f24f946bc2d 7099454: /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Summary: Also reviewed by mikael.gerdin at oracle.com; Changed to the `` syntax instead. Also changed "source" to ".". Reviewed-by: never, stefank, dsamersoff, rottenha ! src/os/posix/launcher/launcher.script Changeset: d1bdeef3e3e2 Author: johnc Date: 2011-10-12 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d1bdeef3e3e2 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Summary: There is a race between one thread successfully forwarding and copying the klass mirror for the SoftReference class (including the static master clock) and another thread attempting to use the master clock while attempting to discover a soft reference object. Maintain a shadow copy of the soft reference master clock and use the shadow during reference discovery and reference processing. Reviewed-by: tonyp, brutisso, ysr ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp From tom.rodriguez at oracle.com Fri Oct 14 12:41:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 14 Oct 2011 12:41:46 -0700 Subject: review for 7098528: crash with java -XX:+ExtendedDTraceProbes Message-ID: http://cr.openjdk.java.net/~never/7098528 61 lines changed: 46 ins; 12 del; 3 mod; 6107 unchg 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: kvn The problem is that the dtrace and jvmti code asks for the size of the java.lang.Class instance before we've set the oop_size. We could just pass the size argument down through the various interfaces but that seems fragile. Instead I changed the initialization path for Class instances to setup the indirections earlier so that the dtrace paths work correctly. Tested with failing command from bug report. From vladimir.kozlov at oracle.com Fri Oct 14 14:39:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Oct 2011 14:39:05 -0700 Subject: review for 7098528: crash with java -XX:+ExtendedDTraceProbes In-Reply-To: References: Message-ID: <4E98ABF9.1030606@oracle.com> Tom, Any difference from what you sent before? Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7098528 > 61 lines changed: 46 ins; 12 del; 3 mod; 6107 unchg > > 7098528: crash with java -XX:+ExtendedDTraceProbes > Reviewed-by: kvn > > The problem is that the dtrace and jvmti code asks for the size of the > java.lang.Class instance before we've set the oop_size. We could just > pass the size argument down through the various interfaces but that > seems fragile. Instead I changed the initialization path for Class > instances to setup the indirections earlier so that the dtrace paths > work correctly. Tested with failing command from bug report. > From tom.rodriguez at oracle.com Fri Oct 14 14:45:22 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 14 Oct 2011 14:45:22 -0700 Subject: review for 7098528: crash with java -XX:+ExtendedDTraceProbes In-Reply-To: <4E98ABF9.1030606@oracle.com> References: <4E98ABF9.1030606@oracle.com> Message-ID: Sorry, I thought I hadn't sent it out for review. I think I need a break... tom On Oct 14, 2011, at 2:39 PM, Vladimir Kozlov wrote: > Tom, > > Any difference from what you sent before? > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7098528 >> 61 lines changed: 46 ins; 12 del; 3 mod; 6107 unchg >> 7098528: crash with java -XX:+ExtendedDTraceProbes >> Reviewed-by: kvn >> The problem is that the dtrace and jvmti code asks for the size of the >> java.lang.Class instance before we've set the oop_size. We could just >> pass the size argument down through the various interfaces but that >> seems fragile. Instead I changed the initialization path for Class >> instances to setup the indirections earlier so that the dtrace paths >> work correctly. Tested with failing command from bug report. From john.coomes at oracle.com Fri Oct 14 18:28:33 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 15 Oct 2011 01:28:33 +0000 Subject: hg: hsx/hsx22/hotspot: 3 new changesets Message-ID: <20111015012841.6F1F847006@hg.openjdk.java.net> Changeset: c2ef8b5cd1f3 Author: never Date: 2011-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/c2ef8b5cd1f3 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: kvn, twisti ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 623aec2a90f7 Author: jcoomes Date: 2011-10-14 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/623aec2a90f7 7101102: Bump the hs22 build number to 08 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: d38fde25cf49 Author: jcoomes Date: 2011-10-14 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/d38fde25cf49 Added tag hs22-b08 for changeset 623aec2a90f7 ! .hgtags From john.coomes at oracle.com Fri Oct 14 21:51:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 15 Oct 2011 04:51:49 +0000 Subject: hg: hsx/hsx23/hotspot: 26 new changesets Message-ID: <20111015045246.992E847009@hg.openjdk.java.net> Changeset: 7c20d272643f Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/7c20d272643f Added tag jdk8-b08 for changeset 49ed7eacfd16 ! .hgtags Changeset: edd5f85e2de7 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/edd5f85e2de7 Added tag jdk8-b09 for changeset 7c20d272643f ! .hgtags Changeset: 95607b70acb5 Author: jcoomes Date: 2011-09-30 22:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/95607b70acb5 7096124: Bump the hs23 build number to 02 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 4f93f0d00802 Author: tonyp Date: 2011-09-20 09:59 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4f93f0d00802 7059019: G1: add G1 support to the SA Summary: Extend the SA to recognize the G1CollectedHeap and implement any code that's needed by our serviceability tools (jmap, jinfo, jstack, etc.) that depend on the SA. Reviewed-by: never, poonam, johnc ! agent/make/Makefile + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegion.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! make/sa.files ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 663cb89032b1 Author: johnc Date: 2011-09-20 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/663cb89032b1 7092412: G1: Some roots not marked during an initial mark that gets an evacuation failure Summary: As a result of the changes for 7080389, an evacuation failure during an initial mark pause may result in some root objects not being marked. Pass whether the caller is a root scanning closure into the evacuation failure handling code so that the thread that successfully forwards an object to itself also marks the object. Reviewed-by: ysr, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 114e52976463 Author: tonyp Date: 2011-09-21 01:27 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/114e52976463 7045232: G1: pool names are inconsistent with other collectors (don't have 'Space') Summary: Make sure the eden and survivor pools have "Space" in their name. Reviewed-by: jmasa, ysr ! src/share/vm/services/g1MemoryPool.cpp Changeset: 1847b501ae74 Author: johnc Date: 2011-09-21 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1847b501ae74 7068215: G1: Print reference processing time during remark Summary: Displays the elapsed time taken to perform reference processing during remark as part of the PrintGCDetails output. Reviewed-by: ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d912b598c6c3 Author: tonyp Date: 2011-09-21 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d912b598c6c3 7091032: G1: assert failure when NewRatio is used Summary: The desired min / max heap sizes are miscalculated at initialization when NewRatio is used. The changeset also includes an additional small change to turn a print statement into a warning. Reviewed-by: johnc, jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 5cc33133bc6d Author: johnc Date: 2011-09-21 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5cc33133bc6d 7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header output Summary: Cast HeapRegion::GrainBytes to size_t in output statement. Reviewed-by: ysr, brutisso, pbk, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: f0ecbe78fc7b Author: tonyp Date: 2011-09-22 07:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f0ecbe78fc7b 7092238: G1: Uninitialized field gc_efficiency in G1PrintRegionLivenessInfo output Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4dfb2df418f2 Author: johnc Date: 2011-09-22 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4dfb2df418f2 6484982: G1: process references during evacuation pauses Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate. Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/thread.cpp Changeset: 8229bd737950 Author: tonyp Date: 2011-09-23 16:07 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/8229bd737950 7075646: G1: fix inconsistencies in the monitoring data Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat. Reviewed-by: jmasa, brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: e807478bf9ca Author: brutisso Date: 2011-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e807478bf9ca 7091366: re-enable quicksort tests Summary: Added extern "C" to make it build with JDK6 compilers Reviewed-by: jwilhelm, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 273b46400613 Author: johnc Date: 2011-09-28 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/273b46400613 7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835 Summary: Some objects may not be marked in the event of an evacuation failure in a partially young GC, during a marking cycle. Avoid this situation by not allowing partially young GCs during a marking cycle. Reviewed-by: tonyp, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 811ec3d0833b Author: johnc Date: 2011-10-03 12:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/811ec3d0833b 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 81aa07130d30 Author: tonyp Date: 2011-10-03 19:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/81aa07130d30 7097048: G1: extend the G1 SA changes to print per-heap space information Reviewed-by: brutisso, johnc ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: c63b928b212b Author: stefank Date: 2011-09-12 16:09 +0200 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c63b928b212b 7021322: assert(object_end <= top()) failed: Object crosses promotion LAB boundary Summary: Pass the same object size value to both allocate and unallocate_object Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp Changeset: 65a8ff39a6da Author: johnc Date: 2011-10-05 08:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/65a8ff39a6da 7095194: G1: HeapRegion::GrainBytes, GrainWords, and CardsPerRegion should be size_t Summary: Declare GrainBytes, GrainWords, and CardsPerRegion as size_t. Reviewed-by: jcoomes, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: fd65bc7c09b6 Author: tonyp Date: 2011-10-06 13:28 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/fd65bc7c09b6 Merge ! agent/make/Makefile ! make/sa.files ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 246daf2c601d Author: brutisso Date: 2011-09-28 08:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/246daf2c601d 7005808: G1: re-enable ReduceInitialCardMarks for G1 Summary: Remove the extra guard to allow G1 to use ReduceInitialCardMarks Reviewed-by: jmasa, tonyp, johnc, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: b9390528617c Author: ysr Date: 2011-10-06 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b9390528617c 7095236: G1: _markedRegions never contains NULL regions Summary: Removed the code for skipping over NULL regions in _markedRegions, replacing it with an assertion that a NULL region is never encountered; removed dead methods, remove() and remove_region(), and inlined a simplified addRegion() directly into fillCache(). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp Changeset: f32dae5d5677 Author: ysr Date: 2011-10-10 08:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f32dae5d5677 Merge Changeset: 3f24f946bc2d Author: brutisso Date: 2011-10-11 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3f24f946bc2d 7099454: /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Summary: Also reviewed by mikael.gerdin at oracle.com; Changed to the `` syntax instead. Also changed "source" to ".". Reviewed-by: never, stefank, dsamersoff, rottenha ! src/os/posix/launcher/launcher.script Changeset: d1bdeef3e3e2 Author: johnc Date: 2011-10-12 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d1bdeef3e3e2 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Summary: There is a race between one thread successfully forwarding and copying the klass mirror for the SoftReference class (including the static master clock) and another thread attempting to use the master clock while attempting to discover a soft reference object. Maintain a shadow copy of the soft reference master clock and use the shadow during reference discovery and reference processing. Reviewed-by: tonyp, brutisso, ysr ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: e4f412d2b75d Author: jcoomes Date: 2011-10-14 18:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e4f412d2b75d Merge ! .hgtags Changeset: d815de2e85e5 Author: jcoomes Date: 2011-10-14 18:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d815de2e85e5 Added tag hs23-b02 for changeset e4f412d2b75d ! .hgtags From john.coomes at oracle.com Sat Oct 15 01:07:08 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 15 Oct 2011 08:07:08 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20111015080722.166054700D@hg.openjdk.java.net> Changeset: 7c20d272643f Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c20d272643f Added tag jdk8-b08 for changeset 49ed7eacfd16 ! .hgtags Changeset: edd5f85e2de7 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/edd5f85e2de7 Added tag jdk8-b09 for changeset 7c20d272643f ! .hgtags Changeset: e4f412d2b75d Author: jcoomes Date: 2011-10-14 18:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e4f412d2b75d Merge ! .hgtags Changeset: d815de2e85e5 Author: jcoomes Date: 2011-10-14 18:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d815de2e85e5 Added tag hs23-b02 for changeset e4f412d2b75d ! .hgtags Changeset: bc257a801090 Author: jcoomes Date: 2011-10-14 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bc257a801090 7101096: Bump the hs23 build number to 03 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From igor.veresov at oracle.com Sun Oct 16 06:33:16 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sun, 16 Oct 2011 13:33:16 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20111016133331.CA93347012@hg.openjdk.java.net> Changeset: 940513efe83a Author: iveresov Date: 2011-10-04 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/940513efe83a 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Summary: Save bci of instruction that produced Goto and use it to call back to runtime Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: ec5ce9326985 Author: kvn Date: 2011-10-04 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec5ce9326985 6865265: JVM crashes with "missing exception handler" error Summary: Retry the call to fast_exception_handler_bci_for() after it returned with a pending exception. Don't cache the exception handler pc computed by compute_compiled_exc_handler() if the handler is for another (nested) exception. Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6865265/StackOverflowBug.java Changeset: eba73e0c7780 Author: bdelsart Date: 2011-10-07 13:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eba73e0c7780 7096366: PPC: corruption of floating-point values with DeoptimizeALot Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms Reviewed-by: roland, dholmes ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 0abefdb54d21 Author: twisti Date: 2011-10-11 02:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0abefdb54d21 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Reviewed-by: never, bdelsart ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp Changeset: 5eb9169b1a14 Author: twisti Date: 2011-10-12 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5eb9169b1a14 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp Changeset: a786fdc79c5f Author: never Date: 2011-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a786fdc79c5f 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: kvn, twisti ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 4bac06a82bc3 Author: kvn Date: 2011-10-14 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4bac06a82bc3 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/7100757/Test7100757.java Changeset: 11d17c7d2ee6 Author: iveresov Date: 2011-10-16 02:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/11d17c7d2ee6 Merge From bookjovi at gmail.com Mon Oct 17 02:59:21 2011 From: bookjovi at gmail.com (Jovi Zhang) Date: Mon, 17 Oct 2011 17:59:21 +0800 Subject: linking libjvm.so failed because "cmsLockVerifier.o: file not recognized: File truncated" Message-ID: Hi, When I link libjvm.so, it report "cmsLockVerifier.o: file not recognized: File truncated". So I checked the object file, then I found below: [root at localhost fastdebug]# pwd /root/Hotspot/hotspot/build/linux/linux_i486_compiler1/fastdebug [root at localhost fastdebug]# file *|grep empty cmsLockVerifier.o: empty cmsPermGen.o: empty [root at localhost fastdebug]# gcc --version gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) [root at localhost fastdebug]# uname -a Linux localhost.localdomain 3.1.0-rc2+ #1 SMP Fri Aug 12 08:43:42 CST 2011 i686 i686 i386 GNU/Linux Obviously, cmsLockVerifier.cpp compiled successful, but I don't know why its content is empty. Is anybody also encounter this problem? The code is lastest hotspot code download from openjdk website, and I use command "make ALT_BOOTDIR=/usr/lib/jvm/java-1.6.0-openjdk" .jovi From christian.thalinger at oracle.com Mon Oct 17 03:06:55 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Oct 2011 12:06:55 +0200 Subject: linking libjvm.so failed because "cmsLockVerifier.o: file not recognized: File truncated" In-Reply-To: References: Message-ID: Are you sure the files compiled correctly? Maybe you're out of disk space or something like that. Does it happen again after a clean and rebuild? -- Chris On Oct 17, 2011, at 11:59 AM, Jovi Zhang wrote: > Hi, > When I link libjvm.so, it report "cmsLockVerifier.o: file not > recognized: File truncated". > > So I checked the object file, then I found below: > > [root at localhost fastdebug]# pwd > /root/Hotspot/hotspot/build/linux/linux_i486_compiler1/fastdebug > > [root at localhost fastdebug]# file *|grep empty > cmsLockVerifier.o: empty > cmsPermGen.o: empty > > [root at localhost fastdebug]# gcc --version > gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) > > [root at localhost fastdebug]# uname -a > Linux localhost.localdomain 3.1.0-rc2+ #1 SMP Fri Aug 12 08:43:42 CST > 2011 i686 i686 i386 GNU/Linux > > Obviously, cmsLockVerifier.cpp compiled successful, but I don't > know why its content is empty. > Is anybody also encounter this problem? > > The code is lastest hotspot code download from openjdk website, > and I use command "make ALT_BOOTDIR=/usr/lib/jvm/java-1.6.0-openjdk" > > .jovi From Alan.Bateman at oracle.com Mon Oct 17 03:07:07 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Oct 2011 11:07:07 +0100 Subject: linking libjvm.so failed because "cmsLockVerifier.o: file not recognized: File truncated" In-Reply-To: References: Message-ID: <4E9BFE4B.7040008@oracle.com> Jovi Zhang wrote: > Hi, > When I link libjvm.so, it report "cmsLockVerifier.o: file not > recognized: File truncated". > > So I checked the object file, then I found below: > > [root at localhost fastdebug]# pwd > /root/Hotspot/hotspot/build/linux/linux_i486_compiler1/fastdebug > > [root at localhost fastdebug]# file *|grep empty > cmsLockVerifier.o: empty > cmsPermGen.o: empty > > [root at localhost fastdebug]# gcc --version > gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) > > [root at localhost fastdebug]# uname -a > Linux localhost.localdomain 3.1.0-rc2+ #1 SMP Fri Aug 12 08:43:42 CST > 2011 i686 i686 i386 GNU/Linux > > Obviously, cmsLockVerifier.cpp compiled successful, but I don't > know why its content is empty. > Is anybody also encounter this problem? > > The code is lastest hotspot code download from openjdk website, > and I use command "make ALT_BOOTDIR=/usr/lib/jvm/java-1.6.0-openjdk" > > .jovi > Any chance the build aborted (file system full for example) and was restarted? Did you try removing the empty .o files and rebuilding? -Alan. From paul.hohensee at oracle.com Tue Oct 18 09:17:42 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 18 Oct 2011 12:17:42 -0400 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E975DC8.3010400@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> <4E972142.8050503@oracle.com> <4E975DC8.3010400@oracle.com> Message-ID: <4E9DA6A6.4030608@oracle.com> Just getting to this (was on vacation last Th thru Sun and have been wading through email). I actually think that directly using C/C++ integral types whose sizes are implementation-defined isn't a good idea, though others disagree. If it were up to me, we wouldn't use 'int' or 'unsigned', but rather one of uint32_t, etc. Longs vary more across implementations than int, but even ints can be different sizes on different platforms. Hotspot has built in the assumption that ints are 32-bit everywhere. Anyway, that's why I said there shouldn't be direct uses of printf format specifiers in Hotspot code. I definitely misspoke wrt %s, but I'd like %d to go away too. In this case, the other reviewers are right about not using INT32_FORMAT, because doing so assumes that int's are 32 bits, which it shouldn't. Paul On 10/13/11 5:53 PM, David Holmes wrote: > On 14/10/2011 3:34 AM, Daniel D. Daugherty wrote: >> On 10/13/11 11:32 AM, Tom Rodriguez wrote: >>> On Oct 13, 2011, at 7:07 AM, Daniel D. Daugherty wrote: >>> >>>> Changing the format string from "%d" to INT32_FORMAT was done >>>> because Paul pointed out that HotSpot isn't supposed to use >>>> format specifiers like "%d" directly. >>> I don't think that's true. %d is the format for the int type and is >>> broadly used in hotspot. Replacing %d with INT32_FORMAT seems more >>> obfuscating than anything. The _FORMAT types are mainly there to deal >>> with the inconsistent handling of longs and pointer sized values in >>> format strings not to hide all formats. Personally I would eradicate >>> INT32_FORMAT from the source since it doesn't add value and is rarely >>> used. >> >> I'll let you and Paul hash that out when he gets back from vacation. > > Paul mis-spoke when he said "There should be no direct uses of > printf format specifiers in Hotspot code," as the code is absolutely > full of them, as you would expect. We should always use %d for int and > jint types, %ld for longs, and should only need macros for typedef'd > types (pointers, jlongs, potentially unsigned values) that might be > different on different platforms/compilers.. > > On a different note, there was no runtime snapshot this week as there > were no changes. Next snapshot will be next week as per the regular > schedule. > > David > ----- > >> Dan >> >> >>> tom >>> >>>> That is different than changing the output from a decimal to >>>> string which I think is beyond the scope of this changeset. It >>>> does raise interesting questions about error diagnostics and, >>>> if memory serves me correctly, there is an open bug for improving >>>> error diagnostics... >>>> >>>> And, yes, I'll have to check the equivalent Linux code to see if >>>> the format strings need to be fixed there also. I suspect they do, >>>> but I already have plans (and a script) to make a pass at sync'ing >>>> BSD improvements back to Linux. >>>> >>>> >>>>> src/share/vm/prims/jni.cpp + thread.* >>>>> >>>>> ! thread->set_done_attaching_via_jni(); >>>>> >>>>> I think the naming has gotten overly verbose here. The only way to >>>>> attach is by definition via JNI. I don't think there was anything >>>>> wrong with the existing _is_attaching logic (yes I added it! ;-) ) >>>>> and my only complaint was that the new _is_attached should really be >>>>> _was_attached. Perhaps a better/simpler/cleaer approach here would >>>>> have been to have a field: can_set_native_thread_name, and only set >>>>> it to true in the non-attaching case. Another cleanup RFE perhaps. >>>> On several occasions I have fielded questions about the difference >>>> between "attach on demand" and "JNI attach" so there is definitely >>>> confusion out there. I think the renaming adds clarity and I had >>>> thought you would like the reduction in number of fields. I also >>>> think the new JNIAttachStates is cleaner and more clear. I think >>>> that adding a field called can_set_native_thread_name is going to >>>> cause some confusion with JVM/TI capabilities since all of those >>>> are named in the style of can_do_this and can_do_that. >>>> >>>> >>>>> src/share/vm/utilities/debug.cpp >>>>> >>>>> Normally if we propose to move something into a product build there >>>>> is a discussion about what we are moving, why, and what the impact >>>>> is on build size and runtime performance. I don't see any of that >>>>> here. :( >>>> I've only recently joined the MacOS Port project so I have no idea >>>> what was discussed before I arrived. I have difficulty imagining >>>> that the changes to debug.cpp will add much to the size and I don't >>>> think they will affect runtime performance unless they are used. >>>> Compared to what I just added via Full Debug Symbols, this has got >>>> to be a drop in the bucket :-) >>>> >>>> >>>>> - set_native_thread_name: >>>>> >>>>> Ok so I have to go back to earlier emails here. Makes sense that >>>>> Thread.setName is augmented to call JVM_SetNativeThreadName. However >>>>> I don't like the semantics of this particular addition. setName has >>>>> no usage restrictions on it, but set_native_thread_name is a no-op >>>>> unless called by the current thread. By restricting it to the >>>>> current thread it simplifies synchronization logic, but it seems a >>>>> somewhat arbitrary restriction in terms of the functionality, given >>>>> the more general nature of the setName API. I guess this is Yet >>>>> Another RFE: set_native_thread_name should not be restricted to only >>>>> the current thread. >>>> We definitely need to get some clarity about the addition of >>>> JVM_SetNativeThreadName(). I'm not fond of APIs without return >>>> values so that's one thing to log in the new bug. The "must be >>>> current thread" semantic should also be hashed out/clarified. >>>> >>>> Like any API between the JDK and HotSpot, changing it will be a >>>> pain and require coordination. >>>> >>>>> BTW: are the JDK changes associated with this also being pushed at >>>>> some stage? >>>> Yes, but the exact process has not been finalized. Since there >>>> are changes being made/coordinated by multiple teams, I'm not >>>> sure which JDK8 sub-repos will be used. >>>> >>>> >>>>> If so are the hotspot changes being pushed first? >>>> I'm planning to push this changeset to RT_Baseline today. I don't >>>> know if there is an HSX-B23-B02 snapshot this week, but I think >>>> I've missed the window by one day. Normally changes have to hit >>>> RT_Baseline by Wednesday nightly cut-off to be included in the >>>> RT_Baseline -> Main_Baseline push for a given week... >>>> >>>> However, I don't know your plans for gatekeeping this week so >>>> maybe you aren't planning to push until Friday morning. >>>> >>>> Strangely enough, because I'm pushing to HSX-23 via RT_Baseline, >>>> my repo coordination life is much easier. HSX-23 will get to >>>> JDK7u via a bulk update so I don't have to juggle too much... >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I've closed out Code Review Round 0 and I'm posting new webrevs >>>>>> for Code Review Round 1: >>>>>> >>>>>> Here's the webrev for just the deltas between Code Review Round 0 >>>>>> and Code Review Round 1: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Here's the webrev for all the changes in one shot: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>>>>> >>>>>> >>>>>> And here are the same subset webrevs: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Here's my current commit message: >>>>>> >>>>>>> 7098194: integrate macosx-port changes >>>>>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>>>>> Reviewed-by: kvn, dholmes, never, phh >>>>>>> Contributed-by: Christos Zoulas, Greg Lewis >>>>>>> , Kurt Miller, >>>>>>> Alexander Strange, Mike Swingler >>>>>>> , Roger Hoover >>>>>> Thanks, in advance, for any final feedback for this changeset. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>>>> >>>>>>> 7089790 integrate bsd-port changes >>>>>>> >>>>>>> and I'm following up on that work using the following bug: >>>>>>> >>>>>>> 7098194 integrate macosx-port changes >>>>>>> >>>>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>>>> include additional changes from the BSD Port in addition the deltas >>>>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>>>> this resync is: >>>>>>> >>>>>>> changeset: 2729:f1a18ada5853 >>>>>>> tag: tip >>>>>>> user: Greg Lewis >>>>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>>>> summary: . Finish removing hsearch_r. >>>>>>> >>>>>>> The macosx-port/hotspot changeset for this merge is: >>>>>>> >>>>>>> changeset: 2756:69de8d34a370 >>>>>>> tag: tip >>>>>>> user: swingler at apple.com >>>>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>>>> >>>>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port >>>>>>> projects. >>>>>>> Shaking out the MacOS X Port itself will be done with other >>>>>>> changesets >>>>>>> on an as needed basis. >>>>>>> >>>>>>> Just to be clear, the push target for this changeset is the >>>>>>> RT_Baseline >>>>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>>>> >>>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>>>> >>>>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so >>>>>>> folks >>>>>>> can review these changes in different ways. My primary focus >>>>>>> here is >>>>>>> the common or shared code so I'm less worried about the BSD or >>>>>>> MacOS X >>>>>>> specific changes. Obviously, if you see something I messed up in >>>>>>> those >>>>>>> files, I'd like to know. >>>>>>> >>>>>>> Here's the webrev for all the changes in one shot: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> The order of the files in the above webrev is the same as for >>>>>>> for the subset webrevs below. >>>>>>> >>>>>>> Here's the webrevs for the changes in subsets: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>>>> made for the MacOS X port. There's a couple of files that also >>>>>>> contain >>>>>>> Dtrace related changes, but I decided it was better to include >>>>>>> those >>>>>>> files in this subset. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>>>> On MacOS X, a newer version of Dtrace is implemented than on >>>>>>> Solaris >>>>>>> which is why the code is #ifdef'ed. I had to change the original >>>>>>> #ifdef'ing because the original implementation had put some >>>>>>> non-Dtrace >>>>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>>>>>> build on >>>>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>>>> >>>>>>> #ifndef USDT2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> #else /* USDT2 */ >>>>>>> >>>>>>> #endif /* USDT2 */ >>>>>>> >>>>>>> #ifndef USDT2 >>>>>>> >>>>>>> >>>>>> equivalent> >>>>>>> #endif /* ! USDT2 */ >>>>>>> >>>>>>> Yes, I realize that the MacOS X Dtrace implementation does not >>>>>>> follow >>>>>>> HotSpot style guidelines very consistently, but I decided not to >>>>>>> fix >>>>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>>>> >>>>>>> I have to consult with Keith McGuigan about how to migrate the >>>>>>> Solaris >>>>>>> Dtrace implementation to the newer version. However, that work >>>>>>> will be >>>>>>> done independently of this bug (7098194). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above webrev has all the infrastructure (e.g., Makefile) >>>>>>> related >>>>>>> changes. Many/most folks aren't interested in Makefile stuff so >>>>>>> I've >>>>>>> put these changes in their own subset. Of course, I need Kelly >>>>>>> O'Hair >>>>>>> to bless these changes... >>>>>>> >>>>>>> Builds done so far: >>>>>>> >>>>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>>>>> jvmg} >>>>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>>>>> HSX repo >>>>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with >>>>>>> new HSX >>>>>>> repo >>>>>>> >>>>>>> Testing done so far: >>>>>>> >>>>>>> - Serviceability stack (25 subsuites): >>>>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>>>> logging, mm >>>>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>>>> misc_attach, misc_jvmstat, misc_tools >>>>>>> - Tested configs (8 configs) >>>>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>>>> >>>>>>> - MacOS X builds have only had minimal 'java -version' type >>>>>>> testing, >>>>>>> i.e., did the build "work"? >>>>>>> >>>>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>>>> testing should be finished later today. >>>>>>> >>>>>>> Things still to do (in no particular order): >>>>>>> >>>>>>> - gather the list of contributors for the changeset comment >>>>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>>>> - dtrace testing on Solaris X86 >>>>>>> - code review >>>>>>> - start bring up of more formal dev testing on MacOS X >>>>>>> >>>>>>> Thanks, in advance, for any review comments. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> From daniel.daugherty at oracle.com Tue Oct 18 19:53:29 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Oct 2011 20:53:29 -0600 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E963736.6010202@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> Message-ID: <4E9E3BA9.30504@oracle.com> Greetings, Code Review Round 1 was closed out last week and the bits were pushed to RT_Baseline for further testing: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/436b4a3231bf I have filed the following RFEs based on the code reviews: 7102470 3/4 RFE: USDT1 versus USDT2 ifdefing should be revisited 7102489 3/4 RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems 7102541 3/4 RFE: os::set_native_thread_name() cleanups I think this pretty much covers the loose ends for 7098194. However, if anyone thinks I missed something, please let me know... Dan On 10/12/11 6:56 PM, Daniel D. Daugherty wrote: > Greetings, > > I've closed out Code Review Round 0 and I'm posting new webrevs > for Code Review Round 1: > > Here's the webrev for just the deltas between Code Review Round 0 > and Code Review Round 1: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only > > > Here's the webrev for all the changes in one shot: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ > > And here are the same subset webrevs: > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ > > http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ > > > > Here's my current commit message: > >> 7098194: integrate macosx-port changes >> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >> Reviewed-by: kvn, dholmes, never, phh >> Contributed-by: Christos Zoulas , Greg Lewis >> , Kurt Miller , >> Alexander Strange , Mike Swingler >> , Roger Hoover > > Thanks, in advance, for any final feedback for this changeset. > > Dan > > >> Greetings, >> >> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >> >> 7089790 integrate bsd-port changes >> >> and I'm following up on that work using the following bug: >> >> 7098194 integrate macosx-port changes >> >> The synopsis is a bit off. In reality, the 7098194changeset will >> include additional changes from the BSD Port in addition the deltas >> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >> this resync is: >> >> changeset: 2729:f1a18ada5853 >> tag: tip >> user: Greg Lewis >> date: Wed Sep 21 22:29:10 2011 -0700 >> summary: . Finish removing hsearch_r. >> >> The macosx-port/hotspot changeset for this merge is: >> >> changeset: 2756:69de8d34a370 >> tag: tip >> user: swingler at apple.com >> date: Thu Sep 29 18:10:16 2011 -0700 >> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >> (avoids stomping DYLD_LIBRARY_PATH) >> >> The focus of 7098194 is to get the MacOS X port into HSX-23 without >> regressing the non-MacOS X platforms. In other words, we're trying >> to get HSX-23 caught up with the BSD Port and MacOS X Port projects. >> Shaking out the MacOS X Port itself will be done with other changesets >> on an as needed basis. >> >> Just to be clear, the push target for this changeset is the RT_Baseline >> sub-repo of HotSpot Express (currently HSX-23): >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >> >> Like what Tom did for 7089790, I'm posting multiple webrevs so folks >> can review these changes in different ways. My primary focus here is >> the common or shared code so I'm less worried about the BSD or MacOS X >> specific changes. Obviously, if you see something I messed up in those >> files, I'd like to know. >> >> Here's the webrev for all the changes in one shot: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >> >> The order of the files in the above webrev is the same as for >> for the subset webrevs below. >> >> Here's the webrevs for the changes in subsets: >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >> >> >> The above webrev has the changes to the bsd-port/hotspot repo made >> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >> >> >> The above webrev has the non-Dtrace and non-infrastructure changes >> made for the MacOS X port. There's a couple of files that also >> contain >> Dtrace related changes, but I decided it was better to include those >> files in this subset. >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >> >> >> The above webrev has almost all of the changes to enable Dtrace on >> MacOS X (a couple of files are in the macosx-other-code subset). >> On MacOS X, a newer version of Dtrace is implemented than on Solaris >> which is why the code is #ifdef'ed. I had to change the original >> #ifdef'ing because the original implementation had put some >> non-Dtrace >> code into #ifdef USDT1 ... #endif blocks so the code didn't build on >> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >> redid all MacOS X Dtrace #ifdef'ing in the following forms: >> >> #ifndef USDT2 >> >> >> >> #else /* USDT2 */ >> >> #endif /* USDT2 */ >> >> #ifndef USDT2 >> >> >> #endif /* ! USDT2 */ >> >> Yes, I realize that the MacOS X Dtrace implementation does not >> follow >> HotSpot style guidelines very consistently, but I decided not to fix >> that so I could diff against the macosx-port/hotspot more reliably. >> >> I have to consult with Keith McGuigan about how to migrate the >> Solaris >> Dtrace implementation to the newer version. However, that work >> will be >> done independently of this bug (7098194). >> >> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >> >> >> The above webrev has all the infrastructure (e.g., Makefile) related >> changes. Many/most folks aren't interested in Makefile stuff so I've >> put these changes in their own subset. Of course, I need Kelly >> O'Hair >> to bless these changes... >> >> Builds done so far: >> >> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, jvmg} >> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >> HSX repo >> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new HSX >> repo >> >> Testing done so far: >> >> - Serviceability stack (25 subsuites): >> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >> logging, mm >> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >> misc_attach, misc_jvmstat, misc_tools >> - Tested configs (8 configs) >> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >> >> - MacOS X builds have only had minimal 'java -version' type testing, >> i.e., did the build "work"? >> >> No regressions have been seen in the Solaris X86 testing and WinXP >> testing should be finished later today. >> >> Things still to do (in no particular order): >> >> - gather the list of contributors for the changeset comment >> - JPRT test jobs when the JPRT-hotspotwest queue settles down >> - dtrace testing on Solaris X86 >> - code review >> - start bring up of more formal dev testing on MacOS X >> >> Thanks, in advance, for any review comments. >> >> Dan >> >> > > From david.holmes at oracle.com Tue Oct 18 21:29:54 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Oct 2011 14:29:54 +1000 Subject: Merging the MacOS X Port into HotSpot Express 23 (7098194) In-Reply-To: <4E9DA6A6.4030608@oracle.com> References: <4E947E11.6070004@oracle.com> <4E963736.6010202@oracle.com> <4E964614.9060406@oracle.com> <4E96F08C.9060600@oracle.com> <8777AB99-7D37-436E-8B83-8FE542197842@oracle.com> <4E972142.8050503@oracle.com> <4E975DC8.3010400@oracle.com> <4E9DA6A6.4030608@oracle.com> Message-ID: <4E9E5242.4000602@oracle.com> Hi Paul, On 19/10/2011 2:17 AM, Paul Hohensee wrote: > Just getting to this (was on vacation last Th thru Sun and have been > wading through email). > > I actually think that directly using C/C++ integral types whose sizes are > implementation-defined isn't a good idea, though others disagree. If > it were up to me, we wouldn't use 'int' or 'unsigned', but rather one of > uint32_t, etc. Longs vary more across implementations than int, but > even ints can be different sizes on different platforms. Hotspot has > built in the assumption that ints are 32-bit everywhere. The important thing is that the types and format specifiers always match. So given we have (and should have in my view) int's and "long long"'s then we should use %d and %lld respectively as the correct format specifiers. If we were to have int32_t, int64_t etc then we would need INT32_T_FORMAT etc. I think it would be wrong to change from using the basic C int type to using int32_t for example as that would cause problems trying to build/run on ILP64 systems for example. I think the current code assumes a well-defined execution environment such as ILP32 (or more strictly ILP32LL), LP64 or even ILP64 (though the latter is untested AFAIK). Any platform that had an int type smaller than 32-bits would require a complete rewrite of the VM in my view due to the fact that Java's int type must be 32-bits and must be accessed atomically. David ----- > Anyway, that's why I said there shouldn't be direct uses of printf format > specifiers in Hotspot code. I definitely misspoke wrt %s, but I'd like %d > to go away too. In this case, the other reviewers are right about not using > INT32_FORMAT, because doing so assumes that int's are 32 bits, which > it shouldn't. > > Paul > > On 10/13/11 5:53 PM, David Holmes wrote: >> On 14/10/2011 3:34 AM, Daniel D. Daugherty wrote: >>> On 10/13/11 11:32 AM, Tom Rodriguez wrote: >>>> On Oct 13, 2011, at 7:07 AM, Daniel D. Daugherty wrote: >>>> >>>>> Changing the format string from "%d" to INT32_FORMAT was done >>>>> because Paul pointed out that HotSpot isn't supposed to use >>>>> format specifiers like "%d" directly. >>>> I don't think that's true. %d is the format for the int type and is >>>> broadly used in hotspot. Replacing %d with INT32_FORMAT seems more >>>> obfuscating than anything. The _FORMAT types are mainly there to deal >>>> with the inconsistent handling of longs and pointer sized values in >>>> format strings not to hide all formats. Personally I would eradicate >>>> INT32_FORMAT from the source since it doesn't add value and is rarely >>>> used. >>> >>> I'll let you and Paul hash that out when he gets back from vacation. >> >> Paul mis-spoke when he said "There should be no direct uses of >> printf format specifiers in Hotspot code," as the code is absolutely >> full of them, as you would expect. We should always use %d for int and >> jint types, %ld for longs, and should only need macros for typedef'd >> types (pointers, jlongs, potentially unsigned values) that might be >> different on different platforms/compilers.. >> >> On a different note, there was no runtime snapshot this week as there >> were no changes. Next snapshot will be next week as per the regular >> schedule. >> >> David >> ----- >> >>> Dan >>> >>> >>>> tom >>>> >>>>> That is different than changing the output from a decimal to >>>>> string which I think is beyond the scope of this changeset. It >>>>> does raise interesting questions about error diagnostics and, >>>>> if memory serves me correctly, there is an open bug for improving >>>>> error diagnostics... >>>>> >>>>> And, yes, I'll have to check the equivalent Linux code to see if >>>>> the format strings need to be fixed there also. I suspect they do, >>>>> but I already have plans (and a script) to make a pass at sync'ing >>>>> BSD improvements back to Linux. >>>>> >>>>> >>>>>> src/share/vm/prims/jni.cpp + thread.* >>>>>> >>>>>> ! thread->set_done_attaching_via_jni(); >>>>>> >>>>>> I think the naming has gotten overly verbose here. The only way to >>>>>> attach is by definition via JNI. I don't think there was anything >>>>>> wrong with the existing _is_attaching logic (yes I added it! ;-) ) >>>>>> and my only complaint was that the new _is_attached should really be >>>>>> _was_attached. Perhaps a better/simpler/cleaer approach here would >>>>>> have been to have a field: can_set_native_thread_name, and only set >>>>>> it to true in the non-attaching case. Another cleanup RFE perhaps. >>>>> On several occasions I have fielded questions about the difference >>>>> between "attach on demand" and "JNI attach" so there is definitely >>>>> confusion out there. I think the renaming adds clarity and I had >>>>> thought you would like the reduction in number of fields. I also >>>>> think the new JNIAttachStates is cleaner and more clear. I think >>>>> that adding a field called can_set_native_thread_name is going to >>>>> cause some confusion with JVM/TI capabilities since all of those >>>>> are named in the style of can_do_this and can_do_that. >>>>> >>>>> >>>>>> src/share/vm/utilities/debug.cpp >>>>>> >>>>>> Normally if we propose to move something into a product build there >>>>>> is a discussion about what we are moving, why, and what the impact >>>>>> is on build size and runtime performance. I don't see any of that >>>>>> here. :( >>>>> I've only recently joined the MacOS Port project so I have no idea >>>>> what was discussed before I arrived. I have difficulty imagining >>>>> that the changes to debug.cpp will add much to the size and I don't >>>>> think they will affect runtime performance unless they are used. >>>>> Compared to what I just added via Full Debug Symbols, this has got >>>>> to be a drop in the bucket :-) >>>>> >>>>> >>>>>> - set_native_thread_name: >>>>>> >>>>>> Ok so I have to go back to earlier emails here. Makes sense that >>>>>> Thread.setName is augmented to call JVM_SetNativeThreadName. However >>>>>> I don't like the semantics of this particular addition. setName has >>>>>> no usage restrictions on it, but set_native_thread_name is a no-op >>>>>> unless called by the current thread. By restricting it to the >>>>>> current thread it simplifies synchronization logic, but it seems a >>>>>> somewhat arbitrary restriction in terms of the functionality, given >>>>>> the more general nature of the setName API. I guess this is Yet >>>>>> Another RFE: set_native_thread_name should not be restricted to only >>>>>> the current thread. >>>>> We definitely need to get some clarity about the addition of >>>>> JVM_SetNativeThreadName(). I'm not fond of APIs without return >>>>> values so that's one thing to log in the new bug. The "must be >>>>> current thread" semantic should also be hashed out/clarified. >>>>> >>>>> Like any API between the JDK and HotSpot, changing it will be a >>>>> pain and require coordination. >>>>> >>>>>> BTW: are the JDK changes associated with this also being pushed at >>>>>> some stage? >>>>> Yes, but the exact process has not been finalized. Since there >>>>> are changes being made/coordinated by multiple teams, I'm not >>>>> sure which JDK8 sub-repos will be used. >>>>> >>>>> >>>>>> If so are the hotspot changes being pushed first? >>>>> I'm planning to push this changeset to RT_Baseline today. I don't >>>>> know if there is an HSX-B23-B02 snapshot this week, but I think >>>>> I've missed the window by one day. Normally changes have to hit >>>>> RT_Baseline by Wednesday nightly cut-off to be included in the >>>>> RT_Baseline -> Main_Baseline push for a given week... >>>>> >>>>> However, I don't know your plans for gatekeeping this week so >>>>> maybe you aren't planning to push until Friday morning. >>>>> >>>>> Strangely enough, because I'm pushing to HSX-23 via RT_Baseline, >>>>> my repo coordination life is much easier. HSX-23 will get to >>>>> JDK7u via a bulk update so I don't have to juggle too much... >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 13/10/2011 10:56 AM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I've closed out Code Review Round 0 and I'm posting new webrevs >>>>>>> for Code Review Round 1: >>>>>>> >>>>>>> Here's the webrev for just the deltas between Code Review Round 0 >>>>>>> and Code Review Round 1: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-deltas-only >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Here's the webrev for all the changes in one shot: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-all/ >>>>>>> >>>>>>> >>>>>>> And here are the same subset webrevs: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-bsd-resync/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-other-code/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-dtrace-code/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/1-macosx-infra/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Here's my current commit message: >>>>>>> >>>>>>>> 7098194: integrate macosx-port changes >>>>>>>> Summary: Integrate macosx-port/hotspot changes as of 2011.09.29. >>>>>>>> Reviewed-by: kvn, dholmes, never, phh >>>>>>>> Contributed-by: Christos Zoulas, Greg Lewis >>>>>>>> , Kurt Miller, >>>>>>>> Alexander Strange, Mike Swingler >>>>>>>> , Roger Hoover >>>>>>> Thanks, in advance, for any final feedback for this changeset. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using: >>>>>>>> >>>>>>>> 7089790 integrate bsd-port changes >>>>>>>> >>>>>>>> and I'm following up on that work using the following bug: >>>>>>>> >>>>>>>> 7098194 integrate macosx-port changes >>>>>>>> >>>>>>>> The synopsis is a bit off. In reality, the 7098194changeset will >>>>>>>> include additional changes from the BSD Port in addition the deltas >>>>>>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for >>>>>>>> this resync is: >>>>>>>> >>>>>>>> changeset: 2729:f1a18ada5853 >>>>>>>> tag: tip >>>>>>>> user: Greg Lewis >>>>>>>> date: Wed Sep 21 22:29:10 2011 -0700 >>>>>>>> summary: . Finish removing hsearch_r. >>>>>>>> >>>>>>>> The macosx-port/hotspot changeset for this merge is: >>>>>>>> >>>>>>>> changeset: 2756:69de8d34a370 >>>>>>>> tag: tip >>>>>>>> user: swingler at apple.com >>>>>>>> date: Thu Sep 29 18:10:16 2011 -0700 >>>>>>>> summary: Adding JAVA_LIBRARY_PATH for bundled app launching >>>>>>>> (avoids stomping DYLD_LIBRARY_PATH) >>>>>>>> >>>>>>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without >>>>>>>> regressing the non-MacOS X platforms. In other words, we're trying >>>>>>>> to get HSX-23 caught up with the BSD Port and MacOS X Port >>>>>>>> projects. >>>>>>>> Shaking out the MacOS X Port itself will be done with other >>>>>>>> changesets >>>>>>>> on an as needed basis. >>>>>>>> >>>>>>>> Just to be clear, the push target for this changeset is the >>>>>>>> RT_Baseline >>>>>>>> sub-repo of HotSpot Express (currently HSX-23): >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot >>>>>>>> >>>>>>>> Like what Tom did for 7089790, I'm posting multiple webrevs so >>>>>>>> folks >>>>>>>> can review these changes in different ways. My primary focus >>>>>>>> here is >>>>>>>> the common or shared code so I'm less worried about the BSD or >>>>>>>> MacOS X >>>>>>>> specific changes. Obviously, if you see something I messed up in >>>>>>>> those >>>>>>>> files, I'd like to know. >>>>>>>> >>>>>>>> Here's the webrev for all the changes in one shot: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The order of the files in the above webrev is the same as for >>>>>>>> for the subset webrevs below. >>>>>>>> >>>>>>>> Here's the webrevs for the changes in subsets: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has the changes to the bsd-port/hotspot repo made >>>>>>>> after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot). >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has the non-Dtrace and non-infrastructure changes >>>>>>>> made for the MacOS X port. There's a couple of files that also >>>>>>>> contain >>>>>>>> Dtrace related changes, but I decided it was better to include >>>>>>>> those >>>>>>>> files in this subset. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has almost all of the changes to enable Dtrace on >>>>>>>> MacOS X (a couple of files are in the macosx-other-code subset). >>>>>>>> On MacOS X, a newer version of Dtrace is implemented than on >>>>>>>> Solaris >>>>>>>> which is why the code is #ifdef'ed. I had to change the original >>>>>>>> #ifdef'ing because the original implementation had put some >>>>>>>> non-Dtrace >>>>>>>> code into #ifdef USDT1 ... #endif blocks so the code didn't >>>>>>>> build on >>>>>>>> non-Solaris platforms. In order to be more clean with #ifdef'ing, I >>>>>>>> redid all MacOS X Dtrace #ifdef'ing in the following forms: >>>>>>>> >>>>>>>> #ifndef USDT2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> #else /* USDT2 */ >>>>>>>> >>>>>>>> #endif /* USDT2 */ >>>>>>>> >>>>>>>> #ifndef USDT2 >>>>>>>> >>>>>>>> >>>>>>> equivalent> >>>>>>>> #endif /* ! USDT2 */ >>>>>>>> >>>>>>>> Yes, I realize that the MacOS X Dtrace implementation does not >>>>>>>> follow >>>>>>>> HotSpot style guidelines very consistently, but I decided not to >>>>>>>> fix >>>>>>>> that so I could diff against the macosx-port/hotspot more reliably. >>>>>>>> >>>>>>>> I have to consult with Keith McGuigan about how to migrate the >>>>>>>> Solaris >>>>>>>> Dtrace implementation to the newer version. However, that work >>>>>>>> will be >>>>>>>> done independently of this bug (7098194). >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The above webrev has all the infrastructure (e.g., Makefile) >>>>>>>> related >>>>>>>> changes. Many/most folks aren't interested in Makefile stuff so >>>>>>>> I've >>>>>>>> put these changes in their own subset. Of course, I need Kelly >>>>>>>> O'Hair >>>>>>>> to bless these changes... >>>>>>>> >>>>>>>> Builds done so far: >>>>>>>> >>>>>>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug, >>>>>>>> jvmg} >>>>>>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug} >>>>>>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with new >>>>>>>> HSX repo >>>>>>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with >>>>>>>> new HSX >>>>>>>> repo >>>>>>>> >>>>>>>> Testing done so far: >>>>>>>> >>>>>>>> - Serviceability stack (25 subsuites): >>>>>>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb, >>>>>>>> logging, mm >>>>>>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm, >>>>>>>> mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed, >>>>>>>> misc_attach, misc_jvmstat, misc_tools >>>>>>>> - Tested configs (8 configs) >>>>>>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp} >>>>>>>> >>>>>>>> - MacOS X builds have only had minimal 'java -version' type >>>>>>>> testing, >>>>>>>> i.e., did the build "work"? >>>>>>>> >>>>>>>> No regressions have been seen in the Solaris X86 testing and WinXP >>>>>>>> testing should be finished later today. >>>>>>>> >>>>>>>> Things still to do (in no particular order): >>>>>>>> >>>>>>>> - gather the list of contributors for the changeset comment >>>>>>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down >>>>>>>> - dtrace testing on Solaris X86 >>>>>>>> - code review >>>>>>>> - start bring up of more formal dev testing on MacOS X >>>>>>>> >>>>>>>> Thanks, in advance, for any review comments. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> From zhengyu.gu at oracle.com Wed Oct 19 09:59:23 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 19 Oct 2011 12:59:23 -0400 Subject: Code review request: 7071311 Decoder enhancement Message-ID: <4E9F01EB.6050901@oracle.com> Hi, This is a refactoring and enhancement of current decoder. The primary goal is to make it thread-safe, so it can be used by other than just error handler. It also addressed CR 7067266 (http://monaco.sfbay.sun.com/detail.jsf?cr=7067266). CR 7071311: http://monaco.sfbay.sun.com/detail.jsf?cr=7071311 Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.00/ The changes have been tested on Win32, Linux 32 and Solaris. Thanks, -Zhengyu From aph at redhat.com Wed Oct 19 10:18:41 2011 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Oct 2011 18:18:41 +0100 Subject: Request for review: 6978641 ( was Re: Request for approval: 6929067: Stack guard pages should be removed when thread is detached) In-Reply-To: <19570.58304.571986.204774@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> <4C6E7FF9.9040009@oracle.com> <4C71B142.1000405@oracle.com> <19570.58304.571986.204774@oracle.com> Message-ID: <4E9F0671.3040403@redhat.com> What is the status of this? 6978641 is marked as 11-Closed, Unverified, request for enhancement Andrew. On 08/23/2010 10:10 PM, John Coomes wrote: > David Holmes (David.Holmes at oracle.com) wrote: >> Here's the official OpenJKDK webrev for this: >> >> http://cr.openjdk.java.net/~dholmes/6978641/ > > Hi David, > > Looks good to me, aside from one syntax nit: I find it hard to read > when control flow is embedded in macros like DEBUG_ONLY(), > PRODUCT_ONLY(), etc. Using a separate variable is easier to read and > also can be useful in the debugger, e.g., > > bool chk_bounds = NOT_DEBUG(os::Linux::is_initial_thread()) DEBUG_ONLY(true); > if (chk_bounds && get_stack_bounds(&stack_extent, &stack_base)) { > assert(...); > > -John > >> If I can add you both as reviewers that would be great. >> >> Coleen can you send me details on which release/build I should use in >> the CR and also if there is any special "magic" I need to submit via JPRT. >> >> Thanks, >> David >> >> Coleen Phillimore said the following on 08/20/10 23:15: >>> >>> This change looks fine to me and yes, thanks for pointing out that I did >>> add the test. >>> >>> Coleen >>> >>> Andrew Haley wrote: >>>> On 08/19/2010 04:49 AM, David Holmes wrote: >>>> >>>> >>>>> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp >>>>> --- a/src/os/linux/vm/os_linux.cpp >>>>> +++ b/src/os/linux/vm/os_linux.cpp >>>>> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint >>>>> // where we're going to put our guard pages, truncate the mapping at >>>>> // that point by munmap()ping it. This ensures that when we later >>>>> // munmap() the guard pages we don't leave a hole in the stack >>>>> -// mapping. >>>>> +// mapping. This only affects the main/initial thread, but guard >>>>> +// against future OS changes >>>>> bool os::create_stack_guard_pages(char* addr, size_t size) { >>>>> uintptr_t stack_extent, stack_base; >>>>> - if (get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) >>>>> get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>> non-initial thread"); >>>>> if (stack_extent < (uintptr_t)addr) >>>>> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); >>>>> } >>>>> >>>> >>>> Is stack_extent initialized here in NOT_DEBUG mode? >>>> >>>> >>>>> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* >>>>> } >>>>> >>>>> // If this is a growable mapping, remove the guard pages entirely by >>>>> -// munmap()ping them. If not, just call uncommit_memory(). >>>>> +// munmap()ping them. If not, just call uncommit_memory(). This only >>>>> +// affects the main/initial thread, but guard against future OS changes >>>>> bool os::remove_stack_guard_pages(char* addr, size_t size) { >>>>> uintptr_t stack_extent, stack_base; >>>>> - if (get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) >>>>> get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>> non-initial thread"); >>>>> + >>>>> return ::munmap(addr, size) == 0; >>>>> } >>>> >>>> This is basically a good compromise, I think. >>>> >>>> Andrew. >>>> > From daniel.daugherty at oracle.com Wed Oct 19 10:31:57 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Oct 2011 11:31:57 -0600 Subject: Request for review: 6978641 ( was Re: Request for approval: 6929067: Stack guard pages should be removed when thread is detached) In-Reply-To: <4E9F0671.3040403@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> <4C6E7FF9.9040009@oracle.com> <4C71B142.1000405@oracle.com> <19570.58304.571986.204774@oracle.com> <4E9F0671.3040403@redhat.com> Message-ID: <4E9F098D.2080506@oracle.com> Andrew, My e-mail archive shows the fix for this bug as pushed a long time ago. Please see the attached changeset notification. Dan On 10/19/11 11:18 AM, Andrew Haley wrote: > What is the status of this? 6978641 is marked as > > 11-Closed, Unverified, request for enhancement > > Andrew. > > > > On 08/23/2010 10:10 PM, John Coomes wrote: >> David Holmes (David.Holmes at oracle.com) wrote: >>> Here's the official OpenJKDK webrev for this: >>> >>> http://cr.openjdk.java.net/~dholmes/6978641/ >> Hi David, >> >> Looks good to me, aside from one syntax nit: I find it hard to read >> when control flow is embedded in macros like DEBUG_ONLY(), >> PRODUCT_ONLY(), etc. Using a separate variable is easier to read and >> also can be useful in the debugger, e.g., >> >> bool chk_bounds = NOT_DEBUG(os::Linux::is_initial_thread()) DEBUG_ONLY(true); >> if (chk_bounds&& get_stack_bounds(&stack_extent,&stack_base)) { >> assert(...); >> >> -John >> >>> If I can add you both as reviewers that would be great. >>> >>> Coleen can you send me details on which release/build I should use in >>> the CR and also if there is any special "magic" I need to submit via JPRT. >>> >>> Thanks, >>> David >>> >>> Coleen Phillimore said the following on 08/20/10 23:15: >>>> This change looks fine to me and yes, thanks for pointing out that I did >>>> add the test. >>>> >>>> Coleen >>>> >>>> Andrew Haley wrote: >>>>> On 08/19/2010 04:49 AM, David Holmes wrote: >>>>> >>>>> >>>>>> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp >>>>>> --- a/src/os/linux/vm/os_linux.cpp >>>>>> +++ b/src/os/linux/vm/os_linux.cpp >>>>>> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint >>>>>> // where we're going to put our guard pages, truncate the mapping at >>>>>> // that point by munmap()ping it. This ensures that when we later >>>>>> // munmap() the guard pages we don't leave a hole in the stack >>>>>> -// mapping. >>>>>> +// mapping. This only affects the main/initial thread, but guard >>>>>> +// against future OS changes >>>>>> bool os::create_stack_guard_pages(char* addr, size_t size) { >>>>>> uintptr_t stack_extent, stack_base; >>>>>> - if (get_stack_bounds(&stack_extent,&stack_base)) { >>>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread()&&) >>>>>> get_stack_bounds(&stack_extent,&stack_base)) { >>>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>>> non-initial thread"); >>>>>> if (stack_extent< (uintptr_t)addr) >>>>>> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); >>>>>> } >>>>>> >>>>> Is stack_extent initialized here in NOT_DEBUG mode? >>>>> >>>>> >>>>>> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* >>>>>> } >>>>>> >>>>>> // If this is a growable mapping, remove the guard pages entirely by >>>>>> -// munmap()ping them. If not, just call uncommit_memory(). >>>>>> +// munmap()ping them. If not, just call uncommit_memory(). This only >>>>>> +// affects the main/initial thread, but guard against future OS changes >>>>>> bool os::remove_stack_guard_pages(char* addr, size_t size) { >>>>>> uintptr_t stack_extent, stack_base; >>>>>> - if (get_stack_bounds(&stack_extent,&stack_base)) { >>>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread()&&) >>>>>> get_stack_bounds(&stack_extent,&stack_base)) { >>>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>>> non-initial thread"); >>>>>> + >>>>>> return ::munmap(addr, size) == 0; >>>>>> } >>>>> This is basically a good compromise, I think. >>>>> >>>>> Andrew. >>>>> > -------------- next part -------------- An embedded message was scrubbed... From: david.holmes at oracle.com Subject: hg: jdk7/hotspot-rt/hotspot: 6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths Date: Fri, 27 Aug 2010 00:01:21 +0000 Size: 3299 Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111019/67796564/AttachedMessage.nws From vladimir.kozlov at oracle.com Wed Oct 19 12:21:16 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 19 Oct 2011 19:21:16 +0000 Subject: hg: hsx/hsx22/hotspot: 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Message-ID: <20111019192123.9A2314708E@hg.openjdk.java.net> Changeset: 714bf7aefe10 Author: kvn Date: 2011-10-14 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/714bf7aefe10 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/7100757/Test7100757.java From david.holmes at oracle.com Wed Oct 19 20:03:27 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Oct 2011 13:03:27 +1000 Subject: Request for review: 6978641 ( was Re: Request for approval: 6929067: Stack guard pages should be removed when thread is detached) In-Reply-To: <4E9F098D.2080506@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> <4C6E7FF9.9040009@oracle.com> <4C71B142.1000405@oracle.com> <19570.58304.571986.204774@oracle.com> <4E9F0671.3040403@redhat.com> <4E9F098D.2080506@oracle.com> Message-ID: <4E9F8F7F.9030400@oracle.com> Indeed this was pushed a long long time ago. In case the issue is the "unverified" part it simply means that there was no verification procedure for actually checking that the bug was fixed. Once bugs are fixed they move to a "Fix delivered" state and from there they move to "Closed - verified" or "Closed - unverified" depending on whether QA had a practical means of verifying the fix (eg a testcase). David On 20/10/2011 3:31 AM, Daniel D. Daugherty wrote: > Andrew, > > My e-mail archive shows the fix for this bug as pushed a long time ago. > Please see the attached changeset notification. > > Dan > > > > On 10/19/11 11:18 AM, Andrew Haley wrote: >> What is the status of this? 6978641 is marked as >> >> 11-Closed, Unverified, request for enhancement >> >> Andrew. >> >> >> >> On 08/23/2010 10:10 PM, John Coomes wrote: >>> David Holmes (David.Holmes at oracle.com) wrote: >>>> Here's the official OpenJKDK webrev for this: >>>> >>>> http://cr.openjdk.java.net/~dholmes/6978641/ >>> Hi David, >>> >>> Looks good to me, aside from one syntax nit: I find it hard to read >>> when control flow is embedded in macros like DEBUG_ONLY(), >>> PRODUCT_ONLY(), etc. Using a separate variable is easier to read and >>> also can be useful in the debugger, e.g., >>> >>> bool chk_bounds = NOT_DEBUG(os::Linux::is_initial_thread()) >>> DEBUG_ONLY(true); >>> if (chk_bounds&& get_stack_bounds(&stack_extent,&stack_base)) { >>> assert(...); >>> >>> -John >>> >>>> If I can add you both as reviewers that would be great. >>>> >>>> Coleen can you send me details on which release/build I should use in >>>> the CR and also if there is any special "magic" I need to submit via >>>> JPRT. >>>> >>>> Thanks, >>>> David >>>> >>>> Coleen Phillimore said the following on 08/20/10 23:15: >>>>> This change looks fine to me and yes, thanks for pointing out that >>>>> I did >>>>> add the test. >>>>> >>>>> Coleen >>>>> >>>>> Andrew Haley wrote: >>>>>> On 08/19/2010 04:49 AM, David Holmes wrote: >>>>>> >>>>>> >>>>>>> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp >>>>>>> --- a/src/os/linux/vm/os_linux.cpp >>>>>>> +++ b/src/os/linux/vm/os_linux.cpp >>>>>>> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint >>>>>>> // where we're going to put our guard pages, truncate the mapping at >>>>>>> // that point by munmap()ping it. This ensures that when we later >>>>>>> // munmap() the guard pages we don't leave a hole in the stack >>>>>>> -// mapping. >>>>>>> +// mapping. This only affects the main/initial thread, but guard >>>>>>> +// against future OS changes >>>>>>> bool os::create_stack_guard_pages(char* addr, size_t size) { >>>>>>> uintptr_t stack_extent, stack_base; >>>>>>> - if (get_stack_bounds(&stack_extent,&stack_base)) { >>>>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread()&&) >>>>>>> get_stack_bounds(&stack_extent,&stack_base)) { >>>>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>>>> non-initial thread"); >>>>>>> if (stack_extent< (uintptr_t)addr) >>>>>>> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); >>>>>>> } >>>>>>> >>>>>> Is stack_extent initialized here in NOT_DEBUG mode? >>>>>> >>>>>> >>>>>>> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* >>>>>>> } >>>>>>> >>>>>>> // If this is a growable mapping, remove the guard pages entirely by >>>>>>> -// munmap()ping them. If not, just call uncommit_memory(). >>>>>>> +// munmap()ping them. If not, just call uncommit_memory(). This >>>>>>> only >>>>>>> +// affects the main/initial thread, but guard against future OS >>>>>>> changes >>>>>>> bool os::remove_stack_guard_pages(char* addr, size_t size) { >>>>>>> uintptr_t stack_extent, stack_base; >>>>>>> - if (get_stack_bounds(&stack_extent,&stack_base)) { >>>>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread()&&) >>>>>>> get_stack_bounds(&stack_extent,&stack_base)) { >>>>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>>>> non-initial thread"); >>>>>>> + >>>>>>> return ::munmap(addr, size) == 0; >>>>>>> } >>>>>> This is basically a good compromise, I think. >>>>>> >>>>>> Andrew. >>>>>> >> From volker.simonis at gmail.com Thu Oct 20 00:45:10 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Oct 2011 09:45:10 +0200 Subject: Code review request: 7071311 Decoder enhancement In-Reply-To: <4E9F01EB.6050901@oracle.com> References: <4E9F01EB.6050901@oracle.com> Message-ID: Could you please post globally visible bug urls like http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7067266 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071311 in the future. Thanks, Volker On Wed, Oct 19, 2011 at 6:59 PM, Zhengyu Gu wrote: > Hi, > > This is a refactoring and enhancement of current decoder. The primary goal > is to make it thread-safe, so it can be used by other than just error > handler. It also addressed CR 7067266 > (http://monaco.sfbay.sun.com/detail.jsf?cr=7067266). > > CR 7071311: http://monaco.sfbay.sun.com/detail.jsf?cr=7071311 > Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.00/ > > The changes have been tested on Win32, Linux 32 and Solaris. > > Thanks, > > -Zhengyu > From david.holmes at oracle.com Thu Oct 20 02:01:28 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Oct 2011 19:01:28 +1000 Subject: Code review request: 7071311 Decoder enhancement In-Reply-To: <4E9F01EB.6050901@oracle.com> References: <4E9F01EB.6050901@oracle.com> Message-ID: <4E9FE368.4070600@oracle.com> Hi Zhengyu, This isn't a full review as I don't know the details of either the windows decoder or the Elf decoder. Overall the thread-safety changes seem reasonable: the static Decoder methods encapsulate acquiring the current _decoder instance under protection of a lock. Two things I'm unclear on though: 1. Which threads might concurrently try to use a Decoder? 2. Who calls Decoder::shutdown ? A few minor comments: src/os/windows/vm/decoder_windows.cpp *** 1,7 **** /* ! * Copyright (c) 1997, 2010, Oracle and/or its affiliates. All rights reserved. --- 1,7 ---- /* ! * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. This change to the copyright can't be correct. Also some new files have a 2010 copyright instead of 2011. ----- src/os/windows/vm/decoder_windows.cpp if (_pfnSymGetSymFromAddr64(::GetCurrentProcess(), (DWORD64)addr, &displacement, pSymbol)) { if (buf != NULL) { ! if (_demangle(pSymbol->Name, buf, buflen)) { jio_snprintf(buf, buflen, "%s", pSymbol->Name); } } ! if(offset) *offset = (int)displacement; ! return true; } } ! if (buf != 0 && buflen > 0) buf[0] = '\0'; ! if (offset) *offset = -1; ! return false; } Stylistically I think we prefer to maintain explicit tests against NULL, and we should be consistent. In the above there is: if (buf != NULL) if (offset) if (buf != 0 ...) these should all be the same form and that should be an explicit test against NULL. Semantically they are equivalent of course (provided NULL hasn't been given some weird definition). --- src/share/vm/utilities/decoder.cpp 33 #include "decoder_machO.hpp" machO? Not sure if that is meant to be a pun/joke :) but wouldn't OSX be more consistent with other OSX specific features? But I'm also unclear whether this is really meant to be BSD or OSX as I assume they are not the same. 52 // Decoder is a secondary service. Althrough, it is good to have, typo: Althrough -> Although Cheers, David ----- On 20/10/2011 2:59 AM, Zhengyu Gu wrote: > Hi, > > This is a refactoring and enhancement of current decoder. The primary > goal is to make it thread-safe, so it can be used by other than just > error handler. It also addressed CR 7067266 > (http://monaco.sfbay.sun.com/detail.jsf?cr=7067266). > > CR 7071311: http://monaco.sfbay.sun.com/detail.jsf?cr=7071311 > Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.00/ > > The changes have been tested on Win32, Linux 32 and Solaris. > > Thanks, > > -Zhengyu From zhengyu.gu at oracle.com Thu Oct 20 05:16:34 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 20 Oct 2011 08:16:34 -0400 Subject: Code review request: 7071311 Decoder enhancement In-Reply-To: <4E9FE368.4070600@oracle.com> References: <4E9F01EB.6050901@oracle.com> <4E9FE368.4070600@oracle.com> Message-ID: <4EA01122.90900@oracle.com> Hi David, Thanks for reviewing. On 10/20/2011 5:01 AM, David Holmes wrote: > Hi Zhengyu, > > This isn't a full review as I don't know the details of either the > windows decoder or the Elf decoder. Overall the thread-safety changes > seem reasonable: the static Decoder methods encapsulate acquiring the > current _decoder instance under protection of a lock. Two things I'm > unclear on though: > > 1. Which threads might concurrently try to use a Decoder? Native memory tracking will use Decoder for callsite symbols. > > 2. Who calls Decoder::shutdown ? > None right now, eventually will be called by native memory tracking code under low memory scenario. The idea is to allow native memory tracking code to free as much memory as possible, so it can proceed a final dump to its client, when native out-of-memory is encountered, even means there won't have decoded symbols. Regarding Mach-O, my understanding is that OSX binaries use Mach-O format (http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/executing_files.html ), BSD still uses Elf(?) I will fix the rest. Thanks, -Zhengyu > A few minor comments: > > src/os/windows/vm/decoder_windows.cpp > > *** 1,7 **** > /* > ! * Copyright (c) 1997, 2010, Oracle and/or its affiliates. All > rights reserved. > --- 1,7 ---- > /* > ! * Copyright (c) 2010, Oracle and/or its affiliates. All rights > reserved. > > This change to the copyright can't be correct. Also some new files > have a 2010 copyright instead of 2011. > > > ----- > > src/os/windows/vm/decoder_windows.cpp > > if (_pfnSymGetSymFromAddr64(::GetCurrentProcess(), > (DWORD64)addr, &displacement, pSymbol)) { > if (buf != NULL) { > ! if (_demangle(pSymbol->Name, buf, buflen)) { > jio_snprintf(buf, buflen, "%s", pSymbol->Name); > } > } > ! if(offset) *offset = (int)displacement; > ! return true; > } > } > ! if (buf != 0 && buflen > 0) buf[0] = '\0'; > ! if (offset) *offset = -1; > ! return false; > } > > Stylistically I think we prefer to maintain explicit tests against > NULL, and we should be consistent. In the above there is: > if (buf != NULL) > if (offset) > if (buf != 0 ...) > these should all be the same form and that should be an explicit test > against NULL. Semantically they are equivalent of course (provided > NULL hasn't been given some weird definition). > > --- > > src/share/vm/utilities/decoder.cpp > > 33 #include "decoder_machO.hpp" > > machO? Not sure if that is meant to be a pun/joke :) but wouldn't OSX > be more consistent with other OSX specific features? But I'm also > unclear whether this is really meant to be BSD or OSX as I assume they > are not the same. > > 52 // Decoder is a secondary service. Althrough, it is good to have, > > typo: Althrough -> Although > > > Cheers, > David > ----- > > > On 20/10/2011 2:59 AM, Zhengyu Gu wrote: >> Hi, >> >> This is a refactoring and enhancement of current decoder. The primary >> goal is to make it thread-safe, so it can be used by other than just >> error handler. It also addressed CR 7067266 >> (http://monaco.sfbay.sun.com/detail.jsf?cr=7067266). >> >> CR 7071311: http://monaco.sfbay.sun.com/detail.jsf?cr=7071311 >> Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.00/ >> >> The changes have been tested on Win32, Linux 32 and Solaris. >> >> Thanks, >> >> -Zhengyu From zhengyu.gu at oracle.com Thu Oct 20 06:10:08 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 20 Oct 2011 09:10:08 -0400 Subject: Code review request: 7071311 Decoder enhancement In-Reply-To: <4E9FE368.4070600@oracle.com> References: <4E9F01EB.6050901@oracle.com> <4E9FE368.4070600@oracle.com> Message-ID: <4EA01DB0.8090309@oracle.com> On 10/20/2011 5:01 AM, David Holmes wrote: > Hi Zhengyu, > > This isn't a full review as I don't know the details of either the > windows decoder or the Elf decoder. BTW, the decoders did not change much, mainly just refactor of current code. Thanks, -Zhengyu From omajid at redhat.com Thu Oct 20 08:36:57 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 20 Oct 2011 11:36:57 -0400 Subject: identifier name clash between hotspot and glibc Message-ID: <4EA04019.20101@redhat.com> Hi, I recently ran into a build failure when building hotspot with a recent glibc: In file included from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/prims/methodHandles.hpp:32:0, from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciMethod.hpp:33, from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/code/debugInfoRec.hpp:30, from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciEnv.hpp:31, from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciUtilities.hpp:28, from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciNullObject.hpp:30, from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciConstant.hpp:29, from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/precompiled.hpp:36: /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:426:0: error: "__LEAF" redefined [-Werror] /usr/include/sys/cdefs.h:43:0: note: this is the location of the previous definition cc1plus: all warnings being treated as errors (Complete build logs are available at [1]) As you can guess, glibc has added a macro __LEAF to /usr/include/sys/cdefs.h, which conflicts with the definition of the macro in hotspot [2]. ISO/IEC 9899:TC3 Section 7.1.3 ("Reserved Identifiers") says: All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use From this, it sounds like hotspot should not be using these identifiers. A search for '#define __' shows about 81 matches [3], but only __LEAF is causing a problem right now. Does anyone have any thoughts on how I should go about fixing it? Does renaming __LEAF to something like VM_LEAF or even LEAF__ make sense? Thanks, Omair [1] http://koji.fedoraproject.org/koji/getfile?taskID=3442873&name=build.log [2] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aa78043a4aafe5db1a1a76d544a833b63b4c5f5c [3] http://icedtea.classpath.org/~omajid/name-clash-log.01 From tom.rodriguez at oracle.com Thu Oct 20 11:18:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 20 Oct 2011 11:18:15 -0700 Subject: identifier name clash between hotspot and glibc In-Reply-To: <4EA04019.20101@redhat.com> References: <4EA04019.20101@redhat.com> Message-ID: On Oct 20, 2011, at 8:36 AM, Omair Majid wrote: > Hi, > > I recently ran into a build failure when building hotspot with a recent glibc: > In file included from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/prims/methodHandles.hpp:32:0, > from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciMethod.hpp:33, > from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/code/debugInfoRec.hpp:30, > from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciEnv.hpp:31, > from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciUtilities.hpp:28, > from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciNullObject.hpp:30, > from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciConstant.hpp:29, > from /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/precompiled.hpp:36: > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:426:0: error: "__LEAF" redefined [-Werror] > /usr/include/sys/cdefs.h:43:0: note: this is the location of the previous definition > cc1plus: all warnings being treated as errors > > (Complete build logs are available at [1]) > > As you can guess, glibc has added a macro __LEAF to /usr/include/sys/cdefs.h, which conflicts with the definition of the macro in hotspot [2]. > > ISO/IEC 9899:TC3 Section 7.1.3 ("Reserved Identifiers") says: > All identifiers that begin with an underscore and either an uppercase > letter or another underscore are always reserved for any use > > From this, it sounds like hotspot should not be using these identifiers. A search for '#define __' shows about 81 matches [3], but only __LEAF is causing a problem right now. most of those are defines of __ by itself which while dubious is a widespread idiom and doesn't appear likely to clash, or at least I don't want to change it until we have to. The remaining ones seem pretty benign so I think we can leave them alone until we have problems. > > Does anyone have any thoughts on how I should go about fixing it? Does renaming __LEAF to something like VM_LEAF or even LEAF__ make sense? VM_LEAF_BASE makes sense to me. Can you fix __ENTRY and __QUICK_ENTRY similarly? I filed 7103224 for this. tom > > Thanks, > Omair > > [1] http://koji.fedoraproject.org/koji/getfile?taskID=3442873&name=build.log > [2] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aa78043a4aafe5db1a1a76d544a833b63b4c5f5c > [3] http://icedtea.classpath.org/~omajid/name-clash-log.01 From rhoover at apple.com Thu Oct 20 12:37:28 2011 From: rhoover at apple.com (roger hoover) Date: Thu, 20 Oct 2011 13:37:28 -0600 Subject: use of MAXFLOAT in share/vm/opto/addnode.cpp Message-ID: ./src/share/vm/opto/addnode.cpp:37:#define MAXFLOAT ((float)3.40282346638528860e+38) Can anyone explain the inclusion of the above definition of MAXFLOAT? roger From tom.rodriguez at oracle.com Thu Oct 20 12:48:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 20 Oct 2011 12:48:32 -0700 Subject: use of MAXFLOAT in share/vm/opto/addnode.cpp In-Reply-To: References: Message-ID: No, it looks like an old useless def that could be deleted. Is it causing problems for you? tom On Oct 20, 2011, at 12:37 PM, roger hoover wrote: > ./src/share/vm/opto/addnode.cpp:37:#define MAXFLOAT ((float)3.40282346638528860e+38) > > Can anyone explain the inclusion of the above definition of MAXFLOAT? > > roger > From rhoover at apple.com Thu Oct 20 12:53:38 2011 From: rhoover at apple.com (roger hoover) Date: Thu, 20 Oct 2011 13:53:38 -0600 Subject: use of MAXFLOAT in share/vm/opto/addnode.cpp In-Reply-To: References: Message-ID: <736D4A46-9C21-46C4-8F0C-6D7B81BAA3B8@apple.com> Yes, it is causing builds to fail with some of apple's experimental compiler/include file combinations: /SourceCache/JavaJDK16/JavaJDK16-391/hotspot/src/share/vm/opto/addnode.cpp:37:1: error: "MAXFLOAT" redefined On Oct 20, 2011, at 1:48 PM, Tom Rodriguez wrote: > No, it looks like an old useless def that could be deleted. Is it causing problems for you? > > tom > > On Oct 20, 2011, at 12:37 PM, roger hoover wrote: > >> ./src/share/vm/opto/addnode.cpp:37:#define MAXFLOAT ((float)3.40282346638528860e+38) >> >> Can anyone explain the inclusion of the above definition of MAXFLOAT? >> >> roger >> > From tom.rodriguez at oracle.com Thu Oct 20 12:56:03 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 20 Oct 2011 12:56:03 -0700 Subject: use of MAXFLOAT in share/vm/opto/addnode.cpp In-Reply-To: <736D4A46-9C21-46C4-8F0C-6D7B81BAA3B8@apple.com> References: <736D4A46-9C21-46C4-8F0C-6D7B81BAA3B8@apple.com> Message-ID: On Oct 20, 2011, at 12:53 PM, roger hoover wrote: > Yes, it is causing builds to fail with some of apple's experimental compiler/include file combinations: > /SourceCache/JavaJDK16/JavaJDK16-391/hotspot/src/share/vm/opto/addnode.cpp:37:1: error: "MAXFLOAT" redefined I can delete it as part of the changes to fix the recently reported collision with __LEAF and gcc. I don't really want a whole new bug for it. Does it matter to you? It can clearly be safepoint deleted since it's mentioned nowhere in the system. tom > > On Oct 20, 2011, at 1:48 PM, Tom Rodriguez wrote: > >> No, it looks like an old useless def that could be deleted. Is it causing problems for you? >> >> tom >> >> On Oct 20, 2011, at 12:37 PM, roger hoover wrote: >> >>> ./src/share/vm/opto/addnode.cpp:37:#define MAXFLOAT ((float)3.40282346638528860e+38) >>> >>> Can anyone explain the inclusion of the above definition of MAXFLOAT? >>> >>> roger >>> >> > From kelly.ohair at oracle.com Thu Oct 20 12:57:02 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 20 Oct 2011 12:57:02 -0700 Subject: use of MAXFLOAT in share/vm/opto/addnode.cpp In-Reply-To: References: Message-ID: <5284B07A-2F99-48AD-A973-4B7B290514DF@oracle.com> Sticking my nose in again... :^( I remember some issue with normalized vs. non-normalized IEEE, or something like that, but I agree with deleting it. Wish people would add comments when they do these things. -kto On Oct 20, 2011, at 12:48 PM, Tom Rodriguez wrote: > No, it looks like an old useless def that could be deleted. Is it causing problems for you? > > tom > > On Oct 20, 2011, at 12:37 PM, roger hoover wrote: > >> ./src/share/vm/opto/addnode.cpp:37:#define MAXFLOAT ((float)3.40282346638528860e+38) >> >> Can anyone explain the inclusion of the above definition of MAXFLOAT? >> >> roger >> > From rhoover at apple.com Thu Oct 20 12:59:50 2011 From: rhoover at apple.com (roger hoover) Date: Thu, 20 Oct 2011 13:59:50 -0600 Subject: use of MAXFLOAT in share/vm/opto/addnode.cpp In-Reply-To: References: <736D4A46-9C21-46C4-8F0C-6D7B81BAA3B8@apple.com> Message-ID: <16E32240-A5D5-49D8-A837-BC2AA95D6CB8@apple.com> Fine with me to get rid of it with other changes. I agree that it cannot be seen anywhere in the code as it stands. I'm about to take it out of our 6u29 build to fix our build problems. On Oct 20, 2011, at 1:56 PM, Tom Rodriguez wrote: > > On Oct 20, 2011, at 12:53 PM, roger hoover wrote: > >> Yes, it is causing builds to fail with some of apple's experimental compiler/include file combinations: >> /SourceCache/JavaJDK16/JavaJDK16-391/hotspot/src/share/vm/opto/addnode.cpp:37:1: error: "MAXFLOAT" redefined > > I can delete it as part of the changes to fix the recently reported collision with __LEAF and gcc. I don't really want a whole new bug for it. Does it matter to you? It can clearly be safepoint deleted since it's mentioned nowhere in the system. > > tom > >> >> On Oct 20, 2011, at 1:48 PM, Tom Rodriguez wrote: >> >>> No, it looks like an old useless def that could be deleted. Is it causing problems for you? >>> >>> tom >>> >>> On Oct 20, 2011, at 12:37 PM, roger hoover wrote: >>> >>>> ./src/share/vm/opto/addnode.cpp:37:#define MAXFLOAT ((float)3.40282346638528860e+38) >>>> >>>> Can anyone explain the inclusion of the above definition of MAXFLOAT? >>>> >>>> roger >>>> >>> >> > From david.holmes at oracle.com Thu Oct 20 15:58:21 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Oct 2011 08:58:21 +1000 Subject: identifier name clash between hotspot and glibc In-Reply-To: <4EA04019.20101@redhat.com> References: <4EA04019.20101@redhat.com> Message-ID: <4EA0A78D.1080603@oracle.com> On 21/10/2011 1:36 AM, Omair Majid wrote: > Hi, > > I recently ran into a build failure when building hotspot with a recent > glibc: Which glibc? Thanks, David > In file included from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/prims/methodHandles.hpp:32:0, > > from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciMethod.hpp:33, > > from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/code/debugInfoRec.hpp:30, > > from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciEnv.hpp:31, > > from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciUtilities.hpp:28, > > from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciNullObject.hpp:30, > > from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/ci/ciConstant.hpp:29, > > from > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/precompiled.hpp:36: > > /builddir/build/BUILD/icedtea6-1.10.4/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:426:0: > error: "__LEAF" redefined [-Werror] > /usr/include/sys/cdefs.h:43:0: note: this is the location of the > previous definition > cc1plus: all warnings being treated as errors > > (Complete build logs are available at [1]) > > As you can guess, glibc has added a macro __LEAF to > /usr/include/sys/cdefs.h, which conflicts with the definition of the > macro in hotspot [2]. > > ISO/IEC 9899:TC3 Section 7.1.3 ("Reserved Identifiers") says: > All identifiers that begin with an underscore and either an uppercase > letter or another underscore are always reserved for any use > > From this, it sounds like hotspot should not be using these > identifiers. A search for '#define __' shows about 81 matches [3], but > only __LEAF is causing a problem right now. > > Does anyone have any thoughts on how I should go about fixing it? Does > renaming __LEAF to something like VM_LEAF or even LEAF__ make sense? > > Thanks, > Omair > > [1] > http://koji.fedoraproject.org/koji/getfile?taskID=3442873&name=build.log > [2] > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aa78043a4aafe5db1a1a76d544a833b63b4c5f5c > > [3] http://icedtea.classpath.org/~omajid/name-clash-log.01 From daniel.daugherty at oracle.com Fri Oct 21 00:29:37 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 21 Oct 2011 07:29:37 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20111021072942.DA1C2470BD@hg.openjdk.java.net> Changeset: 2ef3386478e6 Author: dholmes Date: 2011-10-10 21:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2ef3386478e6 7096278: Update the VM name to indicate it is an embedded build Reviewed-by: kvn, never, jcoomes, bobv ! src/share/vm/runtime/vm_version.cpp Changeset: 436b4a3231bf Author: dcubed Date: 2011-10-13 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/436b4a3231bf 7098194: integrate macosx-port changes Summary: Integrate bsd-port/hotspot and macosx-port/hotspot changes as of 2011.09.29. Reviewed-by: kvn, dholmes, never, phh Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller , Alexander Strange , Mike Swingler , Roger Hoover , Victor Hernandez , Pratik Solanki ! .hgignore + agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/symtab.c ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/top.make ! make/bsd/makefiles/vm.make ! make/defs.make - make/templates/bsd-header ! src/cpu/x86/vm/jni_x86.h + src/os/bsd/dtrace/generateJvmOffsets.cpp + src/os/bsd/dtrace/generateJvmOffsets.h + src/os/bsd/dtrace/generateJvmOffsetsMain.c + src/os/bsd/dtrace/hotspot.d + src/os/bsd/dtrace/hotspot_jni.d + src/os/bsd/dtrace/hs_private.d + src/os/bsd/dtrace/jhelper.d + src/os/bsd/dtrace/jvm_dtrace.c + src/os/bsd/dtrace/jvm_dtrace.h + src/os/bsd/dtrace/libjvm_db.c + src/os/bsd/dtrace/libjvm_db.h ! src/os/bsd/vm/dtraceJSDT_bsd.cpp ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/dtrace.hpp + src/share/vm/utilities/dtrace_usdt2_disabled.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/hashtable.cpp Changeset: 23a1c8de9d51 Author: dholmes Date: 2011-10-17 01:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/23a1c8de9d51 Merge - make/templates/bsd-header ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp From igor.veresov at oracle.com Fri Oct 21 03:46:48 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 21 Oct 2011 10:46:48 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111021104658.BED0B470C4@hg.openjdk.java.net> Changeset: 8187c94a9a87 Author: never Date: 2011-10-17 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8187c94a9a87 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java Changeset: e5928e7dab26 Author: never Date: 2011-10-17 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e5928e7dab26 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp Changeset: 16f9fa2bf76c Author: kvn Date: 2011-10-19 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/16f9fa2bf76c 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations Summary: replace the call to memmove by a simple copy loop Reviewed-by: dholmes, kvn, never Contributed-by: axel.siebenborn at sap.com, volker.simonis at gmail.com ! src/cpu/sparc/vm/copy_sparc.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp + test/runtime/7100935/TestConjointAtomicArraycopy.java + test/runtime/7100935/TestShortArraycopy.java Changeset: 1179647ee175 Author: iveresov Date: 2011-10-21 00:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1179647ee175 Merge From omajid at redhat.com Fri Oct 21 06:36:55 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 21 Oct 2011 09:36:55 -0400 Subject: identifier name clash between hotspot and glibc In-Reply-To: <4EA0A78D.1080603@oracle.com> References: <4EA04019.20101@redhat.com> <4EA0A78D.1080603@oracle.com> Message-ID: <4EA17577.8000002@redhat.com> On 10/20/2011 06:58 PM, David Holmes wrote: > On 21/10/2011 1:36 AM, Omair Majid wrote: >> Hi, >> >> I recently ran into a build failure when building hotspot with a recent >> glibc: > > Which glibc? > I am not sure if it has been released yet. It is present in master [1]. Which is included in Fedora 16 as glibc-2.14.90-13 [2]. Thanks, Omair [1] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aa78043a4aafe5db1a1a76d544a833b63b4c5f5c [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=269462 From omajid at redhat.com Fri Oct 21 07:10:49 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 21 Oct 2011 10:10:49 -0400 Subject: identifier name clash between hotspot and glibc In-Reply-To: References: <4EA04019.20101@redhat.com> Message-ID: <4EA17D69.80903@redhat.com> On 10/20/2011 02:18 PM, Tom Rodriguez wrote: > On Oct 20, 2011, at 8:36 AM, Omair Majid wrote: >> From this, it sounds like hotspot should not be using these >> identifiers. A search for '#define __' shows about 81 matches [3], >> but only __LEAF is causing a problem right now. > > most of those are defines of __ by itself which while dubious is a > widespread idiom and doesn't appear likely to clash, or at least I > don't want to change it until we have to. The remaining ones seem > pretty benign so I think we can leave them alone until we have > problems. > >> >> Does anyone have any thoughts on how I should go about fixing it? >> Does renaming __LEAF to something like VM_LEAF or even LEAF__ make >> sense? > > VM_LEAF_BASE makes sense to me. Can you fix __ENTRY and > __QUICK_ENTRY similarly? I filed 7103224 for this. > Thanks for the suggestions. I have posted a webrev at: http://cr.openjdk.java.net/~omajid/webrevs/7103224-glibc-name-clash/webrev.01/ It is against hg.openjdk.java.net/hsx/hotspot-main/. I couldnt get the entire JDK to compile - I ran into build issues with jaxws (I am not sure how buildable this tree is right now). 'make hotspot' worked fine. Thanks, Omair From zhengyu.gu at oracle.com Fri Oct 21 08:24:21 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 21 Oct 2011 11:24:21 -0400 Subject: Minor updates: Code review request: 7071311 Decoder enhancement In-Reply-To: <4E9F01EB.6050901@oracle.com> References: <4E9F01EB.6050901@oracle.com> Message-ID: <4EA18EA5.1070603@oracle.com> Minor updates based on current feedback. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7067266 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071311 Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.01/ Thanks, -Zhengyu On 10/19/2011 12:59 PM, Zhengyu Gu wrote: > Hi, > > This is a refactoring and enhancement of current decoder. The primary > goal is to make it thread-safe, so it can be used by other than just > error handler. It also addressed CR 7067266 > (http://monaco.sfbay.sun.com/detail.jsf?cr=7067266). > > CR 7071311: http://monaco.sfbay.sun.com/detail.jsf?cr=7071311 > Webrev: http://cr.openjdk.java.net/~zgu/7071311/webrev.00/ > > The changes have been tested on Win32, Linux 32 and Solaris. > > Thanks, > > -Zhengyu From tony.printezis at oracle.com Fri Oct 21 09:23:18 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 21 Oct 2011 16:23:18 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111021162333.8C43F470C7@hg.openjdk.java.net> Changeset: ec4b032a4977 Author: tonyp Date: 2011-10-13 13:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec4b032a4977 7098085: G1: partially-young GCs not initiated under certain circumstances Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 074f0252cc13 Author: tonyp Date: 2011-10-14 11:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/074f0252cc13 7088680: G1: Cleanup in the G1CollectorPolicy class Summary: Removed unused fields and methods, removed the G1CollectoryPolicy_BestRegionsFirst class and folded its functionality into the G1CollectorPolicy class. Reviewed-by: ysr, brutisso, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/universe.cpp Changeset: bf2d2b8b1726 Author: johnc Date: 2011-10-17 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf2d2b8b1726 7095243: Disambiguate ReferenceProcessor::_discoveredSoftRefs Summary: Add a new, separate, pointer to the base of the array of discovered reference lists and use this new pointer in places where we iterate over the entire array. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 647872693572 Author: tonyp Date: 2011-10-21 07:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/647872693572 Merge From tom.rodriguez at oracle.com Fri Oct 21 12:53:12 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Oct 2011 12:53:12 -0700 Subject: identifier name clash between hotspot and glibc In-Reply-To: <4EA17D69.80903@redhat.com> References: <4EA04019.20101@redhat.com> <4EA17D69.80903@redhat.com> Message-ID: <084D80C8-0C83-4759-8A6C-D69BA6696B0E@oracle.com> http://cr.openjdk.java.net/~never/7103224 27 lines changed: 0 ins; 2 del; 25 mod; 10809 unchg 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid glibc has recently added a macro __LEAF to /usr/include/sys/cdefs.h, which conflicts with the definition of the macro in hotspot. The name was updated to be more friendly along with other related ones. I also removed a dead definition of MAXFLOAT that was colliding on some Apple builds. On Oct 21, 2011, at 7:10 AM, Omair Majid wrote: > On 10/20/2011 02:18 PM, Tom Rodriguez wrote: >> On Oct 20, 2011, at 8:36 AM, Omair Majid wrote: >>> From this, it sounds like hotspot should not be using these >>> identifiers. A search for '#define __' shows about 81 matches [3], >>> but only __LEAF is causing a problem right now. >> >> most of those are defines of __ by itself which while dubious is a >> widespread idiom and doesn't appear likely to clash, or at least I >> don't want to change it until we have to. The remaining ones seem >> pretty benign so I think we can leave them alone until we have >> problems. >> >>> >>> Does anyone have any thoughts on how I should go about fixing it? >>> Does renaming __LEAF to something like VM_LEAF or even LEAF__ make >>> sense? >> >> VM_LEAF_BASE makes sense to me. Can you fix __ENTRY and >> __QUICK_ENTRY similarly? I filed 7103224 for this. >> > > Thanks for the suggestions. I have posted a webrev at: > http://cr.openjdk.java.net/~omajid/webrevs/7103224-glibc-name-clash/webrev.01/ > > It is against hg.openjdk.java.net/hsx/hotspot-main/. I couldnt get the entire JDK to compile - I ran into build issues with jaxws (I am not sure how buildable this tree is right now). 'make hotspot' worked fine. > > Thanks, > Omair From vladimir.kozlov at oracle.com Fri Oct 21 14:31:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Oct 2011 14:31:21 -0700 Subject: identifier name clash between hotspot and glibc In-Reply-To: <084D80C8-0C83-4759-8A6C-D69BA6696B0E@oracle.com> References: <4EA04019.20101@redhat.com> <4EA17D69.80903@redhat.com> <084D80C8-0C83-4759-8A6C-D69BA6696B0E@oracle.com> Message-ID: <4EA1E4A9.5090007@oracle.com> Nice. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7103224 > 27 lines changed: 0 ins; 2 del; 25 mod; 10809 unchg > > 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc > Reviewed-by: never > Contributed-by: Omair Majid > > glibc has recently added a macro __LEAF to /usr/include/sys/cdefs.h, > which conflicts with the definition of the macro in hotspot. The name > was updated to be more friendly along with other related ones. I also > removed a dead definition of MAXFLOAT that was colliding on some Apple > builds. > > On Oct 21, 2011, at 7:10 AM, Omair Majid wrote: > >> On 10/20/2011 02:18 PM, Tom Rodriguez wrote: >>> On Oct 20, 2011, at 8:36 AM, Omair Majid wrote: >>>> From this, it sounds like hotspot should not be using these >>>> identifiers. A search for '#define __' shows about 81 matches [3], >>>> but only __LEAF is causing a problem right now. >>> most of those are defines of __ by itself which while dubious is a >>> widespread idiom and doesn't appear likely to clash, or at least I >>> don't want to change it until we have to. The remaining ones seem >>> pretty benign so I think we can leave them alone until we have >>> problems. >>> >>>> Does anyone have any thoughts on how I should go about fixing it? >>>> Does renaming __LEAF to something like VM_LEAF or even LEAF__ make >>>> sense? >>> VM_LEAF_BASE makes sense to me. Can you fix __ENTRY and >>> __QUICK_ENTRY similarly? I filed 7103224 for this. >>> >> Thanks for the suggestions. I have posted a webrev at: >> http://cr.openjdk.java.net/~omajid/webrevs/7103224-glibc-name-clash/webrev.01/ >> >> It is against hg.openjdk.java.net/hsx/hotspot-main/. I couldnt get the entire JDK to compile - I ran into build issues with jaxws (I am not sure how buildable this tree is right now). 'make hotspot' worked fine. >> >> Thanks, >> Omair > From tom.rodriguez at oracle.com Fri Oct 21 14:37:18 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Oct 2011 14:37:18 -0700 Subject: identifier name clash between hotspot and glibc In-Reply-To: <4EA1E4A9.5090007@oracle.com> References: <4EA04019.20101@redhat.com> <4EA17D69.80903@redhat.com> <084D80C8-0C83-4759-8A6C-D69BA6696B0E@oracle.com> <4EA1E4A9.5090007@oracle.com> Message-ID: <2881FB4A-E82C-42C4-9874-537D7B0AF7BA@oracle.com> Thanks, Omair and Vladimir. I'll go ahead and push this. tom On Oct 21, 2011, at 2:31 PM, Vladimir Kozlov wrote: > Nice. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7103224 >> 27 lines changed: 0 ins; 2 del; 25 mod; 10809 unchg >> 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc >> Reviewed-by: never >> Contributed-by: Omair Majid >> glibc has recently added a macro __LEAF to /usr/include/sys/cdefs.h, >> which conflicts with the definition of the macro in hotspot. The name >> was updated to be more friendly along with other related ones. I also >> removed a dead definition of MAXFLOAT that was colliding on some Apple >> builds. >> On Oct 21, 2011, at 7:10 AM, Omair Majid wrote: >>> On 10/20/2011 02:18 PM, Tom Rodriguez wrote: >>>> On Oct 20, 2011, at 8:36 AM, Omair Majid wrote: >>>>> From this, it sounds like hotspot should not be using these >>>>> identifiers. A search for '#define __' shows about 81 matches [3], >>>>> but only __LEAF is causing a problem right now. >>>> most of those are defines of __ by itself which while dubious is a >>>> widespread idiom and doesn't appear likely to clash, or at least I >>>> don't want to change it until we have to. The remaining ones seem >>>> pretty benign so I think we can leave them alone until we have >>>> problems. >>>> >>>>> Does anyone have any thoughts on how I should go about fixing it? >>>>> Does renaming __LEAF to something like VM_LEAF or even LEAF__ make >>>>> sense? >>>> VM_LEAF_BASE makes sense to me. Can you fix __ENTRY and >>>> __QUICK_ENTRY similarly? I filed 7103224 for this. >>>> >>> Thanks for the suggestions. I have posted a webrev at: >>> http://cr.openjdk.java.net/~omajid/webrevs/7103224-glibc-name-clash/webrev.01/ >>> >>> It is against hg.openjdk.java.net/hsx/hotspot-main/. I couldnt get the entire JDK to compile - I ran into build issues with jaxws (I am not sure how buildable this tree is right now). 'make hotspot' worked fine. >>> >>> Thanks, >>> Omair From john.coomes at oracle.com Fri Oct 21 14:57:57 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Oct 2011 21:57:57 +0000 Subject: hg: hsx/hsx23/hotspot: 23 new changesets Message-ID: <20111021215844.D5D13470CC@hg.openjdk.java.net> Changeset: 3170e4044f2d Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3170e4044f2d Added tag jdk8-b10 for changeset d815de2e85e5 ! .hgtags Changeset: bc257a801090 Author: jcoomes Date: 2011-10-14 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/bc257a801090 7101096: Bump the hs23 build number to 03 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 940513efe83a Author: iveresov Date: 2011-10-04 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/940513efe83a 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Summary: Save bci of instruction that produced Goto and use it to call back to runtime Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: ec5ce9326985 Author: kvn Date: 2011-10-04 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ec5ce9326985 6865265: JVM crashes with "missing exception handler" error Summary: Retry the call to fast_exception_handler_bci_for() after it returned with a pending exception. Don't cache the exception handler pc computed by compute_compiled_exc_handler() if the handler is for another (nested) exception. Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6865265/StackOverflowBug.java Changeset: eba73e0c7780 Author: bdelsart Date: 2011-10-07 13:28 +0200 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/eba73e0c7780 7096366: PPC: corruption of floating-point values with DeoptimizeALot Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms Reviewed-by: roland, dholmes ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 0abefdb54d21 Author: twisti Date: 2011-10-11 02:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/0abefdb54d21 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Reviewed-by: never, bdelsart ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp Changeset: 5eb9169b1a14 Author: twisti Date: 2011-10-12 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5eb9169b1a14 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp Changeset: a786fdc79c5f Author: never Date: 2011-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a786fdc79c5f 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: kvn, twisti ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 4bac06a82bc3 Author: kvn Date: 2011-10-14 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4bac06a82bc3 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/7100757/Test7100757.java Changeset: 11d17c7d2ee6 Author: iveresov Date: 2011-10-16 02:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/11d17c7d2ee6 Merge Changeset: 2ef3386478e6 Author: dholmes Date: 2011-10-10 21:01 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/2ef3386478e6 7096278: Update the VM name to indicate it is an embedded build Reviewed-by: kvn, never, jcoomes, bobv ! src/share/vm/runtime/vm_version.cpp Changeset: 436b4a3231bf Author: dcubed Date: 2011-10-13 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/436b4a3231bf 7098194: integrate macosx-port changes Summary: Integrate bsd-port/hotspot and macosx-port/hotspot changes as of 2011.09.29. Reviewed-by: kvn, dholmes, never, phh Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller , Alexander Strange , Mike Swingler , Roger Hoover , Victor Hernandez , Pratik Solanki ! .hgignore + agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/symtab.c ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/top.make ! make/bsd/makefiles/vm.make ! make/defs.make - make/templates/bsd-header ! src/cpu/x86/vm/jni_x86.h + src/os/bsd/dtrace/generateJvmOffsets.cpp + src/os/bsd/dtrace/generateJvmOffsets.h + src/os/bsd/dtrace/generateJvmOffsetsMain.c + src/os/bsd/dtrace/hotspot.d + src/os/bsd/dtrace/hotspot_jni.d + src/os/bsd/dtrace/hs_private.d + src/os/bsd/dtrace/jhelper.d + src/os/bsd/dtrace/jvm_dtrace.c + src/os/bsd/dtrace/jvm_dtrace.h + src/os/bsd/dtrace/libjvm_db.c + src/os/bsd/dtrace/libjvm_db.h ! src/os/bsd/vm/dtraceJSDT_bsd.cpp ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/dtrace.hpp + src/share/vm/utilities/dtrace_usdt2_disabled.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/hashtable.cpp Changeset: 23a1c8de9d51 Author: dholmes Date: 2011-10-17 01:40 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/23a1c8de9d51 Merge - make/templates/bsd-header ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: 8187c94a9a87 Author: never Date: 2011-10-17 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/8187c94a9a87 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java Changeset: e5928e7dab26 Author: never Date: 2011-10-17 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e5928e7dab26 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp Changeset: 16f9fa2bf76c Author: kvn Date: 2011-10-19 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/16f9fa2bf76c 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations Summary: replace the call to memmove by a simple copy loop Reviewed-by: dholmes, kvn, never Contributed-by: axel.siebenborn at sap.com, volker.simonis at gmail.com ! src/cpu/sparc/vm/copy_sparc.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp + test/runtime/7100935/TestConjointAtomicArraycopy.java + test/runtime/7100935/TestShortArraycopy.java Changeset: 1179647ee175 Author: iveresov Date: 2011-10-21 00:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1179647ee175 Merge Changeset: ec4b032a4977 Author: tonyp Date: 2011-10-13 13:54 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ec4b032a4977 7098085: G1: partially-young GCs not initiated under certain circumstances Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 074f0252cc13 Author: tonyp Date: 2011-10-14 11:12 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/074f0252cc13 7088680: G1: Cleanup in the G1CollectorPolicy class Summary: Removed unused fields and methods, removed the G1CollectoryPolicy_BestRegionsFirst class and folded its functionality into the G1CollectorPolicy class. Reviewed-by: ysr, brutisso, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/universe.cpp Changeset: bf2d2b8b1726 Author: johnc Date: 2011-10-17 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/bf2d2b8b1726 7095243: Disambiguate ReferenceProcessor::_discoveredSoftRefs Summary: Add a new, separate, pointer to the base of the array of discovered reference lists and use this new pointer in places where we iterate over the entire array. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 647872693572 Author: tonyp Date: 2011-10-21 07:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/647872693572 Merge Changeset: 4d3850d9d326 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4d3850d9d326 Merge - make/templates/bsd-header Changeset: 4538caeef7b6 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4538caeef7b6 Added tag hs23-b03 for changeset 4d3850d9d326 ! .hgtags From john.coomes at oracle.com Sat Oct 22 00:49:06 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 22 Oct 2011 07:49:06 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111022074920.D0FD5470D1@hg.openjdk.java.net> Changeset: 3170e4044f2d Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3170e4044f2d Added tag jdk8-b10 for changeset d815de2e85e5 ! .hgtags Changeset: 4d3850d9d326 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4d3850d9d326 Merge - make/templates/bsd-header Changeset: 4538caeef7b6 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4538caeef7b6 Added tag hs23-b03 for changeset 4d3850d9d326 ! .hgtags Changeset: c9d25d93ddfe Author: jcoomes Date: 2011-10-21 16:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c9d25d93ddfe 7103619: Bump the hs23 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From john.coomes at oracle.com Sat Oct 22 22:34:57 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:34:57 +0000 Subject: hg: hsx/hotspot-main: 8 new changesets Message-ID: <20111023053457.AB699470D3@hg.openjdk.java.net> Changeset: b1d357ebf0cb Author: weijun Date: 2011-09-08 09:06 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b1d357ebf0cb 7087428: move client tests out of jdk_misc Reviewed-by: ohair, alanb ! make/jprt.properties Changeset: 123873564c23 Author: lana Date: 2011-09-13 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/123873564c23 Merge Changeset: 39edfd9d8ff0 Author: lana Date: 2011-09-23 23:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/39edfd9d8ff0 Merge Changeset: 2f1af0e3e8f7 Author: lana Date: 2011-09-26 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2f1af0e3e8f7 Merge Changeset: fb1bc13260d7 Author: lana Date: 2011-10-03 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/fb1bc13260d7 Merge Changeset: 8adb70647b5a Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8adb70647b5a Added tag jdk8-b08 for changeset fb1bc13260d7 ! .hgtags Changeset: a6c4c248e8fa Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a6c4c248e8fa Added tag jdk8-b09 for changeset 8adb70647b5a ! .hgtags Changeset: 1defbc57940a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1defbc57940a Added tag jdk8-b10 for changeset a6c4c248e8fa ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:35:07 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:35:07 +0000 Subject: hg: hsx/hotspot-main/corba: 3 new changesets Message-ID: <20111023053510.72DBF470D4@hg.openjdk.java.net> Changeset: a891732c1a83 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a891732c1a83 Added tag jdk8-b08 for changeset 0d52b1c87aa8 ! .hgtags Changeset: cda87f7fefce Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/cda87f7fefce Added tag jdk8-b09 for changeset a891732c1a83 ! .hgtags Changeset: 0199e4fef5cc Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0199e4fef5cc Added tag jdk8-b10 for changeset cda87f7fefce ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:35:19 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:35:19 +0000 Subject: hg: hsx/hotspot-main/jaxp: 3 new changesets Message-ID: <20111023053519.E1299470D5@hg.openjdk.java.net> Changeset: 93554324c014 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/93554324c014 Added tag jdk8-b08 for changeset de4794dd69c4 ! .hgtags Changeset: d21a4d5141c0 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d21a4d5141c0 Added tag jdk8-b09 for changeset 93554324c014 ! .hgtags Changeset: d1b7a4f6dd20 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d1b7a4f6dd20 Added tag jdk8-b10 for changeset d21a4d5141c0 ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:35:28 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:35:28 +0000 Subject: hg: hsx/hotspot-main/jaxws: 3 new changesets Message-ID: <20111023053528.BC5C4470D6@hg.openjdk.java.net> Changeset: 70172e57cf29 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/70172e57cf29 Added tag jdk8-b08 for changeset 1c9d4f59acf8 ! .hgtags Changeset: 8e7fdc8e3c75 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/8e7fdc8e3c75 Added tag jdk8-b09 for changeset 70172e57cf29 ! .hgtags Changeset: a12ab897a249 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/a12ab897a249 Added tag jdk8-b10 for changeset 8e7fdc8e3c75 ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:37:08 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:37:08 +0000 Subject: hg: hsx/hotspot-main/jdk: 68 new changesets Message-ID: <20111023054903.B508E470DF@hg.openjdk.java.net> Changeset: b92341e9ae56 Author: bae Date: 2011-09-19 05:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b92341e9ae56 7088287: libpng need to be updated. Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/LICENSE ! src/share/native/sun/awt/libpng/README ! src/share/native/sun/awt/libpng/png.c ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h + src/share/native/sun/awt/libpng/pngdebug.h ! src/share/native/sun/awt/libpng/pngerror.c - src/share/native/sun/awt/libpng/pnggccrd.c ! src/share/native/sun/awt/libpng/pngget.c + src/share/native/sun/awt/libpng/pnginfo.h + src/share/native/sun/awt/libpng/pnglibconf.h ! src/share/native/sun/awt/libpng/pngmem.c ! src/share/native/sun/awt/libpng/pngpread.c + src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngread.c ! src/share/native/sun/awt/libpng/pngrio.c ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/libpng/pngset.c + src/share/native/sun/awt/libpng/pngstruct.h ! src/share/native/sun/awt/libpng/pngtest.c ! src/share/native/sun/awt/libpng/pngtrans.c - src/share/native/sun/awt/libpng/pngvcrd.c ! src/share/native/sun/awt/libpng/pngwio.c ! src/share/native/sun/awt/libpng/pngwrite.c ! src/share/native/sun/awt/libpng/pngwtran.c ! src/share/native/sun/awt/libpng/pngwutil.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: bbf4e1faf859 Author: lana Date: 2011-09-23 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bbf4e1faf859 Merge Changeset: c662c8cf25d6 Author: lana Date: 2011-09-26 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c662c8cf25d6 Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3487d0d48662 Author: rupashka Date: 2011-09-15 16:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3487d0d48662 7090007: Missing style.css in nimbus/doc-files/properties.html Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html Changeset: 16c3dcad4252 Author: rupashka Date: 2011-09-21 17:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/16c3dcad4252 7032018: The file list in JFileChooser does not have an accessible name Reviewed-by: rupashka Contributed-by: Charles Lee ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/sun/swing/FilePane.java Changeset: 44040ece133c Author: lana Date: 2011-09-23 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44040ece133c Merge Changeset: 44f50834b79c Author: rupashka Date: 2011-09-26 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44f50834b79c 7088744: SwingUtilities.isMiddleMouseButton does not work with ALT/Meta keys Reviewed-by: alexp ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7088744/bug7088744.java Changeset: d72ac458b2b7 Author: anthony Date: 2011-09-26 17:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d72ac458b2b7 7081670: Disposing an AppContext can lead to a spinning EventDispatchThread Reviewed-by: art, anthony, dholmes Contributed-by: Clemens Eisserer ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java Changeset: 7fd192952459 Author: denis Date: 2011-09-26 18:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7fd192952459 7080289: AWTKeystroke class registers a subclass factory during deserialization Reviewed-by: serb ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: aac4041609bb Author: lana Date: 2011-09-26 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aac4041609bb Merge Changeset: e0c1282a0ead Author: coffeys Date: 2011-09-13 11:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e0c1282a0ead 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java + test/java/io/etc/FileDescriptorSharing.java Changeset: 04672e957da0 Author: mchung Date: 2011-09-14 08:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04672e957da0 6915797: Remove sun.tools.jar.JarImageSource that is not used 7090178: Move java.util.XMLUtils to another package to avoid split package Reviewed-by: alanb, sherman ! make/java/java/FILES_java.gmk ! make/sun/Makefile + make/sun/util/Makefile ! src/share/classes/java/util/Properties.java - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java + src/share/classes/sun/util/xml/XMLUtils.java Changeset: 2a8072c7cf99 Author: darcy Date: 2011-09-14 11:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2a8072c7cf99 6879143: java.math.BigInteger misses the xxxValueExact methods Reviewed-by: alanb ! src/share/classes/java/math/BigInteger.java + test/java/math/BigInteger/TestValueExact.java Changeset: 84da01e00e6c Author: darcy Date: 2011-09-14 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84da01e00e6c 7088500: there is no @since tag on SafeVarargs Reviewed-by: mduigou ! src/share/classes/java/lang/SafeVarargs.java Changeset: 52bc200b14e5 Author: mbankal Date: 2011-09-14 21:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/52bc200b14e5 7049963: DISTINGUISHED NAMES FOR CERT ARE ESCAPED IN JROCKIT 1.6(NOT COMPATIBLE WITH JROC Reviewed-by: mullan ! src/share/classes/sun/security/x509/AVA.java Changeset: 1260be51581f Author: mbankal Date: 2011-09-14 22:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1260be51581f Merge Changeset: f114bddac6d6 Author: peytoia Date: 2011-09-15 14:45 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f114bddac6d6 7090844: Support a timezone whose offset is changed more than once in the future Reviewed-by: okutsu ! make/tools/src/build/tools/javazic/Mappings.java Changeset: 5e403e9fa34a Author: peytoia Date: 2011-09-15 15:02 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5e403e9fa34a 7090843: (tz) Support tzdata2011j Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 9281d65f911a Author: michaelm Date: 2011-09-15 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9281d65f911a 7073491: -Dsun.net.maxDatagramSockets=1 does not work correctly with system.gc() Reviewed-by: ngmr ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java Changeset: 34fc7bbbb465 Author: michaelm Date: 2011-09-15 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/34fc7bbbb465 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 75d763111eec Author: chegar Date: 2011-09-16 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75d763111eec 7090158: Networking Libraries don't build with javac -Werror Summary: Minor changes to networking java files to remove warnings Reviewed-by: chegar, weijun, hawtin Contributed-by: kurchi.subhra.hazra at oracle.com, sasha_bu at hotmail.com ! make/com/sun/net/httpserver/Makefile ! make/com/sun/net/ssl/Makefile ! make/java/net/Makefile ! make/javax/Makefile ! make/javax/others/Makefile ! make/sun/net/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/SSLSecurity.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet4AddressImpl.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/Inet6AddressImpl.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/Proxy.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/net/TransferProtocolClient.java ! src/share/classes/sun/net/ftp/FtpClientProvider.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/idn/UCharacterEnums.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/share/classes/sun/net/www/HeaderParser.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/MimeTable.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/gopher/GopherClient.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/solaris/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/solaris/classes/java/net/PlainDatagramSocketImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: ccf2a19d7d87 Author: alanb Date: 2011-09-18 12:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ccf2a19d7d87 7091935: (fs) Polling based WatchService not used on Linux Reviewed-by: forax ! make/java/nio/Makefile Changeset: 418628a08ae7 Author: darcy Date: 2011-09-18 18:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/418628a08ae7 7091682: Move sun.misc.FpUtils code into java.lang.Math Reviewed-by: alanb ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ToHexString.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java Changeset: e3d78fe803d4 Author: michaelm Date: 2011-09-19 15:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e3d78fe803d4 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 Reviewed-by: chegar, alanb ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java Changeset: 8fe6d94683af Author: weijun Date: 2011-09-20 12:40 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8fe6d94683af 7091290: fails to build jdk8 b05 Embedded build Reviewed-by: xuelei, dholmes ! src/share/classes/org/ietf/jgss/Oid.java Changeset: c77b41652266 Author: mduigou Date: 2011-09-20 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c77b41652266 7074264: Switches to packages tree view and adds unit tests to sources Reviewed-by: igor ! make/netbeans/README ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/j2se/nbproject/project.xml Changeset: 9b2fc8a11421 Author: darcy Date: 2011-09-20 18:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b2fc8a11421 6268216: Boolean.getBoolean() throws SecurityException Reviewed-by: mduigou ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java Changeset: 029ba13aa0df Author: dcubed Date: 2011-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/029ba13aa0df 7085944: 3/3 FDS: gdb does not find debug symbols for libjsig link Summary: Add support for importing .debuginfo files from HSX. Reviewed-by: phh ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/redist/Makefile ! make/java/redist/sajdi/Makefile Changeset: d177eecda07e Author: dholmes Date: 2011-09-20 22:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d177eecda07e 7012206: ~20 tools tests failing due to -XX:-UsePerfData default in Java SE Embedded Summary: Explicitly enable UsePerfData for the tools that require it to be enabled Reviewed-by: alanb, ohair ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jps/jps-Defaults.sh ! test/sun/tools/jps/jps-V_2.sh ! test/sun/tools/jps/jps-Vm_2.sh ! test/sun/tools/jps/jps-Vvm.sh ! test/sun/tools/jps/jps-Vvml.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-help.sh ! test/sun/tools/jps/jps-l_1.sh ! test/sun/tools/jps/jps-l_2.sh ! test/sun/tools/jps/jps-lm.sh ! test/sun/tools/jps/jps-m.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jps/jps-q.sh ! test/sun/tools/jps/jps-v_1.sh ! test/sun/tools/jps/jps-vm_1.sh ! test/sun/tools/jstack/Basic.sh ! test/sun/tools/jstat/jstatClassOutput1.sh ! test/sun/tools/jstat/jstatClassloadOutput1.sh ! test/sun/tools/jstat/jstatCompilerOutput1.sh ! test/sun/tools/jstat/jstatFileURITest1.sh ! test/sun/tools/jstat/jstatGcCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcCauseOutput1.sh ! test/sun/tools/jstat/jstatGcNewCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcNewOutput1.sh ! test/sun/tools/jstat/jstatGcOldCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcOldOutput1.sh ! test/sun/tools/jstat/jstatGcOutput1.sh ! test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh ! test/sun/tools/jstat/jstatHelp.sh ! test/sun/tools/jstat/jstatLineCounts1.sh ! test/sun/tools/jstat/jstatLineCounts2.sh ! test/sun/tools/jstat/jstatLineCounts3.sh ! test/sun/tools/jstat/jstatLineCounts4.sh ! test/sun/tools/jstat/jstatOptions1.sh ! test/sun/tools/jstat/jstatPrintCompilationOutput1.sh ! test/sun/tools/jstat/jstatSnap1.sh ! test/sun/tools/jstat/jstatSnap2.sh ! test/sun/tools/jstat/jstatTimeStamp1.sh ! test/sun/tools/jstatd/jstatdDefaults.sh ! test/sun/tools/jstatd/jstatdExternalRegistry.sh ! test/sun/tools/jstatd/jstatdPort.sh ! test/sun/tools/jstatd/jstatdServerName.sh Changeset: 61a8c602cace Author: michaelm Date: 2011-09-21 14:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/61a8c602cace 7079012: test/java/net/NetworkInterface/NetParamsTest.java fails with SocketException getting mac address Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c ! test/ProblemList.txt Changeset: e7c2bf7d9d33 Author: michaelm Date: 2011-09-21 14:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7c2bf7d9d33 Merge Changeset: daf87c7be6a1 Author: weijun Date: 2011-09-22 12:05 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/daf87c7be6a1 7092627: use agentvm mode instead of samevm in regtests Reviewed-by: alanb, dsamersoff ! test/Makefile ! test/com/sun/jdi/sde/MangleStepTest.java ! test/java/util/logging/ParentLoggersTest.java Changeset: 6b6b6ee2afd9 Author: darcy Date: 2011-09-21 23:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6b6b6ee2afd9 7092404: Add Math.nextDown and Double.isFinite Reviewed-by: mduigou ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ParseHexFloatingPoint.java ! test/java/lang/Math/CeilAndFloorTests.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java Changeset: 8dab38c07b6b Author: dl Date: 2011-09-23 14:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8dab38c07b6b 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero Reviewed-by: dholmes, chegar ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java + test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCorePoolSize.java Changeset: 651a7afae763 Author: lana Date: 2011-09-23 23:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/651a7afae763 Merge Changeset: 2116952e4459 Author: weijun Date: 2011-09-26 17:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2116952e4459 7094842: test/javax/security/auth/Subject/{Synch.java,Synch2.java,Synch3.java} loop forever in agentvm mode Reviewed-by: alanb ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java Changeset: 8876d1dec4d7 Author: chegar Date: 2011-09-26 15:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8876d1dec4d7 7094141: test/sun/misc/JarIndex/metaInfFilenames/Basic.java no longer compiles Reviewed-by: alanb ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: 1c825eac6c04 Author: lana Date: 2011-09-26 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c825eac6c04 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: f38b39ed9ed0 Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f38b39ed9ed0 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 1c023bcd0c5a Author: jcoomes Date: 2011-10-04 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c023bcd0c5a Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: f1ec21b81421 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f1ec21b81421 Added tag jdk8-b08 for changeset 1c023bcd0c5a ! .hgtags Changeset: 7539cc99befe Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7539cc99befe Added tag jdk8-b09 for changeset f1ec21b81421 ! .hgtags Changeset: 1be72d104f9b Author: dbuck Date: 2011-09-26 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1be72d104f9b 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: cfe25bac6951 Author: bagiras Date: 2011-09-27 13:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cfe25bac6951 7073337: Crash after playing Java game on Pogo Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: fcdb588d77ef Author: rupashka Date: 2011-10-05 18:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fcdb588d77ef 7072167: The "root" field in BufferStrategyPaintManager leaks memory Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java Changeset: 98901d41e1e2 Author: rupashka Date: 2011-10-11 15:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98901d41e1e2 7076791: closed/javax/swing/JColorChooser/Test6827032.java failed on windows Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JColorChooser/Test6827032.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 58190ab77d2e Author: lana Date: 2011-10-12 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/58190ab77d2e Merge Changeset: 7f1aca641910 Author: chegar Date: 2011-09-26 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7f1aca641910 7084030: DatagramSocket.getLocalAddress inconsistent on XP/2003 when IPv6 enabled and socket is connected Summary: Use family of connected IP address to retrieve desired local address of the datagram socket Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c + test/java/net/DatagramSocket/ChangingAddress.java Changeset: 62e1389fdb0a Author: mullan Date: 2011-09-26 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/62e1389fdb0a 7088502: Security libraries don't build with javac -Werror Summary: Changes to files in src/share/classes/com/sun/org/apache/xml/internal/security and its subpackages to remove warnings Reviewed-by: mullan Contributed-by: kurchi.subhra.hazra at oracle.com ! make/com/sun/org/apache/xml/Makefile ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java Changeset: 79582fcc8329 Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/79582fcc8329 7089889: Krb5LoginModule.login() throws an exception if used without a keytab Reviewed-by: xuelei, valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java + test/sun/security/krb5/auto/NoInitNoKeytab.java Changeset: 9b951304bd0a Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b951304bd0a 7077640: gss wrap for cfx doesn't handle rrc != 0 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/RRC.java Changeset: 8d88e694441c Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d88e694441c 7077646: gssapi wrap for CFX per-message tokens always set FLAG_ACCEPTOR_SUBKEY Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java + test/sun/security/krb5/auto/AcceptorSubKey.java Changeset: 74f5fef1d961 Author: chegar Date: 2011-10-04 13:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/74f5fef1d961 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API Reviewed-by: chegar, mduigou Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/InMemoryCookieStore.java + test/java/net/CookieHandler/NullUriCookieTest.java Changeset: 24741fe639a8 Author: chegar Date: 2011-10-04 16:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/24741fe639a8 7095949: java/net/URLConnection/RedirectLimit.java and Redirect307Test fail intermittently Reviewed-by: alanb ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java Changeset: 2bc80ba6f4a4 Author: okutsu Date: 2011-10-05 15:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2bc80ba6f4a4 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11 6984762: Invalid close of file descriptor '-1' in findZoneinfoFile Reviewed-by: coffeys, ohair, naoto, peytoia ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/java/Makefile ! src/solaris/native/java/util/TimeZone_md.c Changeset: ff5e57dc1fb3 Author: chegar Date: 2011-10-06 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff5e57dc1fb3 7090499: missing rawtypes warnings in anonymous inner class Summary: Fix anonymous inner classes with raw types currently being built in the jdk with -Werror Reviewed-by: mcimadamore, alanb ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java Changeset: b8a1d30d6c65 Author: naoto Date: 2011-10-06 17:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8a1d30d6c65 7098394: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Reviewed-by: chegar ! src/solaris/native/java/util/TimeZone_md.c Changeset: 2edaef22de23 Author: vinnie Date: 2011-10-07 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2edaef22de23 7094377: Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Reviewed-by: chegar ! src/share/classes/com/sun/jndi/ldap/Connection.java + test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java Changeset: 1e89a13d9d8f Author: chegar Date: 2011-10-10 10:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1e89a13d9d8f 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Reviewed-by: michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java Changeset: 2a36b8741363 Author: chegar Date: 2011-10-10 15:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2a36b8741363 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Reviewed-by: mcimadamore ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: dd55467dd1f2 Author: ngmr Date: 2011-10-10 14:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd55467dd1f2 7099119: Remove unused dlinfo local variable in launcher code Reviewed-by: ohair, chegar, ngmr Contributed-by: Steve Poole ! src/solaris/bin/java_md.c Changeset: 5f336e0d4d97 Author: ngmr Date: 2011-10-10 16:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f336e0d4d97 Merge Changeset: 5bfe2de1157b Author: chegar Date: 2011-10-11 12:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bfe2de1157b 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Reviewed-by: coffeys ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java Changeset: ffa762153af4 Author: xuelei Date: 2011-09-28 15:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ffa762153af4 7092375: Security Libraries don't build with javac -Werror Summary: Changes to security related java and make files to remove warnings Reviewed-by: xuelei Contributed-by: kurchi.subhra.hazra at oracle.com ! make/java/security/Makefile ! make/javax/Makefile ! make/javax/others/Makefile + make/javax/security/Makefile ! make/org/ietf/jgss/Makefile ! make/sun/security/other/Makefile ! src/share/classes/java/security/Signature.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/CertificateParsingException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/x509/X509CertImpl.java Changeset: 829c3a8d23fa Author: naoto Date: 2011-10-12 12:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/829c3a8d23fa 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Reviewed-by: dholmes, chegar ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! test/java/util/Locale/Bug6989440.java Changeset: eac5d48a6c8e Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eac5d48a6c8e Merge Changeset: 4788745572ef Author: lana Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4788745572ef Merge Changeset: 7ab0d613cd1a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ab0d613cd1a Added tag jdk8-b10 for changeset 4788745572ef ! .hgtags From john.coomes at oracle.com Mon Oct 24 15:08:37 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 24 Oct 2011 22:08:37 +0000 Subject: hg: hsx/hotspot-main/langtools: 22 new changesets Message-ID: <20111024220926.D99CB47106@hg.openjdk.java.net> Changeset: ed338593b0b6 Author: mcimadamore Date: 2011-09-13 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ed338593b0b6 7086595: Error message bug: name of initializer is 'null' Summary: Implementation of MethodSymbol.location() should take into account static/instance initializers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/7086595/T7086595.java + test/tools/javac/7086595/T7086595.out ! test/tools/javac/Diagnostics/6860795/T6860795.out ! test/tools/javac/LocalClasses_2.out ! test/tools/javac/NestedInnerClassNames.out ! test/tools/javac/TryWithResources/BadTwr.out ! test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/diags/examples/AlreadyDefinedClinit.java + test/tools/javac/diags/examples/KindnameInstanceInit.java + test/tools/javac/diags/examples/KindnameStaticInit.java ! test/tools/javac/generics/6910550/T6910550d.out Changeset: f595d8bc0599 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f595d8bc0599 7003595: IncompatibleClassChangeError with unreferenced local class with subclass Summary: Compiler omits unreferenced local inner classes from the InnerClasses attribute Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/7003595/T7003595.java + test/tools/javac/7003595/T7003595b.java Changeset: 3a2200681d69 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3a2200681d69 7086601: Error message bug: cause for method mismatch is 'null' Summary: Inference error during lub() does not set 'cause' for method resolution diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IncompatibleUpperBounds.java + test/tools/javac/generics/inference/7086601/T7086601a.java + test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/generics/inference/7086601/T7086601b.java Changeset: ca2e2b85f437 Author: mchung Date: 2011-09-13 16:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ca2e2b85f437 7090297: Remove com.sun.tools.javac.Launcher from tools.jar Reviewed-by: jjg - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: 0f3da6af9799 Author: jjg Date: 2011-09-14 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0f3da6af9799 7080267: Call to toString() from an ExpressionStatementTree doesn't take in consideration the ";" at the end Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/TestToString.java Changeset: 1807fc3fd33c Author: jjg Date: 2011-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1807fc3fd33c 7090249: IllegalStateException from Trees.getScope when called from JSR 199 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/api/TestGetScope.java Changeset: a6e2c1840ea1 Author: jjg Date: 2011-09-14 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a6e2c1840ea1 7090700: fix for 7080267 breaks two tests Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/tree/JCTree.java Changeset: 826ae6a2f27d Author: jjg Date: 2011-09-14 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/826ae6a2f27d 7068437: Regression: Filer.getResource(SOURCE_OUTPUT, ...) no longer works in JDK 7 w/o -s Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java + test/tools/javac/file/T7068437.java Changeset: c0835c8489b0 Author: mcimadamore Date: 2011-09-16 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c0835c8489b0 7086586: Inference producing null type argument Summary: Inference should fail in 15.12.2.7 when inference variables with 'nulltype' upper bounds are found Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/generics/inference/6638712/T6638712a.out + test/tools/javac/generics/inference/7086586/T7086586.java + test/tools/javac/generics/inference/7086586/T7086586.out + test/tools/javac/generics/inference/7086586/T7086586b.java Changeset: dea82aa3ca4f Author: jjg Date: 2011-09-16 16:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dea82aa3ca4f 7091528: javadoc attempts to parse .class files Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java + test/tools/javadoc/parser/7091528/T7091528.java + test/tools/javadoc/parser/7091528/p/C1.java + test/tools/javadoc/parser/7091528/p/q/C2.java Changeset: ac964af3b5e7 Author: jjg Date: 2011-09-20 12:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ac964af3b5e7 7030473: Remove dead field JCCompilationUnit.flags Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/tree/JCTree.java Changeset: b0d5f00e69f7 Author: jjg Date: 2011-09-21 21:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b0d5f00e69f7 7092965: javac should not close processorClassLoader before end of compilation Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/processing/loader/testClose/TestClose.java + test/tools/javac/processing/loader/testClose/TestClose2.java Changeset: 497571d34112 Author: jjg Date: 2011-09-22 09:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/497571d34112 7075721: javac should have public enum for exit codes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java ! test/tools/javac/lib/CompileFail.java ! test/tools/javac/util/context/T7021650.java Changeset: 0c6f79fc8441 Author: lana Date: 2011-09-23 23:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0c6f79fc8441 Merge Changeset: 28573d605b01 Author: lana Date: 2011-09-26 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/28573d605b01 Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: e8acc2d6c32f Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e8acc2d6c32f Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: b7a7e47c8d3d Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b7a7e47c8d3d Added tag jdk8-b08 for changeset e8acc2d6c32f ! .hgtags Changeset: 510d09ddc861 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/510d09ddc861 Added tag jdk8-b09 for changeset b7a7e47c8d3d ! .hgtags Changeset: 47147081d5b4 Author: mcimadamore Date: 2011-10-06 18:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/47147081d5b4 7090499: missing rawtypes warnings in anonymous inner class Summary: javac does not detect raw types inside anonymous inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/warnings/7090499/T7090499.java + test/tools/javac/warnings/7090499/T7090499.out Changeset: 5010ffc61eda Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5010ffc61eda Merge Changeset: f6c783e18bdf Author: lana Date: 2011-10-17 19:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f6c783e18bdf Merge Changeset: 4bf01f1c4e34 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4bf01f1c4e34 Added tag jdk8-b10 for changeset f6c783e18bdf ! .hgtags From omajid at redhat.com Tue Oct 25 14:48:38 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 25 Oct 2011 17:48:38 -0400 Subject: identifier name clash between hotspot and glibc In-Reply-To: <2881FB4A-E82C-42C4-9874-537D7B0AF7BA@oracle.com> References: <4EA04019.20101@redhat.com> <4EA17D69.80903@redhat.com> <084D80C8-0C83-4759-8A6C-D69BA6696B0E@oracle.com> <4EA1E4A9.5090007@oracle.com> <2881FB4A-E82C-42C4-9874-537D7B0AF7BA@oracle.com> Message-ID: <4EA72EB6.9040700@redhat.com> On 10/21/2011 05:37 PM, Tom Rodriguez wrote: > Thanks, Omair and Vladimir. I'll go ahead and push this. > Thanks for pushing this through! Any idea if this fix might make it into OpenJDK 7u2? Thanks, Omair From tom.rodriguez at oracle.com Tue Oct 25 15:29:49 2011 From: tom.rodriguez at oracle.com (Thomas Rodriguez) Date: Tue, 25 Oct 2011 15:29:49 -0700 Subject: identifier name clash between hotspot and glibc In-Reply-To: <4EA72EB6.9040700@redhat.com> References: <4EA04019.20101@redhat.com> <4EA17D69.80903@redhat.com> <084D80C8-0C83-4759-8A6C-D69BA6696B0E@oracle.com> <4EA1E4A9.5090007@oracle.com> <2881FB4A-E82C-42C4-9874-537D7B0AF7BA@oracle.com> <4EA72EB6.9040700@redhat.com> Message-ID: <69C95A00-94A0-4B3B-A1D9-F43CABE75946@oracle.com> It definitely won't be in 7u2. That's closed except for showstoppers. It'll be in 7u4 though. Thanks! tom On Oct 25, 2011, at 2:48 PM, Omair Majid wrote: > On 10/21/2011 05:37 PM, Tom Rodriguez wrote: >> Thanks, Omair and Vladimir. I'll go ahead and push this. >> > > Thanks for pushing this through! Any idea if this fix might make it into OpenJDK 7u2? > > Thanks, > Omair From ahughes at redhat.com Wed Oct 26 15:49:59 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 26 Oct 2011 23:49:59 +0100 Subject: HotSpot development trees Message-ID: <20111026224959.GK594@rivendell.redhat.com> I see three HotSpot trees have appeared at hg.openjdk.java.net since I last imported one into OpenJDK6: hsx/hsx21/baseline and hsx/hsx21/master hsx/hsx22/hotspot hsx/hsx23/hotspot Which of these can be regarded as stable and can be integrated into OpenJDK6? The nomenclature also appears to have changed from baseline/master trees to just one called 'hotspot'. Why is this? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111026/0af20626/attachment.bin From david.holmes at oracle.com Wed Oct 26 19:35:11 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Oct 2011 12:35:11 +1000 Subject: HotSpot development trees In-Reply-To: <20111026224959.GK594@rivendell.redhat.com> References: <20111026224959.GK594@rivendell.redhat.com> Message-ID: <4EA8C35F.3010208@oracle.com> On 27/10/2011 8:49 AM, Dr Andrew John Hughes wrote: > I see three HotSpot trees have appeared at hg.openjdk.java.net since > I last imported one into OpenJDK6: > > hsx/hsx21/baseline and hsx/hsx21/master > hsx/hsx22/hotspot > hsx/hsx23/hotspot > > Which of these can be regarded as stable and can be integrated into > OpenJDK6? I think they are all "stable" (hs23 the least) but possibly the answer for OpenJDK6 is "none of the above". hs20.X is used in our currentJDK6 update train (and hs19.X for earlier updates) hs21 was jdk7 hs22 is 7u2 hs23 is current version for mainline and for next 7u after 7u2 (not sure why it's already forked off) > The nomenclature also appears to have changed from baseline/master > trees to just one called 'hotspot'. Why is this? The mainline tree is now hsx/hotspot-main, we then fork off hsx/hsxNN as needed. This started with hs22 IIRC. David > Thanks, From mlists at juma.me.uk Thu Oct 27 00:25:01 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 27 Oct 2011 07:25:01 +0000 (UTC) Subject: HotSpot development trees References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> Message-ID: David Holmes writes: > hs20.X is used in our currentJDK6 update train (and hs19.X for earlier > updates) > hs21 was jdk7 > hs22 is 7u2 > hs23 is current version for mainline and for next 7u after 7u2 (not sure > why it's already forked off) David, you probably know this, but for the benefit of others who may not, 7u2 is in phase 2 (aka stabilization) so the number of commits submitted there is small these days. Most of the backporting currently goes to 7u in general. Best, Ismael P.S. The above is based on my understanding from mails sent to 7u mailing list. From jencce2002 at gmail.com Thu Oct 27 06:41:12 2011 From: jencce2002 at gmail.com (jencce zhou) Date: Thu, 27 Oct 2011 21:41:12 +0800 Subject: openjdk6 on ia64 platform Message-ID: hi all , very sorry to bother you. bow :) I just wanna to know that : Does openjdk6 support ia64 platform ? thanks all~~ From rednaxelafx at gmail.com Thu Oct 27 06:54:26 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 27 Oct 2011 21:54:26 +0800 Subject: openjdk6 on ia64 platform In-Reply-To: References: Message-ID: Hi Jencce, I don't think IA-64 is directly supported by OpenJDK. There certainly is an IA-64 port in the closed source, but it's not released to OpenJDK. There's an old post on this list that mentions the IA-64 port. [1] If you really want to run OpenJDK on IA-64, the Zero version of HotSpot VM in OpenJDK should work for you. The IcedTea project should be a better place to find support for this, though. [2] Hope it helps, Kris Mok [1]: http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-June/000033.html [2]: http://en.wikipedia.org/wiki/IcedTea On Thu, Oct 27, 2011 at 9:41 PM, jencce zhou wrote: > hi all , very sorry to bother you. bow :) > > I just wanna to know that : Does openjdk6 support ia64 platform ? > > thanks all~~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111027/8451971c/attachment.html From fweimer at bfk.de Thu Oct 27 07:24:41 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 27 Oct 2011 14:24:41 +0000 Subject: openjdk6 on ia64 platform In-Reply-To: (jencce zhou's message of "Thu, 27 Oct 2011 21:41:12 +0800") References: Message-ID: <82sjmeseae.fsf@mid.bfk.de> * jencce zhou: > hi all , very sorry to bother you. bow :) > > I just wanna to know that : Does openjdk6 support ia64 platform ? Debian compiles OpenJDK packages for ia64. Looking at the test suite result, they work to some extent. I can't comment on performance. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From paul.hohensee at oracle.com Thu Oct 27 08:21:07 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 27 Oct 2011 11:21:07 -0400 Subject: HotSpot development trees In-Reply-To: <4EA8C35F.3010208@oracle.com> References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> Message-ID: <4EA976E3.3000704@oracle.com> Good summary, Dave. The mainline hotspot development train is tagged as hs23 because back in August we changed our process so that the hotspot major version number bump happens when we start development on a new major version rather than when we end it. That's so we can deliver the same version into multiple under-development JDK versions at the same time. Before August, we bumped the major version number each time we delivered into a new JDK, which can cause a nasty jam-up. hs23 is currently being promoted into both the jdk7u train and the jdk8 train on a (semi-)regular basis. Paul On 10/26/11 10:35 PM, David Holmes wrote: > On 27/10/2011 8:49 AM, Dr Andrew John Hughes wrote: >> I see three HotSpot trees have appeared at hg.openjdk.java.net since >> I last imported one into OpenJDK6: >> >> hsx/hsx21/baseline and hsx/hsx21/master >> hsx/hsx22/hotspot >> hsx/hsx23/hotspot >> >> Which of these can be regarded as stable and can be integrated into >> OpenJDK6? > > I think they are all "stable" (hs23 the least) but possibly the answer > for OpenJDK6 is "none of the above". > > hs20.X is used in our currentJDK6 update train (and hs19.X for earlier > updates) > hs21 was jdk7 > hs22 is 7u2 > hs23 is current version for mainline and for next 7u after 7u2 (not > sure why it's already forked off) > >> The nomenclature also appears to have changed from baseline/master >> trees to just one called 'hotspot'. Why is this? > > The mainline tree is now hsx/hotspot-main, we then fork off hsx/hsxNN > as needed. This started with hs22 IIRC. > > David > >> Thanks, From vladimir.kozlov at oracle.com Thu Oct 27 09:04:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Oct 2011 09:04:10 -0700 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA950A5.5020408@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> <4EA950A5.5020408@oracle.com> Message-ID: <4EA980FA.4000900@oracle.com> Bengt, Please, send to hotspot-dev alias only. I'm sending this mail there. You need to use cast to narrow type (size_t) in final compare in check_max_length_overflow() as I suggested before. Using reverse calculation will not catch integer overflow since all values are longs. > This actually changes the implementation for 64 bits. We will always use max_jint (even for double, long, etc) where we used to use an aligned value with the header subtracted. I think this is more correct, but is is different than before. Yes, it is different than before. But I don't think we should treat long[] and double[] differently (in 64 bit VM) than other types for which we return max_jint. > Also an alernative to your implementation would be: In general we prefer to avoid platform specific (64 bit) ifdefs. >> Is SIZE_MAX defined on all platforms? I am fine with SIZE_MAX if it passed JPRT (including embedded) as you said. If you can, please, verify if it exist in bsd and mac. May be Dan or Christian can help. > I see your point regarding the increased job times. But I think it is much clearer to have the internal unit tests as a separate target. That way they can be included and excluded with a JPRT command line. Did you measure the additional total time they added to JPRT job? If it is around 5 mins I am fine with it. Thanks, Vladimir On 10/27/11 5:37 AM, Bengt Rutisson wrote: > > Hi again, > > An updated webrev based on comments from Stefan and Vladimir > http://cr.openjdk.java.net/~brutisso/7102044/webrev.02/ > > Bengt > > On 2011-10-27 13:44, Bengt Rutisson wrote: >> >> Hi Vladimir, >> >> Thanks for looking at this change! >> >> On 2011-10-26 17:44, Vladimir Kozlov wrote: >>> Hi Bengt, >>> >>> I thought VM should throw OOM exception in such cases (as your example) since you can't allocate such arrays in >>> 32-bit VM. Does the size check for OOM happened after heap resize calculation? >> >> You are right. The VM will throw an OOME both before and after my change. But for different reasons. >> >> With my change we will detect already in typeArrayKlass::allocate_common() that length <= max_length() and throw an >> OOME. Before this change we could pass that test and go on in the allocation path. This would result in a size_t >> overflow when we want to expand the heap. We would do a lot of extra work to expand to the wrong size. Then the >> allocation would fail and we would throw OOME. >> >> I think it is better to detect this early and avoid the extra work. This way the assert that G1 does (which I think >> makes sense) will hold. We already have the length check so I assume that this was the intention from the beginning. >> >>> Is SIZE_MAX defined on all platforms? >> >> I did try to look around the hotspot code for any uses of max size_t but I could not find it. So, I reverted to >> looking at standard ways of doing it. SIZE_MAX seems to be defined on all our platforms, since my code passes JPRT. >> And it seems to be part of the C99 standard: >> >> http://en.wikipedia.org/wiki/Size_t >> >> I thought it would be better to rely on this than for example "(size_t)-1". But I am happy to use any other define. >> >>> You still have problem with short[] and char[] since 2*max_jint+header_size will overflow. >> >> Right. I did add some unit tests to catch this (but as you point out below those tests did not detect this overflow). >> Thanks for catching it. I will fix it and send out an updated webrev. >> >>> Also max_array_length() puts unneeded limitation on double[] and long[] max length in 64 but VM, it should be >>> max_jint. I think we can do something like next: >>> >>> const size_t max_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); >>> const size_t max_elements_per_size_t = HeapWordSize * max_words_per_size_t / type2aelembytes(type); >>> if ((size_t)max_jint < max_elements_per_size_t); >>> return max_jint ; >>> return (int32_t)max_elements_per_size_t; >> >> I did not intend for my change to limit anything for 64 bits. That's why I added the MIN2((size_t)max_jint, >> max_words_per_size_t) statement and included the old calculation in the unit tests to verify that nothing has changed >> on 64 bits. >> >> I can change the code as you suggest, but I would like to understand what the problem is with my code first. I think >> it handles 64 bits correctly. >> >>> check_overflow() should use julong type for expressions instead of size_t to catch overflow: >>> >>> +bool arrayOopDesc::check_overflow(BasicType type) { >>> + julong length = (julong)max_array_length(type); >>> + julong bytes_per_element = (julong)type2aelembytes(type); >>> + julong bytes = length * bytes_per_element + (julong)header_size_in_bytes(); >>> + return (julong)(size_t)bytes == bytes; >>> +} >> >> Right. This is why I didn't catch the problem above. Thanks. I'll fix. >> >>> Rename check_overflow() to check_max_length_overflow() or something. >> >> Done. >> >>> I don't think we need incorrect old_max_array_length() method and corresponding checks for LP64. >> >> Ok. I'll keep it for some more testing to make sure that I don't unintentionally change anything for 64 bit. But I'll >> remove it before I push. >> >>> Initialization and execution of additional JPRT tests will increase jobs time. I think you could add InternalVMTests >>> to existing client and server tests: >>> >>> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >>> --- >>> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >>> >> >> I see your point regarding the increased job times. But I think it is much clearer to have the internal unit tests as >> a separate target. That way they can be included and excluded with a JPRT command line. >> >> Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I would like to be more explicit about that this >> is only a (fast)debug build flag. >> >> Thanks, >> Bengt >> >>> regards, >>> Vladimir >>> >>> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Can I get a couple of reviews to this fairly small change? >>>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>>> >>>> Sorry for the wide distribution, but the bug is reported on GC, I think the actual change (in arrayOop.hpp) is runtime >>>> responsibility and the method that is being changed is used on a few occasions in C2. So, I figured I'd like >>>> everyone to >>>> know that this is about to go in. >>>> >>>> CR: >>>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>>> >>>> Background >>>> arrayOopDesc::max_array_length() returns the maximum length an array can have based on the type of the array elements. >>>> This is passed on through the allcocation path as a word size. When we need to expand the heap we have to convert the >>>> word size to a byte size. The problem is that on 32 bit platforms this conversion may overflow a size_t. Which will >>>> result in that we call expand() with a much smaller size than required size or even with a size of 0. >>>> >>>> Here is a small reproducer that will trigger the assert mentioned in the CR if we run it with -XX:+UseG1GC: >>>> >>>> public class LargeObj { >>>> public static void main(String[] args) { >>>> int[] a = new int[2147483639]; >>>> } >>>> } >>>> >>>> It is not only G1 that has this problem. ParallelGC has the same issue, it just doesn't have an assert to detect it. It >>>> can be argued that the GCs should check for overflows, but I think that since arrayOopDesc::max_array_length() will >>>> catch the problem earlier and solve it for all GCs this is a better place to fix the problem. >>>> >>>> I added some unit tests to test the new implementation. To make sure that these tests are run I had to update some more >>>> files. The actual change is in arrayOop.hpp. The rest of the files have just been changed to allow the unit tests to >>>> run. >>>> >>>> A few questions: >>>> >>>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that we don't overflow a size_t. This is only needed on >>>> 32 bit platforms. I prefer this general code compared to #ifndef _LP64. Any thoughts? >>>> >>>> (2) I made the unit tests run as JPRT make targets. I guess it can also be done as jtreg tests, but that way it would >>>> only be executed for PIT etc. Any thoughts on this? >>>> >>>> Thanks, >>>> Bengt >> > From bengt.rutisson at oracle.com Thu Oct 27 13:37:49 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 22:37:49 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA980FA.4000900@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> <4EA950A5.5020408@oracle.com> <4EA980FA.4000900@oracle.com> Message-ID: <4EA9C11D.7080408@oracle.com> Vladimir, On 2011-10-27 18:04, Vladimir Kozlov wrote: > Bengt, > > Please, send to hotspot-dev alias only. I'm sending this mail there. Ok. Thanks. > You need to use cast to narrow type (size_t) in final compare in > check_max_length_overflow() as I suggested before. Using reverse > calculation will not catch integer overflow since all values are longs. Done. Sorry I missed it first time around. > > This actually changes the implementation for 64 bits. We will always > use max_jint (even for double, long, etc) where we used to use an > aligned value with the header subtracted. I think this is more > correct, but is is different than before. > > Yes, it is different than before. But I don't think we should treat > long[] and double[] differently (in 64 bit VM) than other types for > which we return max_jint. > > > Also an alernative to your implementation would be: > > In general we prefer to avoid platform specific (64 bit) ifdefs. Agreed. I'll go with the calculation solution you suggested instead. > >> Is SIZE_MAX defined on all platforms? > > I am fine with SIZE_MAX if it passed JPRT (including embedded) as you > said. If you can, please, verify if it exist in bsd and mac. May be > Dan or Christian can help. I'll check with them. You mean Dan Daugherty and Christian Thalenger, right? > > I see your point regarding the increased job times. But I think it > is much clearer to have the internal unit tests as a separate target. > That way they can be included and excluded with a JPRT command line. > > Did you measure the additional total time they added to JPRT job? If > it is around 5 mins I am fine with it. Here is a run I did where I only run the internalvmtests target. Most of them take 1-2 minutes. windows_x64 takes 3.5 minutes. http://prt-web.us.oracle.com//archive/2011/10/2011-10-27-124029.brutisso.hs-gc-max-array-length//JobStatus.txt Thanks again for the review! Bengt > > Thanks, > Vladimir > > On 10/27/11 5:37 AM, Bengt Rutisson wrote: >> >> Hi again, >> >> An updated webrev based on comments from Stefan and Vladimir >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.02/ >> >> Bengt >> >> On 2011-10-27 13:44, Bengt Rutisson wrote: >>> >>> Hi Vladimir, >>> >>> Thanks for looking at this change! >>> >>> On 2011-10-26 17:44, Vladimir Kozlov wrote: >>>> Hi Bengt, >>>> >>>> I thought VM should throw OOM exception in such cases (as your >>>> example) since you can't allocate such arrays in >>>> 32-bit VM. Does the size check for OOM happened after heap resize >>>> calculation? >>> >>> You are right. The VM will throw an OOME both before and after my >>> change. But for different reasons. >>> >>> With my change we will detect already in >>> typeArrayKlass::allocate_common() that length <= max_length() and >>> throw an >>> OOME. Before this change we could pass that test and go on in the >>> allocation path. This would result in a size_t >>> overflow when we want to expand the heap. We would do a lot of extra >>> work to expand to the wrong size. Then the >>> allocation would fail and we would throw OOME. >>> >>> I think it is better to detect this early and avoid the extra work. >>> This way the assert that G1 does (which I think >>> makes sense) will hold. We already have the length check so I assume >>> that this was the intention from the beginning. >>> >>>> Is SIZE_MAX defined on all platforms? >>> >>> I did try to look around the hotspot code for any uses of max size_t >>> but I could not find it. So, I reverted to >>> looking at standard ways of doing it. SIZE_MAX seems to be defined >>> on all our platforms, since my code passes JPRT. >>> And it seems to be part of the C99 standard: >>> >>> http://en.wikipedia.org/wiki/Size_t >>> >>> I thought it would be better to rely on this than for example >>> "(size_t)-1". But I am happy to use any other define. >>> >>>> You still have problem with short[] and char[] since >>>> 2*max_jint+header_size will overflow. >>> >>> Right. I did add some unit tests to catch this (but as you point out >>> below those tests did not detect this overflow). >>> Thanks for catching it. I will fix it and send out an updated webrev. >>> >>>> Also max_array_length() puts unneeded limitation on double[] and >>>> long[] max length in 64 but VM, it should be >>>> max_jint. I think we can do something like next: >>>> >>>> const size_t max_words_per_size_t = >>>> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >>>> MinObjAlignment); >>>> const size_t max_elements_per_size_t = HeapWordSize * >>>> max_words_per_size_t / type2aelembytes(type); >>>> if ((size_t)max_jint < max_elements_per_size_t); >>>> return max_jint ; >>>> return (int32_t)max_elements_per_size_t; >>> >>> I did not intend for my change to limit anything for 64 bits. That's >>> why I added the MIN2((size_t)max_jint, >>> max_words_per_size_t) statement and included the old calculation in >>> the unit tests to verify that nothing has changed >>> on 64 bits. >>> >>> I can change the code as you suggest, but I would like to understand >>> what the problem is with my code first. I think >>> it handles 64 bits correctly. >>> >>>> check_overflow() should use julong type for expressions instead of >>>> size_t to catch overflow: >>>> >>>> +bool arrayOopDesc::check_overflow(BasicType type) { >>>> + julong length = (julong)max_array_length(type); >>>> + julong bytes_per_element = (julong)type2aelembytes(type); >>>> + julong bytes = length * bytes_per_element + >>>> (julong)header_size_in_bytes(); >>>> + return (julong)(size_t)bytes == bytes; >>>> +} >>> >>> Right. This is why I didn't catch the problem above. Thanks. I'll fix. >>> >>>> Rename check_overflow() to check_max_length_overflow() or something. >>> >>> Done. >>> >>>> I don't think we need incorrect old_max_array_length() method and >>>> corresponding checks for LP64. >>> >>> Ok. I'll keep it for some more testing to make sure that I don't >>> unintentionally change anything for 64 bit. But I'll >>> remove it before I push. >>> >>>> Initialization and execution of additional JPRT tests will increase >>>> jobs time. I think you could add InternalVMTests >>>> to existing client and server tests: >>>> >>>> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >>>> --- >>>> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >>>> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >>>> >>> >>> I see your point regarding the increased job times. But I think it >>> is much clearer to have the internal unit tests as >>> a separate target. That way they can be included and excluded with a >>> JPRT command line. >>> >>> Also, I don't really like the IgnoreUnrecognizedVMOptions solution. >>> I would like to be more explicit about that this >>> is only a (fast)debug build flag. >>> >>> Thanks, >>> Bengt >>> >>>> regards, >>>> Vladimir >>>> >>>> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Can I get a couple of reviews to this fairly small change? >>>>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>>>> >>>>> Sorry for the wide distribution, but the bug is reported on GC, I >>>>> think the actual change (in arrayOop.hpp) is runtime >>>>> responsibility and the method that is being changed is used on a >>>>> few occasions in C2. So, I figured I'd like >>>>> everyone to >>>>> know that this is about to go in. >>>>> >>>>> CR: >>>>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: >>>>> don't call this otherwise >>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>>>> >>>>> Background >>>>> arrayOopDesc::max_array_length() returns the maximum length an >>>>> array can have based on the type of the array elements. >>>>> This is passed on through the allcocation path as a word size. >>>>> When we need to expand the heap we have to convert the >>>>> word size to a byte size. The problem is that on 32 bit platforms >>>>> this conversion may overflow a size_t. Which will >>>>> result in that we call expand() with a much smaller size than >>>>> required size or even with a size of 0. >>>>> >>>>> Here is a small reproducer that will trigger the assert mentioned >>>>> in the CR if we run it with -XX:+UseG1GC: >>>>> >>>>> public class LargeObj { >>>>> public static void main(String[] args) { >>>>> int[] a = new int[2147483639]; >>>>> } >>>>> } >>>>> >>>>> It is not only G1 that has this problem. ParallelGC has the same >>>>> issue, it just doesn't have an assert to detect it. It >>>>> can be argued that the GCs should check for overflows, but I think >>>>> that since arrayOopDesc::max_array_length() will >>>>> catch the problem earlier and solve it for all GCs this is a >>>>> better place to fix the problem. >>>>> >>>>> I added some unit tests to test the new implementation. To make >>>>> sure that these tests are run I had to update some more >>>>> files. The actual change is in arrayOop.hpp. The rest of the files >>>>> have just been changed to allow the unit tests to >>>>> run. >>>>> >>>>> A few questions: >>>>> >>>>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure >>>>> that we don't overflow a size_t. This is only needed on >>>>> 32 bit platforms. I prefer this general code compared to #ifndef >>>>> _LP64. Any thoughts? >>>>> >>>>> (2) I made the unit tests run as JPRT make targets. I guess it can >>>>> also be done as jtreg tests, but that way it would >>>>> only be executed for PIT etc. Any thoughts on this? >>>>> >>>>> Thanks, >>>>> Bengt >>> >> From vladimir.kozlov at oracle.com Thu Oct 27 13:50:41 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Oct 2011 13:50:41 -0700 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA9C11D.7080408@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> <4EA950A5.5020408@oracle.com> <4EA980FA.4000900@oracle.com> <4EA9C11D.7080408@oracle.com> Message-ID: <4EA9C421.9000606@oracle.com> Bengt Rutisson wrote: >> I am fine with SIZE_MAX if it passed JPRT (including embedded) as you >> said. If you can, please, verify if it exist in bsd and mac. May be >> Dan or Christian can help. > > I'll check with them. You mean Dan Daugherty and Christian Thalenger, > right? Yes, them. >> Did you measure the additional total time they added to JPRT job? If >> it is around 5 mins I am fine with it. > > Here is a run I did where I only run the internalvmtests target. Most of > them take 1-2 minutes. windows_x64 takes 3.5 minutes. > http://prt-web.us.oracle.com//archive/2011/10/2011-10-27-124029.brutisso.hs-gc-max-array-length//JobStatus.txt Nice. Thanks, Vladimir > > > Thanks again for the review! > Bengt > >> >> Thanks, >> Vladimir >> >> On 10/27/11 5:37 AM, Bengt Rutisson wrote: >>> >>> Hi again, >>> >>> An updated webrev based on comments from Stefan and Vladimir >>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.02/ >>> >>> Bengt >>> >>> On 2011-10-27 13:44, Bengt Rutisson wrote: >>>> >>>> Hi Vladimir, >>>> >>>> Thanks for looking at this change! >>>> >>>> On 2011-10-26 17:44, Vladimir Kozlov wrote: >>>>> Hi Bengt, >>>>> >>>>> I thought VM should throw OOM exception in such cases (as your >>>>> example) since you can't allocate such arrays in >>>>> 32-bit VM. Does the size check for OOM happened after heap resize >>>>> calculation? >>>> >>>> You are right. The VM will throw an OOME both before and after my >>>> change. But for different reasons. >>>> >>>> With my change we will detect already in >>>> typeArrayKlass::allocate_common() that length <= max_length() and >>>> throw an >>>> OOME. Before this change we could pass that test and go on in the >>>> allocation path. This would result in a size_t >>>> overflow when we want to expand the heap. We would do a lot of extra >>>> work to expand to the wrong size. Then the >>>> allocation would fail and we would throw OOME. >>>> >>>> I think it is better to detect this early and avoid the extra work. >>>> This way the assert that G1 does (which I think >>>> makes sense) will hold. We already have the length check so I assume >>>> that this was the intention from the beginning. >>>> >>>>> Is SIZE_MAX defined on all platforms? >>>> >>>> I did try to look around the hotspot code for any uses of max size_t >>>> but I could not find it. So, I reverted to >>>> looking at standard ways of doing it. SIZE_MAX seems to be defined >>>> on all our platforms, since my code passes JPRT. >>>> And it seems to be part of the C99 standard: >>>> >>>> http://en.wikipedia.org/wiki/Size_t >>>> >>>> I thought it would be better to rely on this than for example >>>> "(size_t)-1". But I am happy to use any other define. >>>> >>>>> You still have problem with short[] and char[] since >>>>> 2*max_jint+header_size will overflow. >>>> >>>> Right. I did add some unit tests to catch this (but as you point out >>>> below those tests did not detect this overflow). >>>> Thanks for catching it. I will fix it and send out an updated webrev. >>>> >>>>> Also max_array_length() puts unneeded limitation on double[] and >>>>> long[] max length in 64 but VM, it should be >>>>> max_jint. I think we can do something like next: >>>>> >>>>> const size_t max_words_per_size_t = >>>>> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >>>>> MinObjAlignment); >>>>> const size_t max_elements_per_size_t = HeapWordSize * >>>>> max_words_per_size_t / type2aelembytes(type); >>>>> if ((size_t)max_jint < max_elements_per_size_t); >>>>> return max_jint ; >>>>> return (int32_t)max_elements_per_size_t; >>>> >>>> I did not intend for my change to limit anything for 64 bits. That's >>>> why I added the MIN2((size_t)max_jint, >>>> max_words_per_size_t) statement and included the old calculation in >>>> the unit tests to verify that nothing has changed >>>> on 64 bits. >>>> >>>> I can change the code as you suggest, but I would like to understand >>>> what the problem is with my code first. I think >>>> it handles 64 bits correctly. >>>> >>>>> check_overflow() should use julong type for expressions instead of >>>>> size_t to catch overflow: >>>>> >>>>> +bool arrayOopDesc::check_overflow(BasicType type) { >>>>> + julong length = (julong)max_array_length(type); >>>>> + julong bytes_per_element = (julong)type2aelembytes(type); >>>>> + julong bytes = length * bytes_per_element + >>>>> (julong)header_size_in_bytes(); >>>>> + return (julong)(size_t)bytes == bytes; >>>>> +} >>>> >>>> Right. This is why I didn't catch the problem above. Thanks. I'll fix. >>>> >>>>> Rename check_overflow() to check_max_length_overflow() or something. >>>> >>>> Done. >>>> >>>>> I don't think we need incorrect old_max_array_length() method and >>>>> corresponding checks for LP64. >>>> >>>> Ok. I'll keep it for some more testing to make sure that I don't >>>> unintentionally change anything for 64 bit. But I'll >>>> remove it before I push. >>>> >>>>> Initialization and execution of additional JPRT tests will increase >>>>> jobs time. I think you could add InternalVMTests >>>>> to existing client and server tests: >>>>> >>>>> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >>>>> --- >>>>> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >>>>> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >>>>> >>>> >>>> I see your point regarding the increased job times. But I think it >>>> is much clearer to have the internal unit tests as >>>> a separate target. That way they can be included and excluded with a >>>> JPRT command line. >>>> >>>> Also, I don't really like the IgnoreUnrecognizedVMOptions solution. >>>> I would like to be more explicit about that this >>>> is only a (fast)debug build flag. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> regards, >>>>> Vladimir >>>>> >>>>> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Can I get a couple of reviews to this fairly small change? >>>>>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>>>>> >>>>>> Sorry for the wide distribution, but the bug is reported on GC, I >>>>>> think the actual change (in arrayOop.hpp) is runtime >>>>>> responsibility and the method that is being changed is used on a >>>>>> few occasions in C2. So, I figured I'd like >>>>>> everyone to >>>>>> know that this is about to go in. >>>>>> >>>>>> CR: >>>>>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: >>>>>> don't call this otherwise >>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>>>>> >>>>>> Background >>>>>> arrayOopDesc::max_array_length() returns the maximum length an >>>>>> array can have based on the type of the array elements. >>>>>> This is passed on through the allcocation path as a word size. >>>>>> When we need to expand the heap we have to convert the >>>>>> word size to a byte size. The problem is that on 32 bit platforms >>>>>> this conversion may overflow a size_t. Which will >>>>>> result in that we call expand() with a much smaller size than >>>>>> required size or even with a size of 0. >>>>>> >>>>>> Here is a small reproducer that will trigger the assert mentioned >>>>>> in the CR if we run it with -XX:+UseG1GC: >>>>>> >>>>>> public class LargeObj { >>>>>> public static void main(String[] args) { >>>>>> int[] a = new int[2147483639]; >>>>>> } >>>>>> } >>>>>> >>>>>> It is not only G1 that has this problem. ParallelGC has the same >>>>>> issue, it just doesn't have an assert to detect it. It >>>>>> can be argued that the GCs should check for overflows, but I think >>>>>> that since arrayOopDesc::max_array_length() will >>>>>> catch the problem earlier and solve it for all GCs this is a >>>>>> better place to fix the problem. >>>>>> >>>>>> I added some unit tests to test the new implementation. To make >>>>>> sure that these tests are run I had to update some more >>>>>> files. The actual change is in arrayOop.hpp. The rest of the files >>>>>> have just been changed to allow the unit tests to >>>>>> run. >>>>>> >>>>>> A few questions: >>>>>> >>>>>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure >>>>>> that we don't overflow a size_t. This is only needed on >>>>>> 32 bit platforms. I prefer this general code compared to #ifndef >>>>>> _LP64. Any thoughts? >>>>>> >>>>>> (2) I made the unit tests run as JPRT make targets. I guess it can >>>>>> also be done as jtreg tests, but that way it would >>>>>> only be executed for PIT etc. Any thoughts on this? >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >>> > From trims at netdemons.com Thu Oct 27 17:37:35 2011 From: trims at netdemons.com (Erik Trimble) Date: Thu, 27 Oct 2011 17:37:35 -0700 Subject: HotSpot development trees In-Reply-To: <4EA976E3.3000704@oracle.com> References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> Message-ID: <4EA9F94F.3030707@netdemons.com> Back to Andrew's question: The best HSX candidate repository for OpenJDK6 to use is N-1, where N is the largest one you see. In theory, that repo should be fully stabilized. The hsxN repo is current undergoing stabilization, and the hsx/hotspot-main is undergoing active development. -Erik On 10/27/2011 8:21 AM, Paul Hohensee wrote: > Good summary, Dave. > > The mainline hotspot development train is tagged as hs23 because back > in August > we changed our process so that the hotspot major version number bump > happens > when we start development on a new major version rather than when we > end it. > That's so we can deliver the same version into multiple under-development > JDK versions at the same time. Before August, we bumped the major > version > number each time we delivered into a new JDK, which can cause a nasty > jam-up. > > hs23 is currently being promoted into both the jdk7u train and the > jdk8 train > on a (semi-)regular basis. > > Paul > > On 10/26/11 10:35 PM, David Holmes wrote: >> On 27/10/2011 8:49 AM, Dr Andrew John Hughes wrote: >>> I see three HotSpot trees have appeared at hg.openjdk.java.net since >>> I last imported one into OpenJDK6: >>> >>> hsx/hsx21/baseline and hsx/hsx21/master >>> hsx/hsx22/hotspot >>> hsx/hsx23/hotspot >>> >>> Which of these can be regarded as stable and can be integrated into >>> OpenJDK6? >> >> I think they are all "stable" (hs23 the least) but possibly the >> answer for OpenJDK6 is "none of the above". >> >> hs20.X is used in our currentJDK6 update train (and hs19.X for >> earlier updates) >> hs21 was jdk7 >> hs22 is 7u2 >> hs23 is current version for mainline and for next 7u after 7u2 (not >> sure why it's already forked off) >> >>> The nomenclature also appears to have changed from baseline/master >>> trees to just one called 'hotspot'. Why is this? >> >> The mainline tree is now hsx/hotspot-main, we then fork off hsx/hsxNN >> as needed. This started with hs22 IIRC. >> >> David >> >>> Thanks, From jencce2002 at gmail.com Thu Oct 27 18:20:53 2011 From: jencce2002 at gmail.com (jencce zhou) Date: Fri, 28 Oct 2011 09:20:53 +0800 Subject: openjdk6 on ia64 platform In-Reply-To: References: Message-ID: Hi Kris, thanks very much! jencce 2011/10/27 Krystal Mok : > Hi Jencce, > I don't think IA-64 is directly supported by OpenJDK. There certainly is an > IA-64 port in the closed source, but it's not released to OpenJDK.?There's > an old post on this list that mentions the IA-64 port. [1] > If you really want to run OpenJDK on IA-64, the Zero version of HotSpot VM > in OpenJDK should work for you. The IcedTea project should be a better place > to find support for this, though. [2] > Hope it helps, > Kris Mok > > [1]:?http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-June/000033.html > [2]:?http://en.wikipedia.org/wiki/IcedTea > > On Thu, Oct 27, 2011 at 9:41 PM, jencce zhou wrote: >> >> hi all , very sorry to bother you. bow :) >> >> I just wanna to know that : Does openjdk6 support ia64 platform ? >> >> thanks all~~ > > From jencce2002 at gmail.com Thu Oct 27 18:21:58 2011 From: jencce2002 at gmail.com (jencce zhou) Date: Fri, 28 Oct 2011 09:21:58 +0800 Subject: openjdk6 on ia64 platform In-Reply-To: <82sjmeseae.fsf@mid.bfk.de> References: <82sjmeseae.fsf@mid.bfk.de> Message-ID: Hi , Florian thank you very much~~ jencce 2011/10/27 Florian Weimer : > * jencce zhou: > >> hi all , very sorry to bother you. bow :) >> >> I just wanna to know that : Does openjdk6 support ia64 platform ? > > Debian compiles OpenJDK packages for ia64. ?Looking at the test suite > result, they work to some extent. ?I can't comment on performance. > > -- > Florian Weimer ? ? ? ? ? ? ? ? > BFK edv-consulting GmbH ? ? ? http://www.bfk.de/ > Kriegsstra?e 100 ? ? ? ? ? ? ?tel: +49-721-96201-1 > D-76133 Karlsruhe ? ? ? ? ? ? fax: +49-721-96201-99 > From david.holmes at oracle.com Thu Oct 27 20:00:58 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Oct 2011 13:00:58 +1000 Subject: HotSpot development trees In-Reply-To: <4EA9F94F.3030707@netdemons.com> References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> Message-ID: <4EAA1AEA.2060505@oracle.com> On 28/10/2011 10:37 AM, Erik Trimble wrote: > Back to Andrew's question: > > The best HSX candidate repository for OpenJDK6 to use is N-1, where N is > the largest one you see. In theory, that repo should be fully > stabilized. The hsxN repo is current undergoing stabilization, and the > hsx/hotspot-main is undergoing active development. There is no guarantee that hs21+ will work with OpenJDK6 David > -Erik > > > On 10/27/2011 8:21 AM, Paul Hohensee wrote: >> Good summary, Dave. >> >> The mainline hotspot development train is tagged as hs23 because back >> in August >> we changed our process so that the hotspot major version number bump >> happens >> when we start development on a new major version rather than when we >> end it. >> That's so we can deliver the same version into multiple under-development >> JDK versions at the same time. Before August, we bumped the major version >> number each time we delivered into a new JDK, which can cause a nasty >> jam-up. >> >> hs23 is currently being promoted into both the jdk7u train and the >> jdk8 train >> on a (semi-)regular basis. >> >> Paul >> >> On 10/26/11 10:35 PM, David Holmes wrote: >>> On 27/10/2011 8:49 AM, Dr Andrew John Hughes wrote: >>>> I see three HotSpot trees have appeared at hg.openjdk.java.net since >>>> I last imported one into OpenJDK6: >>>> >>>> hsx/hsx21/baseline and hsx/hsx21/master >>>> hsx/hsx22/hotspot >>>> hsx/hsx23/hotspot >>>> >>>> Which of these can be regarded as stable and can be integrated into >>>> OpenJDK6? >>> >>> I think they are all "stable" (hs23 the least) but possibly the >>> answer for OpenJDK6 is "none of the above". >>> >>> hs20.X is used in our currentJDK6 update train (and hs19.X for >>> earlier updates) >>> hs21 was jdk7 >>> hs22 is 7u2 >>> hs23 is current version for mainline and for next 7u after 7u2 (not >>> sure why it's already forked off) >>> >>>> The nomenclature also appears to have changed from baseline/master >>>> trees to just one called 'hotspot'. Why is this? >>> >>> The mainline tree is now hsx/hotspot-main, we then fork off hsx/hsxNN >>> as needed. This started with hs22 IIRC. >>> >>> David >>> >>>> Thanks, > From john.coomes at oracle.com Thu Oct 27 20:34:51 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:34:51 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b11 for changeset 1defbc57940a Message-ID: <20111028033452.040984718C@hg.openjdk.java.net> Changeset: 8e2104d565ba Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8e2104d565ba Added tag jdk8-b11 for changeset 1defbc57940a ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:35:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:35:00 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b11 for changeset 0199e4fef5cc Message-ID: <20111028033503.34D884718D@hg.openjdk.java.net> Changeset: 31d70911b712 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/31d70911b712 Added tag jdk8-b11 for changeset 0199e4fef5cc ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:35:12 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:35:12 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b11 for changeset d1b7a4f6dd20 Message-ID: <20111028033512.433734718E@hg.openjdk.java.net> Changeset: ca977d167697 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ca977d167697 Added tag jdk8-b11 for changeset d1b7a4f6dd20 ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:35:21 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:35:21 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b11 for changeset a12ab897a249 Message-ID: <20111028033521.7D20B4718F@hg.openjdk.java.net> Changeset: e6eed2ff5d5f Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/e6eed2ff5d5f Added tag jdk8-b11 for changeset a12ab897a249 ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:35:33 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:35:33 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b11 for changeset 7ab0d613cd1a Message-ID: <20111028033609.C8B9F47190@hg.openjdk.java.net> Changeset: e1f4b4b4b96e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e1f4b4b4b96e Added tag jdk8-b11 for changeset 7ab0d613cd1a ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:36:19 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:36:19 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b11 for changeset 4bf01f1c4e34 Message-ID: <20111028033624.ED41347191@hg.openjdk.java.net> Changeset: 8ff85191a7ac Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8ff85191a7ac Added tag jdk8-b11 for changeset 4bf01f1c4e34 ! .hgtags From david.holmes at oracle.com Thu Oct 27 23:53:53 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Oct 2011 16:53:53 +1000 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA950A5.5020408@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> <4EA950A5.5020408@oracle.com> Message-ID: <4EAA5181.5070201@oracle.com> Hi Bengt, On 27/10/2011 10:37 PM, Bengt Rutisson wrote: > > Hi again, > > An updated webrev based on comments from Stefan and Vladimir > http://cr.openjdk.java.net/~brutisso/7102044/webrev.02/ It took me a little while to get my head around the calculations here. I think this: 113 const size_t max_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); 114 const size_t max_elements_per_size_t = HeapWordSize * max_words_per_size_t / type2aelembytes(type); 115 if ((size_t)max_jint < max_elements_per_size_t) { 116 return max_jint; 117 } 118 return (int32_t)max_elements_per_size_t; would be a little clearer if that first variable was called max_element_words_per_size_t in the style of the original code. 121 // for unit testing 122 #ifndef PRODUCT 123 static bool check_max_length_overflow(BasicType type); 124 static int32_t old_max_array_length(BasicType type); 125 static bool test_max_array_length(); 126 #endif After 6 years on Hotspot I was not aware of the existence of ExecuteInternalVMTests. :) I wonder when that existing quickSort test was last run? That said does this really warrant these internal tests over a simple assert in the function itself? test/Makefile With regard to only executing the tests for debug/fastdebug, I think JPRT may set JPRT_BUILD_FLAVOR which you could then check for the presence of "debug". I'm not certain - it might only do that when building, not when running the tests. Cheers, David > Bengt > > On 2011-10-27 13:44, Bengt Rutisson wrote: >> >> Hi Vladimir, >> >> Thanks for looking at this change! >> >> On 2011-10-26 17:44, Vladimir Kozlov wrote: >>> Hi Bengt, >>> >>> I thought VM should throw OOM exception in such cases (as your >>> example) since you can't allocate such arrays in 32-bit VM. Does the >>> size check for OOM happened after heap resize calculation? >> >> You are right. The VM will throw an OOME both before and after my >> change. But for different reasons. >> >> With my change we will detect already in >> typeArrayKlass::allocate_common() that length <= max_length() and >> throw an OOME. Before this change we could pass that test and go on in >> the allocation path. This would result in a size_t overflow when we >> want to expand the heap. We would do a lot of extra work to expand to >> the wrong size. Then the allocation would fail and we would throw OOME. >> >> I think it is better to detect this early and avoid the extra work. >> This way the assert that G1 does (which I think makes sense) will >> hold. We already have the length check so I assume that this was the >> intention from the beginning. >> >>> Is SIZE_MAX defined on all platforms? >> >> I did try to look around the hotspot code for any uses of max size_t >> but I could not find it. So, I reverted to looking at standard ways of >> doing it. SIZE_MAX seems to be defined on all our platforms, since my >> code passes JPRT. And it seems to be part of the C99 standard: >> >> http://en.wikipedia.org/wiki/Size_t >> >> I thought it would be better to rely on this than for example >> "(size_t)-1". But I am happy to use any other define. >> >>> You still have problem with short[] and char[] since >>> 2*max_jint+header_size will overflow. >> >> Right. I did add some unit tests to catch this (but as you point out >> below those tests did not detect this overflow). Thanks for catching >> it. I will fix it and send out an updated webrev. >> >>> Also max_array_length() puts unneeded limitation on double[] and >>> long[] max length in 64 but VM, it should be max_jint. I think we can >>> do something like next: >>> >>> const size_t max_words_per_size_t = >>> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >>> MinObjAlignment); >>> const size_t max_elements_per_size_t = HeapWordSize * >>> max_words_per_size_t / type2aelembytes(type); >>> if ((size_t)max_jint < max_elements_per_size_t); >>> return max_jint ; >>> return (int32_t)max_elements_per_size_t; >> >> I did not intend for my change to limit anything for 64 bits. That's >> why I added the MIN2((size_t)max_jint, max_words_per_size_t) statement >> and included the old calculation in the unit tests to verify that >> nothing has changed on 64 bits. >> >> I can change the code as you suggest, but I would like to understand >> what the problem is with my code first. I think it handles 64 bits >> correctly. >> >>> check_overflow() should use julong type for expressions instead of >>> size_t to catch overflow: >>> >>> +bool arrayOopDesc::check_overflow(BasicType type) { >>> + julong length = (julong)max_array_length(type); >>> + julong bytes_per_element = (julong)type2aelembytes(type); >>> + julong bytes = length * bytes_per_element + >>> (julong)header_size_in_bytes(); >>> + return (julong)(size_t)bytes == bytes; >>> +} >> >> Right. This is why I didn't catch the problem above. Thanks. I'll fix. >> >>> Rename check_overflow() to check_max_length_overflow() or something. >> >> Done. >> >>> I don't think we need incorrect old_max_array_length() method and >>> corresponding checks for LP64. >> >> Ok. I'll keep it for some more testing to make sure that I don't >> unintentionally change anything for 64 bit. But I'll remove it before >> I push. >> >>> Initialization and execution of additional JPRT tests will increase >>> jobs time. I think you could add InternalVMTests to existing client >>> and server tests: >>> >>> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >>> --- >>> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >>> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >>> >> >> I see your point regarding the increased job times. But I think it is >> much clearer to have the internal unit tests as a separate target. >> That way they can be included and excluded with a JPRT command line. >> >> Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I >> would like to be more explicit about that this is only a (fast)debug >> build flag. >> >> Thanks, >> Bengt >> >>> regards, >>> Vladimir >>> >>> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Can I get a couple of reviews to this fairly small change? >>>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>>> >>>> Sorry for the wide distribution, but the bug is reported on GC, I >>>> think the actual change (in arrayOop.hpp) is runtime >>>> responsibility and the method that is being changed is used on a few >>>> occasions in C2. So, I figured I'd like everyone to >>>> know that this is about to go in. >>>> >>>> CR: >>>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >>>> call this otherwise >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>>> >>>> Background >>>> arrayOopDesc::max_array_length() returns the maximum length an array >>>> can have based on the type of the array elements. >>>> This is passed on through the allcocation path as a word size. When >>>> we need to expand the heap we have to convert the >>>> word size to a byte size. The problem is that on 32 bit platforms >>>> this conversion may overflow a size_t. Which will >>>> result in that we call expand() with a much smaller size than >>>> required size or even with a size of 0. >>>> >>>> Here is a small reproducer that will trigger the assert mentioned in >>>> the CR if we run it with -XX:+UseG1GC: >>>> >>>> public class LargeObj { >>>> public static void main(String[] args) { >>>> int[] a = new int[2147483639]; >>>> } >>>> } >>>> >>>> It is not only G1 that has this problem. ParallelGC has the same >>>> issue, it just doesn't have an assert to detect it. It >>>> can be argued that the GCs should check for overflows, but I think >>>> that since arrayOopDesc::max_array_length() will >>>> catch the problem earlier and solve it for all GCs this is a better >>>> place to fix the problem. >>>> >>>> I added some unit tests to test the new implementation. To make sure >>>> that these tests are run I had to update some more >>>> files. The actual change is in arrayOop.hpp. The rest of the files >>>> have just been changed to allow the unit tests to run. >>>> >>>> A few questions: >>>> >>>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >>>> we don't overflow a size_t. This is only needed on >>>> 32 bit platforms. I prefer this general code compared to #ifndef >>>> _LP64. Any thoughts? >>>> >>>> (2) I made the unit tests run as JPRT make targets. I guess it can >>>> also be done as jtreg tests, but that way it would >>>> only be executed for PIT etc. Any thoughts on this? >>>> >>>> Thanks, >>>> Bengt >> > From rednaxelafx at gmail.com Thu Oct 27 23:58:57 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 28 Oct 2011 14:58:57 +0800 Subject: HotSpot development trees In-Reply-To: <4EAA1AEA.2060505@oracle.com> References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> <4EAA1AEA.2060505@oracle.com> Message-ID: Hi all, HS21 introduced quite a few behavioral changes that OpenJDK 6 users might not be expecting. One of them would be the progress of PermGen removal, which affects some tuning. It might still be pretty much compatible, but no one has been testing for JDK6/HS21 compatibility, right? >From what we can see from the outside, recent JDK 6 releases from Oracle are staying on HotSpot 20.x, with some bug fixes applied. My question is: Are there any plans from Oracle/OpenJDK to release further updates to OpenJDK 6, with the bug fixes applied to HotSpot Express 20's master repo? Or, could there be a list of recommended list of bug fixes/patches that should be backported to HS20? We're stuck on JDK 6 now, with no plans to move to JDK 7 in the near future, our work would have to base on HS20. So backporting bugfixes to HS20 is kind of like "scratching my own itch". If there's anything outside contributors can do about this, I'm more than willing to help. Regards, Kris Mok Software Engineer Taobao (http://www.taobao.com) On Fri, Oct 28, 2011 at 11:00 AM, David Holmes wrote: > On 28/10/2011 10:37 AM, Erik Trimble wrote: > >> Back to Andrew's question: >> >> The best HSX candidate repository for OpenJDK6 to use is N-1, where N is >> the largest one you see. In theory, that repo should be fully >> stabilized. The hsxN repo is current undergoing stabilization, and the >> hsx/hotspot-main is undergoing active development. >> > > There is no guarantee that hs21+ will work with OpenJDK6 > > David > > > -Erik >> >> >> On 10/27/2011 8:21 AM, Paul Hohensee wrote: >> >>> Good summary, Dave. >>> >>> The mainline hotspot development train is tagged as hs23 because back >>> in August >>> we changed our process so that the hotspot major version number bump >>> happens >>> when we start development on a new major version rather than when we >>> end it. >>> That's so we can deliver the same version into multiple under-development >>> JDK versions at the same time. Before August, we bumped the major version >>> number each time we delivered into a new JDK, which can cause a nasty >>> jam-up. >>> >>> hs23 is currently being promoted into both the jdk7u train and the >>> jdk8 train >>> on a (semi-)regular basis. >>> >>> Paul >>> >>> On 10/26/11 10:35 PM, David Holmes wrote: >>> >>>> On 27/10/2011 8:49 AM, Dr Andrew John Hughes wrote: >>>> >>>>> I see three HotSpot trees have appeared at hg.openjdk.java.net since >>>>> I last imported one into OpenJDK6: >>>>> >>>>> hsx/hsx21/baseline and hsx/hsx21/master >>>>> hsx/hsx22/hotspot >>>>> hsx/hsx23/hotspot >>>>> >>>>> Which of these can be regarded as stable and can be integrated into >>>>> OpenJDK6? >>>>> >>>> >>>> I think they are all "stable" (hs23 the least) but possibly the >>>> answer for OpenJDK6 is "none of the above". >>>> >>>> hs20.X is used in our currentJDK6 update train (and hs19.X for >>>> earlier updates) >>>> hs21 was jdk7 >>>> hs22 is 7u2 >>>> hs23 is current version for mainline and for next 7u after 7u2 (not >>>> sure why it's already forked off) >>>> >>>> The nomenclature also appears to have changed from baseline/master >>>>> trees to just one called 'hotspot'. Why is this? >>>>> >>>> >>>> The mainline tree is now hsx/hotspot-main, we then fork off hsx/hsxNN >>>> as needed. This started with hs22 IIRC. >>>> >>>> David >>>> >>>> Thanks, >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111028/990b48ed/attachment.html From bengt.rutisson at oracle.com Fri Oct 28 00:06:16 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 28 Oct 2011 09:06:16 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EAA5181.5070201@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> <4EA950A5.5020408@oracle.com> <4EAA5181.5070201@oracle.com> Message-ID: <4EAA5468.2010800@oracle.com> Hi David, Thanks for looking at this! On 2011-10-28 08:53, David Holmes wrote: > Hi Bengt, > > On 27/10/2011 10:37 PM, Bengt Rutisson wrote: >> >> Hi again, >> >> An updated webrev based on comments from Stefan and Vladimir >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.02/ > > It took me a little while to get my head around the calculations here. > I think this: > > 113 const size_t max_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > 114 const size_t max_elements_per_size_t = HeapWordSize * > max_words_per_size_t / type2aelembytes(type); > 115 if ((size_t)max_jint < max_elements_per_size_t) { > 116 return max_jint; > 117 } > 118 return (int32_t)max_elements_per_size_t; > > would be a little clearer if that first variable was called > max_element_words_per_size_t in the style of the original code. Sure. I'll fix that. > 121 // for unit testing > 122 #ifndef PRODUCT > 123 static bool check_max_length_overflow(BasicType type); > 124 static int32_t old_max_array_length(BasicType type); > 125 static bool test_max_array_length(); > 126 #endif > > After 6 years on Hotspot I was not aware of the existence of > ExecuteInternalVMTests. :) I wonder when that existing quickSort test > was last run? That said does this really warrant these internal tests > over a simple assert in the function itself? Actually I added the ExecuteInternalVMTests earlier this summer when I was adding the quickSort implementation. But at the time I was not sure what the best way to get them run automatically was. Now that I wanted to add more unit tests I thought I'd make sure they are run and asked around for how to do it. > That said does this really warrant these internal tests over a simple > assert in the function itself? I think so, since these are very statical calculations. There is really no need to execute an assert (in debug builds) every time we do the calculations. I prefer to have this as a separate test. That also makes it more obvious that all types are tested. > test/Makefile > > With regard to only executing the tests for debug/fastdebug, I think > JPRT may set JPRT_BUILD_FLAVOR which you could then check for the > presence of "debug". I'm not certain - it might only do that when > building, not when running the tests. Not quite sure how you mean that I can make use of JPRT_BUILD_FLAVOR. Did you mean that I could avoid having a separate build target if I could check whether or not it is a debug build and then piggy back the test execution on the server or client targets? Thanks, Bengt > > Cheers, > David > >> Bengt >> >> On 2011-10-27 13:44, Bengt Rutisson wrote: >>> >>> Hi Vladimir, >>> >>> Thanks for looking at this change! >>> >>> On 2011-10-26 17:44, Vladimir Kozlov wrote: >>>> Hi Bengt, >>>> >>>> I thought VM should throw OOM exception in such cases (as your >>>> example) since you can't allocate such arrays in 32-bit VM. Does the >>>> size check for OOM happened after heap resize calculation? >>> >>> You are right. The VM will throw an OOME both before and after my >>> change. But for different reasons. >>> >>> With my change we will detect already in >>> typeArrayKlass::allocate_common() that length <= max_length() and >>> throw an OOME. Before this change we could pass that test and go on in >>> the allocation path. This would result in a size_t overflow when we >>> want to expand the heap. We would do a lot of extra work to expand to >>> the wrong size. Then the allocation would fail and we would throw OOME. >>> >>> I think it is better to detect this early and avoid the extra work. >>> This way the assert that G1 does (which I think makes sense) will >>> hold. We already have the length check so I assume that this was the >>> intention from the beginning. >>> >>>> Is SIZE_MAX defined on all platforms? >>> >>> I did try to look around the hotspot code for any uses of max size_t >>> but I could not find it. So, I reverted to looking at standard ways of >>> doing it. SIZE_MAX seems to be defined on all our platforms, since my >>> code passes JPRT. And it seems to be part of the C99 standard: >>> >>> http://en.wikipedia.org/wiki/Size_t >>> >>> I thought it would be better to rely on this than for example >>> "(size_t)-1". But I am happy to use any other define. >>> >>>> You still have problem with short[] and char[] since >>>> 2*max_jint+header_size will overflow. >>> >>> Right. I did add some unit tests to catch this (but as you point out >>> below those tests did not detect this overflow). Thanks for catching >>> it. I will fix it and send out an updated webrev. >>> >>>> Also max_array_length() puts unneeded limitation on double[] and >>>> long[] max length in 64 but VM, it should be max_jint. I think we can >>>> do something like next: >>>> >>>> const size_t max_words_per_size_t = >>>> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >>>> MinObjAlignment); >>>> const size_t max_elements_per_size_t = HeapWordSize * >>>> max_words_per_size_t / type2aelembytes(type); >>>> if ((size_t)max_jint < max_elements_per_size_t); >>>> return max_jint ; >>>> return (int32_t)max_elements_per_size_t; >>> >>> I did not intend for my change to limit anything for 64 bits. That's >>> why I added the MIN2((size_t)max_jint, max_words_per_size_t) statement >>> and included the old calculation in the unit tests to verify that >>> nothing has changed on 64 bits. >>> >>> I can change the code as you suggest, but I would like to understand >>> what the problem is with my code first. I think it handles 64 bits >>> correctly. >>> >>>> check_overflow() should use julong type for expressions instead of >>>> size_t to catch overflow: >>>> >>>> +bool arrayOopDesc::check_overflow(BasicType type) { >>>> + julong length = (julong)max_array_length(type); >>>> + julong bytes_per_element = (julong)type2aelembytes(type); >>>> + julong bytes = length * bytes_per_element + >>>> (julong)header_size_in_bytes(); >>>> + return (julong)(size_t)bytes == bytes; >>>> +} >>> >>> Right. This is why I didn't catch the problem above. Thanks. I'll fix. >>> >>>> Rename check_overflow() to check_max_length_overflow() or something. >>> >>> Done. >>> >>>> I don't think we need incorrect old_max_array_length() method and >>>> corresponding checks for LP64. >>> >>> Ok. I'll keep it for some more testing to make sure that I don't >>> unintentionally change anything for 64 bit. But I'll remove it before >>> I push. >>> >>>> Initialization and execution of additional JPRT tests will increase >>>> jobs time. I think you could add InternalVMTests to existing client >>>> and server tests: >>>> >>>> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >>>> --- >>>> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >>>> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >>>> >>> >>> I see your point regarding the increased job times. But I think it is >>> much clearer to have the internal unit tests as a separate target. >>> That way they can be included and excluded with a JPRT command line. >>> >>> Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I >>> would like to be more explicit about that this is only a (fast)debug >>> build flag. >>> >>> Thanks, >>> Bengt >>> >>>> regards, >>>> Vladimir >>>> >>>> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Can I get a couple of reviews to this fairly small change? >>>>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>>>> >>>>> Sorry for the wide distribution, but the bug is reported on GC, I >>>>> think the actual change (in arrayOop.hpp) is runtime >>>>> responsibility and the method that is being changed is used on a few >>>>> occasions in C2. So, I figured I'd like everyone to >>>>> know that this is about to go in. >>>>> >>>>> CR: >>>>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >>>>> call this otherwise >>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>>>> >>>>> Background >>>>> arrayOopDesc::max_array_length() returns the maximum length an array >>>>> can have based on the type of the array elements. >>>>> This is passed on through the allcocation path as a word size. When >>>>> we need to expand the heap we have to convert the >>>>> word size to a byte size. The problem is that on 32 bit platforms >>>>> this conversion may overflow a size_t. Which will >>>>> result in that we call expand() with a much smaller size than >>>>> required size or even with a size of 0. >>>>> >>>>> Here is a small reproducer that will trigger the assert mentioned in >>>>> the CR if we run it with -XX:+UseG1GC: >>>>> >>>>> public class LargeObj { >>>>> public static void main(String[] args) { >>>>> int[] a = new int[2147483639]; >>>>> } >>>>> } >>>>> >>>>> It is not only G1 that has this problem. ParallelGC has the same >>>>> issue, it just doesn't have an assert to detect it. It >>>>> can be argued that the GCs should check for overflows, but I think >>>>> that since arrayOopDesc::max_array_length() will >>>>> catch the problem earlier and solve it for all GCs this is a better >>>>> place to fix the problem. >>>>> >>>>> I added some unit tests to test the new implementation. To make sure >>>>> that these tests are run I had to update some more >>>>> files. The actual change is in arrayOop.hpp. The rest of the files >>>>> have just been changed to allow the unit tests to run. >>>>> >>>>> A few questions: >>>>> >>>>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >>>>> we don't overflow a size_t. This is only needed on >>>>> 32 bit platforms. I prefer this general code compared to #ifndef >>>>> _LP64. Any thoughts? >>>>> >>>>> (2) I made the unit tests run as JPRT make targets. I guess it can >>>>> also be done as jtreg tests, but that way it would >>>>> only be executed for PIT etc. Any thoughts on this? >>>>> >>>>> Thanks, >>>>> Bengt >>> >> From david.holmes at oracle.com Fri Oct 28 00:21:15 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Oct 2011 17:21:15 +1000 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EAA5468.2010800@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> <4EA950A5.5020408@oracle.com> <4EAA5181.5070201@oracle.com> <4EAA5468.2010800@oracle.com> Message-ID: <4EAA57EB.1040608@oracle.com> On 28/10/2011 5:06 PM, Bengt Rutisson wrote: > On 2011-10-28 08:53, David Holmes wrote: >> After 6 years on Hotspot I was not aware of the existence of >> ExecuteInternalVMTests. :) I wonder when that existing quickSort test >> was last run? That said does this really warrant these internal tests >> over a simple assert in the function itself? > > Actually I added the ExecuteInternalVMTests earlier this summer when I > was adding the quickSort implementation. :-) Ah that explains it - and that would have been through gc or compiler so I wouldn't have seen it. >> That said does this really warrant these internal tests over a simple >> assert in the function itself? > > I think so, since these are very statical calculations. There is really > no need to execute an assert (in debug builds) every time we do the > calculations. I prefer to have this as a separate test. That also makes > it more obvious that all types are tested. True the assert is only need once per run. >> test/Makefile >> >> With regard to only executing the tests for debug/fastdebug, I think >> JPRT may set JPRT_BUILD_FLAVOR which you could then check for the >> presence of "debug". I'm not certain - it might only do that when >> building, not when running the tests. > > Not quite sure how you mean that I can make use of JPRT_BUILD_FLAVOR. > Did you mean that I could avoid having a separate build target if I > could check whether or not it is a debug build and then piggy back the > test execution on the server or client targets? I meant the following (converted to appropriate Make syntax) internalvmtests: prep $(PRODUCT_HOME) if ( substr($JPRT_BUILD_FLAVOR, "Debug") != 0 ) $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -XX:+ExecuteInternalVMTests -version Cheers, David > > Thanks, > Bengt >> >> Cheers, >> David >> >>> Bengt >>> >>> On 2011-10-27 13:44, Bengt Rutisson wrote: >>>> >>>> Hi Vladimir, >>>> >>>> Thanks for looking at this change! >>>> >>>> On 2011-10-26 17:44, Vladimir Kozlov wrote: >>>>> Hi Bengt, >>>>> >>>>> I thought VM should throw OOM exception in such cases (as your >>>>> example) since you can't allocate such arrays in 32-bit VM. Does the >>>>> size check for OOM happened after heap resize calculation? >>>> >>>> You are right. The VM will throw an OOME both before and after my >>>> change. But for different reasons. >>>> >>>> With my change we will detect already in >>>> typeArrayKlass::allocate_common() that length <= max_length() and >>>> throw an OOME. Before this change we could pass that test and go on in >>>> the allocation path. This would result in a size_t overflow when we >>>> want to expand the heap. We would do a lot of extra work to expand to >>>> the wrong size. Then the allocation would fail and we would throw OOME. >>>> >>>> I think it is better to detect this early and avoid the extra work. >>>> This way the assert that G1 does (which I think makes sense) will >>>> hold. We already have the length check so I assume that this was the >>>> intention from the beginning. >>>> >>>>> Is SIZE_MAX defined on all platforms? >>>> >>>> I did try to look around the hotspot code for any uses of max size_t >>>> but I could not find it. So, I reverted to looking at standard ways of >>>> doing it. SIZE_MAX seems to be defined on all our platforms, since my >>>> code passes JPRT. And it seems to be part of the C99 standard: >>>> >>>> http://en.wikipedia.org/wiki/Size_t >>>> >>>> I thought it would be better to rely on this than for example >>>> "(size_t)-1". But I am happy to use any other define. >>>> >>>>> You still have problem with short[] and char[] since >>>>> 2*max_jint+header_size will overflow. >>>> >>>> Right. I did add some unit tests to catch this (but as you point out >>>> below those tests did not detect this overflow). Thanks for catching >>>> it. I will fix it and send out an updated webrev. >>>> >>>>> Also max_array_length() puts unneeded limitation on double[] and >>>>> long[] max length in 64 but VM, it should be max_jint. I think we can >>>>> do something like next: >>>>> >>>>> const size_t max_words_per_size_t = >>>>> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >>>>> MinObjAlignment); >>>>> const size_t max_elements_per_size_t = HeapWordSize * >>>>> max_words_per_size_t / type2aelembytes(type); >>>>> if ((size_t)max_jint < max_elements_per_size_t); >>>>> return max_jint ; >>>>> return (int32_t)max_elements_per_size_t; >>>> >>>> I did not intend for my change to limit anything for 64 bits. That's >>>> why I added the MIN2((size_t)max_jint, max_words_per_size_t) statement >>>> and included the old calculation in the unit tests to verify that >>>> nothing has changed on 64 bits. >>>> >>>> I can change the code as you suggest, but I would like to understand >>>> what the problem is with my code first. I think it handles 64 bits >>>> correctly. >>>> >>>>> check_overflow() should use julong type for expressions instead of >>>>> size_t to catch overflow: >>>>> >>>>> +bool arrayOopDesc::check_overflow(BasicType type) { >>>>> + julong length = (julong)max_array_length(type); >>>>> + julong bytes_per_element = (julong)type2aelembytes(type); >>>>> + julong bytes = length * bytes_per_element + >>>>> (julong)header_size_in_bytes(); >>>>> + return (julong)(size_t)bytes == bytes; >>>>> +} >>>> >>>> Right. This is why I didn't catch the problem above. Thanks. I'll fix. >>>> >>>>> Rename check_overflow() to check_max_length_overflow() or something. >>>> >>>> Done. >>>> >>>>> I don't think we need incorrect old_max_array_length() method and >>>>> corresponding checks for LP64. >>>> >>>> Ok. I'll keep it for some more testing to make sure that I don't >>>> unintentionally change anything for 64 bit. But I'll remove it before >>>> I push. >>>> >>>>> Initialization and execution of additional JPRT tests will increase >>>>> jobs time. I think you could add InternalVMTests to existing client >>>>> and server tests: >>>>> >>>>> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >>>>> --- >>>>> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >>>>> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >>>>> >>>> >>>> I see your point regarding the increased job times. But I think it is >>>> much clearer to have the internal unit tests as a separate target. >>>> That way they can be included and excluded with a JPRT command line. >>>> >>>> Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I >>>> would like to be more explicit about that this is only a (fast)debug >>>> build flag. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> regards, >>>>> Vladimir >>>>> >>>>> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Can I get a couple of reviews to this fairly small change? >>>>>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>>>>> >>>>>> Sorry for the wide distribution, but the bug is reported on GC, I >>>>>> think the actual change (in arrayOop.hpp) is runtime >>>>>> responsibility and the method that is being changed is used on a few >>>>>> occasions in C2. So, I figured I'd like everyone to >>>>>> know that this is about to go in. >>>>>> >>>>>> CR: >>>>>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >>>>>> call this otherwise >>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>>>>> >>>>>> Background >>>>>> arrayOopDesc::max_array_length() returns the maximum length an array >>>>>> can have based on the type of the array elements. >>>>>> This is passed on through the allcocation path as a word size. When >>>>>> we need to expand the heap we have to convert the >>>>>> word size to a byte size. The problem is that on 32 bit platforms >>>>>> this conversion may overflow a size_t. Which will >>>>>> result in that we call expand() with a much smaller size than >>>>>> required size or even with a size of 0. >>>>>> >>>>>> Here is a small reproducer that will trigger the assert mentioned in >>>>>> the CR if we run it with -XX:+UseG1GC: >>>>>> >>>>>> public class LargeObj { >>>>>> public static void main(String[] args) { >>>>>> int[] a = new int[2147483639]; >>>>>> } >>>>>> } >>>>>> >>>>>> It is not only G1 that has this problem. ParallelGC has the same >>>>>> issue, it just doesn't have an assert to detect it. It >>>>>> can be argued that the GCs should check for overflows, but I think >>>>>> that since arrayOopDesc::max_array_length() will >>>>>> catch the problem earlier and solve it for all GCs this is a better >>>>>> place to fix the problem. >>>>>> >>>>>> I added some unit tests to test the new implementation. To make sure >>>>>> that these tests are run I had to update some more >>>>>> files. The actual change is in arrayOop.hpp. The rest of the files >>>>>> have just been changed to allow the unit tests to run. >>>>>> >>>>>> A few questions: >>>>>> >>>>>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >>>>>> we don't overflow a size_t. This is only needed on >>>>>> 32 bit platforms. I prefer this general code compared to #ifndef >>>>>> _LP64. Any thoughts? >>>>>> >>>>>> (2) I made the unit tests run as JPRT make targets. I guess it can >>>>>> also be done as jtreg tests, but that way it would >>>>>> only be executed for PIT etc. Any thoughts on this? >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >>> > From john.pampuch at oracle.com Fri Oct 28 10:47:48 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Fri, 28 Oct 2011 10:47:48 -0700 Subject: HotSpot development trees In-Reply-To: References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> <4EAA1AEA.2060505@oracle.com> Message-ID: <4EAAEAC4.8000001@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111028/9d29dc7b/attachment.html From tony.printezis at oracle.com Fri Oct 28 12:11:34 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 28 Oct 2011 19:11:34 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20111028191148.C9700471BD@hg.openjdk.java.net> Changeset: 5e5d4821bf07 Author: brutisso Date: 2011-10-20 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5e5d4821bf07 7097516: G1: assert(0<= from_card && from_card References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> Message-ID: <4EAB0963.5020503@oracle.com> On 10/28/11 2:37 AM, Erik Trimble wrote: > Back to Andrew's question: > > The best HSX candidate repository for OpenJDK6 to use is N-1, where N is the largest one you see. In theory, that repo should be fully stabilized. The hsxN repo is current undergoing stabilization, and the hsx/hotspot-main is undergoing active development. As Paul mentioned, hs23 is currently being promoted into both the jdk7u train and the jdk8 train on a (semi-)regular basis. We don't test it with jdk6, and don't plan to integrate it into jdk6, as John said. Similarly, hs21 and hs22 are used for jdk7 and jdk7u2 releases, so while it may be technically possible to get them to build with jdk6, given that the combination is untested, it's not something for the faint-hearted. If things break, you get to keep the pieces, etc. In short, if you'd like to use hs21 or later in a release, use jdk7u - that's where the promotion and testing action is. cheers, dalibor topic > -Erik > > > On 10/27/2011 8:21 AM, Paul Hohensee wrote: >> Good summary, Dave. >> >> The mainline hotspot development train is tagged as hs23 because back in August >> we changed our process so that the hotspot major version number bump happens >> when we start development on a new major version rather than when we end it. >> That's so we can deliver the same version into multiple under-development >> JDK versions at the same time. Before August, we bumped the major version >> number each time we delivered into a new JDK, which can cause a nasty jam-up. >> >> hs23 is currently being promoted into both the jdk7u train and the jdk8 train >> on a (semi-)regular basis. >> >> Paul >> >> On 10/26/11 10:35 PM, David Holmes wrote: >>> On 27/10/2011 8:49 AM, Dr Andrew John Hughes wrote: >>>> I see three HotSpot trees have appeared at hg.openjdk.java.net since >>>> I last imported one into OpenJDK6: >>>> >>>> hsx/hsx21/baseline and hsx/hsx21/master >>>> hsx/hsx22/hotspot >>>> hsx/hsx23/hotspot >>>> >>>> Which of these can be regarded as stable and can be integrated into >>>> OpenJDK6? >>> >>> I think they are all "stable" (hs23 the least) but possibly the answer for OpenJDK6 is "none of the above". >>> >>> hs20.X is used in our currentJDK6 update train (and hs19.X for earlier updates) >>> hs21 was jdk7 >>> hs22 is 7u2 >>> hs23 is current version for mainline and for next 7u after 7u2 (not sure why it's already forked off) >>> >>>> The nomenclature also appears to have changed from baseline/master >>>> trees to just one called 'hotspot'. Why is this? >>> >>> The mainline tree is now hsx/hotspot-main, we then fork off hsx/hsxNN as needed. This started with hs22 IIRC. >>> >>> David >>> >>>> Thanks, > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From john.coomes at oracle.com Fri Oct 28 19:53:13 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 29 Oct 2011 02:53:13 +0000 Subject: hg: hsx/hsx23/hotspot: 11 new changesets Message-ID: <20111029025342.131C1471C7@hg.openjdk.java.net> Changeset: 02fe430d493e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/02fe430d493e Added tag jdk8-b11 for changeset 4538caeef7b6 ! .hgtags Changeset: c9d25d93ddfe Author: jcoomes Date: 2011-10-21 16:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c9d25d93ddfe 7103619: Bump the hs23 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5e5d4821bf07 Author: brutisso Date: 2011-10-20 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5e5d4821bf07 7097516: G1: assert(0<= from_card && from_card References: <20111026224959.GK594@rivendell.redhat.com> <4EA8C35F.3010208@oracle.com> <4EA976E3.3000704@oracle.com> <4EA9F94F.3030707@netdemons.com> <4EAA1AEA.2060505@oracle.com> Message-ID: <4EABA885.2060700@netdemons.com> On 10/27/2011 11:58 PM, Krystal Mok wrote: > Hi all, > > HS21 introduced quite a few behavioral changes that OpenJDK 6 users > might not be expecting. One of them would be the progress of PermGen > removal, which affects some tuning. It might still be pretty much > compatible, but no one has been testing for JDK6/HS21 compatibility, > right? > > From what we can see from the outside, recent JDK 6 releases from > Oracle are staying on HotSpot 20.x, with some bug fixes applied. > > My question is: > Are there any plans from Oracle/OpenJDK to release further updates to > OpenJDK 6, with the bug fixes applied to HotSpot Express 20's master > repo? Or, could there be a list of recommended list of bug > fixes/patches that should be backported to HS20? > > We're stuck on JDK 6 now, with no plans to move to JDK 7 in the near > future, our work would have to base on HS20. So backporting bugfixes > to HS20 is kind of like "scratching my own itch". If there's anything > outside contributors can do about this, I'm more than willing to help. > > Regards, > Kris Mok > > Software Engineer > Taobao (http://www.taobao.com) > I admit I'm not as intimately aware of what's going on in the JVM as I once was, but I see no real reason why HS21 or better shouldn't work under OpenJDK 6, *provided* that during the backport process, certain features are either permanently disabled, or just turned off by default. I was under the impression that HS20 was being retained as the Oracle JDK 6 VM so as to lower the workload for testing - that is, Oracle JDK 6 was being moved into a "maintenance mode" process, and that all that was being applied to that codebase was fixes, rather than the continued stream of VM feature updates that had been the norm prior to the official release of JDK 7. If someone inside Oracle can comment? -Erik > On Fri, Oct 28, 2011 at 11:00 AM, David Holmes > > wrote: > > On 28/10/2011 10:37 AM, Erik Trimble wrote: > > Back to Andrew's question: > > The best HSX candidate repository for OpenJDK6 to use is N-1, > where N is > the largest one you see. In theory, that repo should be fully > stabilized. The hsxN repo is current undergoing stabilization, > and the > hsx/hotspot-main is undergoing active development. > > > There is no guarantee that hs21+ will work with OpenJDK6 > > David > > > -Erik > > > On 10/27/2011 8:21 AM, Paul Hohensee wrote: > > Good summary, Dave. > > The mainline hotspot development train is tagged as hs23 > because back > in August > we changed our process so that the hotspot major version > number bump > happens > when we start development on a new major version rather > than when we > end it. > That's so we can deliver the same version into multiple > under-development > JDK versions at the same time. Before August, we bumped > the major version > number each time we delivered into a new JDK, which can > cause a nasty > jam-up. > > hs23 is currently being promoted into both the jdk7u train > and the > jdk8 train > on a (semi-)regular basis. > > Paul > > On 10/26/11 10:35 PM, David Holmes wrote: > > On 27/10/2011 8:49 AM, Dr Andrew John Hughes wrote: > > I see three HotSpot trees have appeared at > hg.openjdk.java.net since > I last imported one into OpenJDK6: > > hsx/hsx21/baseline and hsx/hsx21/master > hsx/hsx22/hotspot > hsx/hsx23/hotspot > > Which of these can be regarded as stable and can > be integrated into > OpenJDK6? > > > I think they are all "stable" (hs23 the least) but > possibly the > answer for OpenJDK6 is "none of the above". > > hs20.X is used in our currentJDK6 update train (and > hs19.X for > earlier updates) > hs21 was jdk7 > hs22 is 7u2 > hs23 is current version for mainline and for next 7u > after 7u2 (not > sure why it's already forked off) > > The nomenclature also appears to have changed from > baseline/master > trees to just one called 'hotspot'. Why is this? > > > The mainline tree is now hsx/hotspot-main, we then > fork off hsx/hsxNN > as needed. This started with hs22 IIRC. > > David > > Thanks, > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111029/f7cb7546/attachment-0001.html From john.coomes at oracle.com Sat Oct 29 03:05:57 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 29 Oct 2011 10:05:57 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111029100611.CCCB4471CC@hg.openjdk.java.net> Changeset: 02fe430d493e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/02fe430d493e Added tag jdk8-b11 for changeset 4538caeef7b6 ! .hgtags Changeset: 6534482ff68a Author: jcoomes Date: 2011-10-28 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6534482ff68a Merge Changeset: 1d3900713a67 Author: jcoomes Date: 2011-10-28 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1d3900713a67 Added tag hs23-b04 for changeset 6534482ff68a ! .hgtags Changeset: 5c8c7bef6403 Author: jcoomes Date: 2011-10-28 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5c8c7bef6403 7106092: Bump the hs23 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From daniel.daugherty at oracle.com Mon Oct 31 10:26:12 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 31 Oct 2011 11:26:12 -0600 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA9C421.9000606@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> <4EA950A5.5020408@oracle.com> <4EA980FA.4000900@oracle.com> <4EA9C11D.7080408@oracle.com> <4EA9C421.9000606@oracle.com> Message-ID: <4EAEDA34.5070509@oracle.com> On 10/27/11 2:50 PM, Vladimir Kozlov wrote: > Bengt Rutisson wrote: >>> I am fine with SIZE_MAX if it passed JPRT (including embedded) as >>> you said. If you can, please, verify if it exist in bsd and mac. May >>> be Dan or Christian can help. >> >> I'll check with them. You mean Dan Daugherty and Christian Thalenger, >> right? > > Yes, them. On my MacOS 10.6.8 machine: /usr/include/gcc/darwin/4.0/stdint.h:#define SIZE_MAX UINT64_MAX /usr/include/gcc/darwin/4.0/stdint.h:#define SIZE_MAX UINT32_MAX /usr/include/gcc/darwin/4.2/stdint.h:#define SIZE_MAX UINT64_MAX /usr/include/gcc/darwin/4.2/stdint.h:#define SIZE_MAX UINT32_MAX On my MacOS 10.7 machine, SIZE_MAX shows up in /usr/include/stdint.h. That same path is a symlink on my 10.6.8 machine... Dan