From guanxiaohua at gmail.com Sun Aug 1 13:50:57 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Sun, 1 Aug 2010 15:50:57 -0500 Subject: how to bring jvm to safepoint In-Reply-To: <4C54ED7D.50202@oracle.com> References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> <4C53BB1E.9070401@oracle.com> <4C54ED7D.50202@oracle.com> Message-ID: Hi David, Thanks for the explanation, now I get to understand it. Have to say, it's a nice failure for me. :) Tony (Xiaohua Guan) On Sat, Jul 31, 2010 at 10:43 PM, David Holmes wrote: > Hi Tony, > > Now it is all clear :) > >> It's exactly how the error occurred, I am monitoring the >> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >> intercepting inside jvm implementation), once this method gets called, >> I will call GenCollectedHeap::invoke_transEden_collection() to start a >> GC using VMThread::Execute(&op). > > Right, you are using: > > _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 > > but dtrace_method_exit is defined as a runtime "leaf" method (JRT_LEAF). > "leaf" methods are not allowed to perform certain actions and in debug mode > we have JRT_Leaf_Verifier that is used to check those actions. A > JRT_Leaf_Verifier is a No_Safepoint_Verifier - hence as I said before you > get the assertion failure due to this. > > When you do the VMThread::execute to initiate the safepoint operation for > your GC action, the current thread will block waiting for it to complete. > Part of that blocking involves a safepoint check and hence the system finds > that the thread is attempting to enter a safepoint from a "leaf" method - > and that is not allowed. > > You might just try changing the definition of dtrace_method_exit to be > JRT_ENTRY rather than JRT_LEAF, but I don't know if that will have > unexpected side-effects. > > There are lots of rules (not necessarily clearly documented) that control > how you can call into the VM runtime and how different parts of the VM > runtime can call other parts of the runtime. > > Cheers, > David Holmes > > Tony Guan said the following on 08/01/10 08:10: >> >> Hi David & Tom, >> >> Please see the decoded stack below(also full decoded log is attached): >> >> " >> Current thread (0x00000000012ed000): ?JavaThread "RMI TCP >> Connection(idle)" daemon [_thread_in_Java, id=30929, >> stack(0x000000004073b000,0x000000004083c000)] >> >> Stack: [0x000000004073b000,0x000000004083c000], >> sp=0x0000000040839d60, ?free space=3fb0000000000000000k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V ?[libjvm.so+0x8cad18];; ?_ZN7VMError6reportEP12outputStream+0xb72 >> V ?[libjvm.so+0x8cbe38];; ?_ZN7VMError14report_and_dieEv+0x5f6 >> V ?[libjvm.so+0x4039f1];; ?_Z12report_fatalPKciS0_+0x6b >> V ?[libjvm.so+0x87a183];; >> ?_ZN6Thread31check_for_valid_safepoint_stateEb+0x33 >> V ?[libjvm.so+0x8e1127];; ?_ZN8VMThread7executeEP12VM_Operation+0x49 >> V ?[libjvm.so+0x4d52ab];; >> _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 >> V ?[libjvm.so+0x7ee63d];; >> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >> j ?sun.misc.Unsafe.park(ZJ)V+0 >> j >> ?java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >> j >> ?java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >> j >> ?java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >> j >> ?java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >> j >> ?java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >> j >> ?java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >> j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 >> j ?java.lang.Thread.run()V+11 >> v ?~StubRoutines::call_stub >> V ?[libjvm.so+0x555ecc];; >> >> _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 >> V ?[libjvm.so+0x747a34];; >> >> _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 >> V ?[libjvm.so+0x554b55];; >> >> _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f >> V ?[libjvm.so+0x5551f0];; >> >> _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 >> V ?[libjvm.so+0x5553cc];; >> >> _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 >> V ?[libjvm.so+0x5be6cd];; ?_Z12thread_entryP10JavaThreadP6Thread+0x9f >> V ?[libjvm.so+0x879869];; ?_ZN10JavaThread17thread_main_innerEv+0xc9 >> V ?[libjvm.so+0x87c1b5];; ?_ZN10JavaThread3runEv+0x2c1 >> V ?[libjvm.so+0x750455];; ?_Z10java_startP6Thread+0x16f >> " >> >> It's exactly how the error occurred, I am monitoring the >> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >> intercepting inside jvm implementation), once this method gets called, >> I will call GenCollectedHeap::invoke_transEden_collection() to start a >> GC using VMThread::Execute(&op). >> >> At the beginning of VMTHread::Execute(), >> check_for_valid_safepoint_state is called like this: >> >> void VMThread::execute(VM_Operation* op) { >> ?Thread* t = Thread::current(); >> ?if (!t->is_VM_thread()) { >> ? ?// JavaThread or WatcherThread >> ? ?t->check_for_valid_safepoint_state(true); ?//And we failed here!! >> ? ?// New request from Java thread, evaluate prologue >> ? ?if (!op->doit_prologue()) { >> ? ? ?return; ? // op was cancelled >> ? ?} >> ... >> } >> >> That's why I said the current thread is not a VM_thread. I think I can >> make a workaround by invoking the GC at the next allocation request, >> which should be in the safepoint. But would be great if I can learn >> more about hotspot solving this problem. >> >> Thanks a lot! >> >> Tony (Xiaohua Guan) >> >> >> >> On Sat, Jul 31, 2010 at 12:56 AM, David Holmes >> wrote: >>> >>> Tom Rodriguez said the following on 07/31/10 05:01: >>>> >>>> Actually I think the problem is that the thread is in thread_in_Java >>>> state. I don't believe you can safepoint from that state, only >>>> thread_in_vm. >>> >>> The reported failure: >>> >>> # ?Error: Possible safepoint reached by thread that does not allow it >>> >>> is here: >>> >>> void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) >>> { >>> ? // Check if current thread is allowed to block at a safepoint >>> ? if (!(_allow_safepoint_count == 0)) >>> ? ? fatal("Possible safepoint reached by thread that does not allow it"); >>> >>> as far as I can see the only code that touches _allow_safepoint_count are >>> the No_Safepoint_Verifier classes. >>> >>> Also the stack shows: >>> >>> V ?[libjvm.so+0x7ee63d] >>> j ?sun.misc.Unsafe.park(ZJ)V+0 >>> >>> and so we should have transitioned to _thread_in_vm here. >>> >>> That said, Tony also stated: >>> >>>> The reason for the fail is that >>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>> the currentThread is not a VMThread. >>> >>> But that is not supported by the error produced. >>> >>> Tony: why did you make the above comment? >>> >>> Either way we need to see a decoded stack to get an idea of what is going >>> wrong. >>> >>> Cheers, >>> David >>> >>>> tom >>>> >>>> On Jul 30, 2010, at 12:04 AM, David Holmes >>>> wrote: >>>> >>>>> Sorry Tony I keep forgetting that I don't have a way to decode a >>>>> crash log from a VM that you built yourself. :( However you may be >>>>> able to decode it yourself please see: >>>>> >>>>> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >>>>> >>>>> for a perl script. >>>>> >>>>> That said looking at the actual assertion failure I am guessing >>>>> that you initiated the VM operation from code where a >>>>> No_Safepoint_verifier is active. >>>>> >>>>> David >>>>> >>>>> Tony Guan said the following on 07/30/10 15:58: >>>>>> >>>>>> Hi David, Thanks a lot! I am copying the content to below, and >>>>>> for convenience, the full log file is attached. cat >>>>>> hs_err_pid30894.log # # A fatal error has been detected by the >>>>>> Java Runtime Environment: # # ?Internal Error >>>>>> >>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>> ?pid=30894, tid=1082374480 # ?Error: Possible safepoint reached >>>>>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>>>>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>>>>> mode linux-amd64 ) # If you would like to submit a bug report, >>>>>> please visit: # ? http://java.sun.com/webapps/bugreport/crash.jsp >>>>>> ?# --------------- ?T H R E A D ?--------------- Current thread >>>>>> (0x00000000012ed000): ?JavaThread "RMI TCP Connection(idle)" >>>>>> daemon [_thread_in_Java, id=30929, >>>>>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>>>>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>>>>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>>>>> code, j=interpreted, Vv=VM code, C=native code) V >>>>>> [libjvm.so+0x8cad18] V ?[libjvm.so+0x8cbe38] V >>>>>> [libjvm.so+0x4039f1] V ?[libjvm.so+0x87a183] V >>>>>> [libjvm.so+0x8e1127] V ?[libjvm.so+0x4d52ab] V >>>>>> [libjvm.so+0x7ee63d] j ?sun.misc.Unsafe.park(ZJ)V+0 j >>>>>> >>>>>> >>>>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>>> ?j >>>>>> >>>>>> >>>>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>>> ?j >>>>>> >>>>>> >>>>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>>> ?j >>>>>> >>>>>> >>>>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>>> ?j >>>>>> >>>>>> >>>>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>>> ?j >>>>>> >>>>>> >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>>> ?j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>>>>> java.lang.Thread.run()V+11 v ?~StubRoutines::call_stub V >>>>>> [libjvm.so+0x555ecc] V ?[libjvm.so+0x747a34] V >>>>>> [libjvm.so+0x554b55] V ?[libjvm.so+0x5551f0] V >>>>>> [libjvm.so+0x5553cc] V ?[libjvm.so+0x5be6cd] V >>>>>> [libjvm.so+0x879869] V ?[libjvm.so+0x87c1b5] V >>>>>> [libjvm.so+0x750455] .... (above is the stack, please see the >>>>>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>>>>> 29, 2010 at 8:07 PM, David Holmes >>>>>> wrote: >>>>>>> >>>>>>> Tony, >>>>>>> >>>>>>> I don't see anything obviously wrong with what you attempted. >>>>>>> Can you show the full stack dump from the error. >>>>>>> >>>>>>> David Holmes >>>>>>> >>>>>>> Tony Guan said the following on 07/30/10 07:29: >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I want to invoke the GC at a certain time, for example, when >>>>>>>> a certain method is called at runtime, so I created a new >>>>>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>>>>> object op, finally, executed using:VMThread::execute(&op) >>>>>>>> >>>>>>>> then I got the following error message: >>>>>>>> >>>>>>>> # ?Internal Error >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>> ?pid=29652, tid=1096460624 # ?Error: Possible safepoint >>>>>>>> reached by thread that does not allow it >>>>>>>> >>>>>>>> The reason for the fail is that >>>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>>> the currentThread is not a VMThread. >>>>>>>> >>>>>>>> My question is: how do I bring the current thread to a >>>>>>>> safepoint? or how do I call a GC operation properly? is there >>>>>>>> any prerequisite for doing so? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Tony (Xiaohua Guan) > From ik3g09 at ecs.soton.ac.uk Mon Aug 2 13:17:25 2010 From: ik3g09 at ecs.soton.ac.uk (kammerath i. (ik3g09)) Date: Mon, 2 Aug 2010 21:17:25 +0100 Subject: Research into modifications on the primordial class loader Message-ID: Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members, After initial contact with core-libs-owner, I have been able to get a lot further. The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. Where am I: Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not). Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play? I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"? I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. Many thanks in advance Ivo ________________________________________ From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu] Sent: 01 August 2010 03:35 To: kammerath i. (ik3g09) Subject: RE: Research on the primordial class loader Hi, Ivo. I didn't receive your original message. I don't know what happened as it isn't in the set of pending moderator requests and your message didn't seem to make it into our archive (see the "archive link") near the top of this page: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev One way to avoid the need for moderation is to become a subscriber. There is a digest mode if you get inundated with mail. Alternatively, you could just unsubscribe as soon as you get the information you need. I think that core-libs-dev is a fine place to ask your question. Alternatively hotspot-dev or hotspot-runtime-dev may also be good candidates as that is where a great deal of heavy lifting occurs for class loading. Here are some pointers for you to begin your investigation. I've selected subversion files from the JDK7 tl repository, but these files will reside in similar locations in other JDK repositories. http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j ava/lang/ClassLoader.java java.lang.ClassLoader provides the specification for the delegation model and is the primary implementation. Note that specification comments such as this: "If the parent is "null", the class loader built-in to the virtual machine..." and the corresponding null checks are references to class loader implemented by the VM. http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja va/lang/ClassLoader.c The supporting libraries C code for j.l.ClassLoader. This is where libraries makes the calls into the VM. http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl assfile/ I am by no means a VM expert, but I believe that this is where the VM implements most of class loading. A VM engineer will be able to provide more details. http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html I'm sure you've' already found it, but just in case... The VM specification, Chapter 5 contains the complete spec for loading, linking, and initializing: Hope this gets you started. My apologies for not seeing your earlier message. Thanks, iris ________________________________________ From: Ivo Sent: 29 July 2010 17:15 To: core-libs-dev at openjdk.java.net Subject: Research on the primordial class loader Hello core-libs-dev members, In my research on dynamic continuous integration at run-time and dynamic self-modification. I reached a point where I would like to have a look at the implementation of the 'Primordial ClassLoader'. Which, according to what I read so far, is responsible for loading all classes, excluding those loaded by any custom ClassLaoder. When I downloaded the OpenJDK source I felt a little lost, I could not quite work out where to look. As far as I understood, the Primordial ClassLoader is more than just a bunch of Java classes. Correct me if I am wrong, but I assume it involves a few C/C++ classes/procedures? So my question is: Which classes are involved in the primordial classloading and which files of the HotSpot are involved in the process? many thanks in advance Ivo From vladimir.kozlov at oracle.com Mon Aug 2 15:01:02 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Aug 2010 15:01:02 -0700 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] Message-ID: <4C57401E.5040204@oracle.com> Forwarding to GC and Runtime groups since it is common code. Vladimir -------- Original Message -------- Subject: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA Date: Mon, 02 Aug 2010 14:57:25 -0700 From: Vladimir Kozlov To: hotspot compiler http://cr.openjdk.java.net/~kvn/6973963/webrev Fixed 6973963: SEGV in ciBlock::start_bci() with EA I added stress recompilation during CompileTheWorld and found this case. It is similar to 6968368. BCEscapeAnalyzer::do_analysis() calls ciMethod::get_method_blocks() which calls constructor ciMethodBlocks. This constructor allocates GrowableArray elements on stack (thread local resource area). As result when the method recompiled without EA _blocks->_data is NULL. Solution: Added stress recompilation during CompileTheWorld: recompile with subsume_loads = false and do_escape_analysis = false. Added more checks into ResourceObj and growableArray to verify correctness of allocation. I have to relax the new assert in GrowableArray when elements are allocated on arena to allow allocattion of GrowableArray object as a part of an other object (for example, in ConnectionGraph and SuperWord). Tested with failed cases, CTW. From tom.rodriguez at oracle.com Mon Aug 2 15:24:51 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 2 Aug 2010 15:24:51 -0700 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] In-Reply-To: <4C57401E.5040204@oracle.com> References: <4C57401E.5040204@oracle.com> Message-ID: So doesn't this triple the amount of time taken by CTW? That seems kind of extreme for the default mode. Maybe it should be under a flag? The allocation.hpp changes look a little sketchy. + if (~(_allocation | allocation_mask) != (uintptr_t)this) { + set_allocation_type((address)this, RESOURCE_AREA); Why is this case called RESOURCE_AREA? Isn't this the stack or embedding case? This doesn't make sense either. ! bool allocated_on_stack() { return get_allocation_type() == RESOURCE_AREA; } Anyway, the existing logic around this seemed sketchy so I can't quite say whether this is better or not. I'll have to leave that to someone else. The GrowableArray changes themselves look fine. tom On Aug 2, 2010, at 3:01 PM, Vladimir Kozlov wrote: > Forwarding to GC and Runtime groups since it is common code. > > Vladimir > > -------- Original Message -------- > Subject: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA > Date: Mon, 02 Aug 2010 14:57:25 -0700 > From: Vladimir Kozlov > To: hotspot compiler > > http://cr.openjdk.java.net/~kvn/6973963/webrev > > Fixed 6973963: SEGV in ciBlock::start_bci() with EA > > I added stress recompilation during CompileTheWorld and found this case. > It is similar to 6968368. BCEscapeAnalyzer::do_analysis() calls > ciMethod::get_method_blocks() which calls constructor ciMethodBlocks. > This constructor allocates GrowableArray elements on stack (thread > local resource area). As result when the method recompiled without EA > _blocks->_data is NULL. > > Solution: > Added stress recompilation during CompileTheWorld: recompile with > subsume_loads = false and do_escape_analysis = false. > Added more checks into ResourceObj and growableArray to verify correctness > of allocation. I have to relax the new assert in GrowableArray when > elements are allocated on arena to allow allocattion of GrowableArray object > as a part of an other object (for example, in ConnectionGraph and SuperWord). > > Tested with failed cases, CTW. From vladimir.kozlov at oracle.com Mon Aug 2 15:39:00 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Aug 2010 15:39:00 -0700 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] In-Reply-To: References: <4C57401E.5040204@oracle.com> Message-ID: <4C574904.2050307@oracle.com> Thank you, Tom RESOURCE_AREA case combines 3 cases: GrowableArray *foo = new GrowableArray(size); // resource array allocation GrowableArray foo; // stack allocation class A : public ResourceObj { GrowableArray foo; // embedding allocation } In all this cases GrowableArray::_data array is allocated in thread local resource area. GrowableArray calls all these cases as stack allocation and I followed this naming. But you are right I can separate 2 last cases into "stack" (stack or embedding) allocation, I still have 1 bit in allocation_type :) Thanks, Vladimir Tom Rodriguez wrote: > So doesn't this triple the amount of time taken by CTW? That seems kind of extreme for the default mode. Maybe it should be under a flag? The allocation.hpp changes look a little sketchy. > > + if (~(_allocation | allocation_mask) != (uintptr_t)this) { > + set_allocation_type((address)this, RESOURCE_AREA); > > Why is this case called RESOURCE_AREA? Isn't this the stack or embedding case? > > This doesn't make sense either. > > ! bool allocated_on_stack() { return get_allocation_type() == RESOURCE_AREA; } > > Anyway, the existing logic around this seemed sketchy so I can't quite say whether this is better or not. I'll have to leave that to someone else. > > The GrowableArray changes themselves look fine. > > tom > > On Aug 2, 2010, at 3:01 PM, Vladimir Kozlov wrote: > >> Forwarding to GC and Runtime groups since it is common code. >> >> Vladimir >> >> -------- Original Message -------- >> Subject: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA >> Date: Mon, 02 Aug 2010 14:57:25 -0700 >> From: Vladimir Kozlov >> To: hotspot compiler >> >> http://cr.openjdk.java.net/~kvn/6973963/webrev >> >> Fixed 6973963: SEGV in ciBlock::start_bci() with EA >> >> I added stress recompilation during CompileTheWorld and found this case. >> It is similar to 6968368. BCEscapeAnalyzer::do_analysis() calls >> ciMethod::get_method_blocks() which calls constructor ciMethodBlocks. >> This constructor allocates GrowableArray elements on stack (thread >> local resource area). As result when the method recompiled without EA >> _blocks->_data is NULL. >> >> Solution: >> Added stress recompilation during CompileTheWorld: recompile with >> subsume_loads = false and do_escape_analysis = false. >> Added more checks into ResourceObj and growableArray to verify correctness >> of allocation. I have to relax the new assert in GrowableArray when >> elements are allocated on arena to allow allocattion of GrowableArray object >> as a part of an other object (for example, in ConnectionGraph and SuperWord). >> >> Tested with failed cases, CTW. > From David.Holmes at oracle.com Mon Aug 2 16:44:35 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 03 Aug 2010 09:44:35 +1000 Subject: Research into modifications on the primordial class loader In-Reply-To: References: Message-ID: <4C575863.1050602@oracle.com> Just a clarification on terminology. The native loader in the VM is the bootstrap loader. A class was loaded by the bootstrap loader if its ClassLoader is reported as "null". There is then a hierarchy of classloaders created: - the extensions loader is used to add the ability to load standard extensions (from lib/ext if I recall correctly) these are classes that are treated the same as "core" classes for security purposes - the application-class loader, aka the system classloader (bad name), is created to load the application class that you want to run The application can then define its own classloaders. For a ClassLoader to actually load a class it must use defineClass, which is implemented in the VM as part of the native loader. Hence any subterfuge has to be done inside the VM: you need to look at the systemDictionary and the loader_constraints, which enforce the language rules. I really don't know how you would go about doing what you suggest because the details are the critical points here. You could define a ClassLoader that returned an arbitrary Class object for a given name, but that Class object would report it's real identity. If this was part of an implicit classloading process, then you'd likely get a ClassCastException, or some other exception if you actually tried to return a different Class than required. Good luck. David Holmes kammerath i. (ik3g09) said the following on 08/03/10 06:17: > Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members, > > After initial contact with core-libs-owner, I have been able to get a lot further. > The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. > > When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). > > Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. > > Where am I: > > Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not). > > Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play? > I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"? > > I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. > > Many thanks in advance > Ivo > ________________________________________ > From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu] > Sent: 01 August 2010 03:35 > To: kammerath i. (ik3g09) > Subject: RE: Research on the primordial class loader > > Hi, Ivo. > > I didn't receive your original message. I don't know what happened as it > isn't in the set of pending moderator requests and your message didn't seem > to make it into our archive (see the "archive link") near the top of this > page: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > > One way to avoid the need for moderation is to become a subscriber. There > is a digest mode if you get inundated with mail. Alternatively, you could > just unsubscribe as soon as you get the information you need. > > I think that core-libs-dev is a fine place to ask your question. > Alternatively hotspot-dev or hotspot-runtime-dev may also be good > candidates as that is where a great deal of heavy lifting occurs for class > loading. Here are some pointers for you to begin your investigation. I've > selected subversion files from the JDK7 tl repository, but these files will > reside in similar locations in other JDK repositories. > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j > ava/lang/ClassLoader.java > java.lang.ClassLoader provides the specification for the delegation model > and is the primary implementation. Note that specification comments such > as this: "If the parent is "null", the class loader built-in to the > virtual machine..." and the corresponding null checks are references to > class loader implemented by the VM. > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja > va/lang/ClassLoader.c > The supporting libraries C code for j.l.ClassLoader. This is where > libraries makes the calls into the VM. > > http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl > assfile/ > I am by no means a VM expert, but I believe that this is where the VM > implements most of class loading. A VM engineer will be able to provide > more details. > > http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html > I'm sure you've' already found it, but just in case... The VM > specification, > Chapter 5 contains the complete spec for loading, linking, and > initializing: > > Hope this gets you started. My apologies for not seeing your earlier > message. > > Thanks, > iris > ________________________________________ > From: Ivo > Sent: 29 July 2010 17:15 > To: core-libs-dev at openjdk.java.net > Subject: Research on the primordial class loader > > Hello core-libs-dev members, > > In my research on dynamic continuous integration at run-time and dynamic > self-modification. > I reached a point where I would like to have a look at the implementation of > the 'Primordial ClassLoader'. > Which, according to what I read so far, is responsible for loading all > classes, excluding those loaded by any > custom ClassLaoder. > > When I downloaded the OpenJDK source I felt a little lost, I could not quite > work out where to look. > As far as I understood, the Primordial ClassLoader is more than just a > bunch of Java classes. > Correct me if I am wrong, but I assume it involves a few C/C++ > classes/procedures? > > So my question is: > Which classes are involved in the primordial classloading and which files of > the HotSpot are involved in the process? > > many thanks in advance > Ivo From ap.nath at gmail.com Mon Aug 2 22:20:23 2010 From: ap.nath at gmail.com (Apurba Nath) Date: Tue, 3 Aug 2010 10:50:23 +0530 Subject: Research into modifications on the primordial class loader Message-ID: Hi Ivo I am not an expert, read at your own risk, am looking into the same problem myself. I understand that your original problem was "dynamic continuous integration at run-time and dynamic self-modification", if that is the case we are interested in reloading a different version of the same class, if so unloading the class and loading the new class is going to be pretty complicated, as we would need to move all the existing objects from the previous class definition to the new, also remember its impact on all the classes that extend this. I am trying to currently soup up the vtable and itable portions in the class definition, the idea is that when we provide a new version of an existing class, we analyse the methods that have been modified and the ones that have been added and make the corresponding changes in the vtable. The current vtable implementation needs to be modified to make it grow dynamically at class levels, if you or anyone else is interested, can send details of the changes that I am trying to implement. Thanks Apurba > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 Aug 2010 21:17:25 +0100 > From: "kammerath i. (ik3g09)" > Subject: Research into modifications on the primordial class loader > To: "hotspot-runtime-dev at openjdk.java.net" > ? ? ? ?, "hotspot-dev at openjdk.java.net" > ? ? ? ?, "core-libs-dev at openjdk.java.net" > ? ? ? ? > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset="us-ascii" > > Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members, > > After initial contact with core-libs-owner, I have been able to get a lot further. > The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. > > When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). > > Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. > > Where am I: > > Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not). > > Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play? > I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"? > > I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. > > Many thanks in advance > Ivo > ________________________________________ > From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu] > Sent: 01 August 2010 03:35 > To: kammerath i. (ik3g09) > Subject: RE: Research on the primordial class loader > > Hi, Ivo. > > I didn't receive your original message. ?I don't know what happened as it > isn't in the set of pending moderator requests and your message didn't seem > to make it into our archive (see the "archive link") near the top of this > page: ?http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > > One way to avoid the need for moderation is to become a subscriber. ?There > is a digest mode if you get inundated with mail. ?Alternatively, you could > just unsubscribe as soon as you get the information you need. > > I think that core-libs-dev is a fine place to ask your question. > Alternatively hotspot-dev or hotspot-runtime-dev may also be good > candidates as that is where a great deal of heavy lifting occurs for class > loading. ?Here are some pointers for you to begin your investigation. ?I've > selected subversion files from the JDK7 tl repository, but these files will > reside in similar locations in other JDK repositories. > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j > ava/lang/ClassLoader.java > ?java.lang.ClassLoader provides the specification for the delegation model > ?and is the primary implementation. ?Note that specification comments such > ?as this: ?"If the parent is "null", the class loader built-in to the > ?virtual machine..." and the corresponding null checks are references to > ?class loader implemented by the VM. > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja > va/lang/ClassLoader.c > ?The supporting libraries C code for j.l.ClassLoader. ?This is where > ?libraries makes the calls into the VM. > > http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl > assfile/ > ?I am by no means a VM expert, but I believe that this is where the VM > ?implements most of class loading. ?A VM engineer will be able to provide > ?more details. > > http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html > ?I'm sure you've' already found it, but just in case... The VM > specification, > ?Chapter 5 contains the complete spec for loading, linking, and > initializing: > > Hope this gets you started. ?My apologies for not seeing your earlier > message. > > Thanks, > iris > ________________________________________ > From: Ivo > Sent: 29 July 2010 17:15 > To: core-libs-dev at openjdk.java.net > Subject: Research on the primordial class loader > > Hello core-libs-dev members, > > In my research on dynamic continuous integration at run-time and dynamic > self-modification. > I reached a point where I would like to have a look at the implementation of > the 'Primordial ClassLoader'. > Which, according to what I read so far, is responsible for loading all > classes, excluding those loaded by any > custom ClassLaoder. > > When I downloaded the OpenJDK source I felt a little lost, I could not quite > work out where to look. > As far as I understood, ?the Primordial ClassLoader is more than just a > bunch of Java classes. > Correct me if I am wrong, but I assume it involves a few C/C++ > classes/procedures? > > So my question is: > Which classes are involved in the primordial classloading and which files of > the HotSpot are involved in the process? > > many thanks in advance > Ivo > From vladimir.kozlov at oracle.com Mon Aug 2 22:45:10 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Aug 2010 22:45:10 -0700 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] In-Reply-To: <4C574904.2050307@oracle.com> References: <4C57401E.5040204@oracle.com> <4C574904.2050307@oracle.com> Message-ID: <4C57ACE6.6090702@oracle.com> I updated webrev: http://cr.openjdk.java.net/~kvn/6973963/webrev.01 Additional changes: 1. Used new option StressRecompilation instead of CompileTheWorld. I am still not sure if it is OK since we never test our stress options. 2. Added new allocation type: STACK_OR_EMBEDDED for cases when new() is not called. 3. Added ResourceObj destructor to zap _allocation field. 4. Added assert into get_allocation_type() to check that 'this' address is still encoded in _allocation. Found several cases where it was not true, have to add copy constructor and assignment operator. 5. Moved all new methods with asserts into allocation.cpp. 6. The added assert failed for CodeBuffer since it destroys itself inside destructor before ResourceObj destructor called. Moved Copy::fill_to_bytes(badResourceValue) into CodeBuffer::operator delete(). 7. Replaced PhaseCFG::_node_latency field with pointer since it is valid only inside resource mark in GlobalCodeMotion(). Thanks, Vladimir Vladimir Kozlov wrote: > Thank you, Tom > > RESOURCE_AREA case combines 3 cases: > > GrowableArray *foo = new GrowableArray(size); // resource > array allocation > > GrowableArray foo; // stack allocation > > class A : public ResourceObj { > GrowableArray foo; // embedding allocation > } > > In all this cases GrowableArray::_data array is allocated in thread local > resource area. GrowableArray calls all these cases as stack allocation > and I followed this naming. > > But you are right I can separate 2 last cases into "stack" (stack or > embedding) > allocation, I still have 1 bit in allocation_type :) > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> So doesn't this triple the amount of time taken by CTW? That seems >> kind of extreme for the default mode. Maybe it should be under a >> flag? The allocation.hpp changes look a little sketchy. >> + if (~(_allocation | allocation_mask) != (uintptr_t)this) { >> + set_allocation_type((address)this, RESOURCE_AREA); >> >> Why is this case called RESOURCE_AREA? Isn't this the stack or >> embedding case? >> >> This doesn't make sense either. >> >> ! bool allocated_on_stack() { return get_allocation_type() == >> RESOURCE_AREA; } >> >> Anyway, the existing logic around this seemed sketchy so I can't quite >> say whether this is better or not. I'll have to leave that to someone >> else. >> >> The GrowableArray changes themselves look fine. >> >> tom >> >> On Aug 2, 2010, at 3:01 PM, Vladimir Kozlov wrote: >> >>> Forwarding to GC and Runtime groups since it is common code. >>> >>> Vladimir >>> >>> -------- Original Message -------- >>> Subject: Request for reviews (M): 6973963: SEGV in >>> ciBlock::start_bci() with EA >>> Date: Mon, 02 Aug 2010 14:57:25 -0700 >>> From: Vladimir Kozlov >>> To: hotspot compiler >>> >>> http://cr.openjdk.java.net/~kvn/6973963/webrev >>> >>> Fixed 6973963: SEGV in ciBlock::start_bci() with EA >>> >>> I added stress recompilation during CompileTheWorld and found this case. >>> It is similar to 6968368. BCEscapeAnalyzer::do_analysis() calls >>> ciMethod::get_method_blocks() which calls constructor ciMethodBlocks. >>> This constructor allocates GrowableArray elements on stack (thread >>> local resource area). As result when the method recompiled without EA >>> _blocks->_data is NULL. >>> >>> Solution: >>> Added stress recompilation during CompileTheWorld: recompile with >>> subsume_loads = false and do_escape_analysis = false. >>> Added more checks into ResourceObj and growableArray to verify >>> correctness >>> of allocation. I have to relax the new assert in GrowableArray when >>> elements are allocated on arena to allow allocattion of GrowableArray >>> object >>> as a part of an other object (for example, in ConnectionGraph and >>> SuperWord). >>> >>> Tested with failed cases, CTW. >> From David.Holmes at oracle.com Mon Aug 2 23:23:12 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 03 Aug 2010 16:23:12 +1000 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] In-Reply-To: <4C57ACE6.6090702@oracle.com> References: <4C57401E.5040204@oracle.com> <4C574904.2050307@oracle.com> <4C57ACE6.6090702@oracle.com> Message-ID: <4C57B5D0.4090807@oracle.com> Hi Vladimir, I always get nervous when people start tweaking these fundamental allocation classes - there are always unforeseen interactions. :) This is only a partial review. src/share/vm/asm/codeBuffer.cpp + void CodeBuffer::operator delete(void* p) { + ResourceObj::operator delete(p); #ifdef ASSERT ! Copy::fill_to_bytes(p, sizeof(CodeBuffer), badResourceValue); #endif } You moved the copy from the destructor to operator delete, but now you access p after you have deleted it. src/share/vm/utilities/growableArray.hpp + // on stack or ebedded into an other object. Typo: embedded src/share/vm/memory/allocation.hpp ! ~ResourceObj(); You've added a destructor, but subclasses define their own destructors - so doesn't this need to be virtual? src/share/vm/memory/allocation.cpp + #ifdef ASSERT + ((ResourceObj *)p)->_allocation = badHeapOopVal; + #endif // ASSERT For consistency this should be a DEBUG_ONLY(...) + assert((allocation & allocation_mask) == 0, ""); + assert(type <= allocation_mask, ""); Please give meaningful messages to assertion failures. David ----- Vladimir Kozlov said the following on 08/03/10 15:45: > I updated webrev: > > http://cr.openjdk.java.net/~kvn/6973963/webrev.01 > > Additional changes: > > 1. Used new option StressRecompilation instead of CompileTheWorld. > I am still not sure if it is OK since we never test our stress options. > > 2. Added new allocation type: STACK_OR_EMBEDDED for cases when new() is > not called. > > 3. Added ResourceObj destructor to zap _allocation field. > > 4. Added assert into get_allocation_type() to check that 'this' address > is still encoded in _allocation. > Found several cases where it was not true, have to add copy > constructor and assignment operator. > > 5. Moved all new methods with asserts into allocation.cpp. > > 6. The added assert failed for CodeBuffer since it destroys itself > inside destructor before ResourceObj destructor called. > Moved Copy::fill_to_bytes(badResourceValue) into CodeBuffer::operator > delete(). > > 7. Replaced PhaseCFG::_node_latency field with pointer since it is valid > only inside resource mark in GlobalCodeMotion(). > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Thank you, Tom >> >> RESOURCE_AREA case combines 3 cases: >> >> GrowableArray *foo = new GrowableArray(size); // resource >> array allocation >> >> GrowableArray foo; // stack allocation >> >> class A : public ResourceObj { >> GrowableArray foo; // embedding allocation >> } >> >> In all this cases GrowableArray::_data array is allocated in thread local >> resource area. GrowableArray calls all these cases as stack allocation >> and I followed this naming. >> >> But you are right I can separate 2 last cases into "stack" (stack or >> embedding) >> allocation, I still have 1 bit in allocation_type :) >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> So doesn't this triple the amount of time taken by CTW? That seems >>> kind of extreme for the default mode. Maybe it should be under a >>> flag? The allocation.hpp changes look a little sketchy. + if >>> (~(_allocation | allocation_mask) != (uintptr_t)this) { >>> + set_allocation_type((address)this, RESOURCE_AREA); >>> >>> Why is this case called RESOURCE_AREA? Isn't this the stack or >>> embedding case? >>> >>> This doesn't make sense either. >>> >>> ! bool allocated_on_stack() { return get_allocation_type() == >>> RESOURCE_AREA; } >>> >>> Anyway, the existing logic around this seemed sketchy so I can't >>> quite say whether this is better or not. I'll have to leave that to >>> someone else. >>> >>> The GrowableArray changes themselves look fine. >>> >>> tom >>> >>> On Aug 2, 2010, at 3:01 PM, Vladimir Kozlov wrote: >>> >>>> Forwarding to GC and Runtime groups since it is common code. >>>> >>>> Vladimir >>>> >>>> -------- Original Message -------- >>>> Subject: Request for reviews (M): 6973963: SEGV in >>>> ciBlock::start_bci() with EA >>>> Date: Mon, 02 Aug 2010 14:57:25 -0700 >>>> From: Vladimir Kozlov >>>> To: hotspot compiler >>>> >>>> http://cr.openjdk.java.net/~kvn/6973963/webrev >>>> >>>> Fixed 6973963: SEGV in ciBlock::start_bci() with EA >>>> >>>> I added stress recompilation during CompileTheWorld and found this >>>> case. >>>> It is similar to 6968368. BCEscapeAnalyzer::do_analysis() calls >>>> ciMethod::get_method_blocks() which calls constructor ciMethodBlocks. >>>> This constructor allocates GrowableArray elements on stack (thread >>>> local resource area). As result when the method recompiled without EA >>>> _blocks->_data is NULL. >>>> >>>> Solution: >>>> Added stress recompilation during CompileTheWorld: recompile with >>>> subsume_loads = false and do_escape_analysis = false. >>>> Added more checks into ResourceObj and growableArray to verify >>>> correctness >>>> of allocation. I have to relax the new assert in GrowableArray when >>>> elements are allocated on arena to allow allocattion of >>>> GrowableArray object >>>> as a part of an other object (for example, in ConnectionGraph and >>>> SuperWord). >>>> >>>> Tested with failed cases, CTW. >>> From vladimir.kozlov at oracle.com Tue Aug 3 02:33:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Aug 2010 02:33:28 -0700 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] In-Reply-To: <4C57B5D0.4090807@oracle.com> References: <4C57401E.5040204@oracle.com> <4C574904.2050307@oracle.com> <4C57ACE6.6090702@oracle.com> <4C57B5D0.4090807@oracle.com> Message-ID: <4C57E268.5060602@oracle.com> Thank you, Dave On 8/2/10 11:23 PM, David Holmes wrote: > Hi Vladimir, > > I always get nervous when people start tweaking these fundamental allocation classes - there are always unforeseen > interactions. :) I hate to touch it also. But my patience was broken when I found this problem. > > This is only a partial review. > > src/share/vm/asm/codeBuffer.cpp > > + void CodeBuffer::operator delete(void* p) { > + ResourceObj::operator delete(p); > #ifdef ASSERT > ! Copy::fill_to_bytes(p, sizeof(CodeBuffer), badResourceValue); > #endif > } > > You moved the copy from the destructor to operator delete, but now you access p after you have deleted it. Yes, you are right. But CodeBuffer is never allocated on C heap and ResourceObj::delete(p) should be called only for allocation on C_HEAP. So this code should never be executed, I will replace it with ShouldNotCallThis() in CodeBuffer::delete(void* p). Which leaves the original problem: I need to find how to zap CodeBuffer after ResourceObj destructor which is called after CodeBuffer destructor. Note: the problem here is not CodeBuffer but its field: OopRecorder _default_oop_recorder; > > src/share/vm/utilities/growableArray.hpp > > + // on stack or ebedded into an other object. > > Typo: embedded OK. > > src/share/vm/memory/allocation.hpp > > ! ~ResourceObj(); > > You've added a destructor, but subclasses define their own destructors - so doesn't this need to be virtual? Constructor and destructor are special methods. Super class's default destructor are always called from subclass's destructor. The only case when you need to declare it as virtual if subclass object is assigned to local/field of super class type and compiler does not know what the original subclass was. ResourceObj *f = new OopRecorder(); ... delete f; We don't use such constructions. > > src/share/vm/memory/allocation.cpp > > + #ifdef ASSERT > + ((ResourceObj *)p)->_allocation = badHeapOopVal; > + #endif // ASSERT > > For consistency this should be a DEBUG_ONLY(...) OK. I had problems recently with some macros when I passed expressions with nested () so I was too conservative here. > > + assert((allocation & allocation_mask) == 0, ""); > + assert(type <= allocation_mask, ""); > > Please give meaningful messages to assertion failures. OK. I will update webrev today (during work hours :) ). Thanks, Vladimir > > David > ----- > > Vladimir Kozlov said the following on 08/03/10 15:45: >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/6973963/webrev.01 >> >> Additional changes: >> >> 1. Used new option StressRecompilation instead of CompileTheWorld. >> I am still not sure if it is OK since we never test our stress options. >> >> 2. Added new allocation type: STACK_OR_EMBEDDED for cases when new() is not called. >> >> 3. Added ResourceObj destructor to zap _allocation field. >> >> 4. Added assert into get_allocation_type() to check that 'this' address is still encoded in _allocation. >> Found several cases where it was not true, have to add copy constructor and assignment operator. >> >> 5. Moved all new methods with asserts into allocation.cpp. >> >> 6. The added assert failed for CodeBuffer since it destroys itself inside destructor before ResourceObj destructor >> called. >> Moved Copy::fill_to_bytes(badResourceValue) into CodeBuffer::operator delete(). >> >> 7. Replaced PhaseCFG::_node_latency field with pointer since it is valid only inside resource mark in GlobalCodeMotion(). >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> RESOURCE_AREA case combines 3 cases: >>> >>> GrowableArray *foo = new GrowableArray(size); // resource array allocation >>> >>> GrowableArray foo; // stack allocation >>> >>> class A : public ResourceObj { >>> GrowableArray foo; // embedding allocation >>> } >>> >>> In all this cases GrowableArray::_data array is allocated in thread local >>> resource area. GrowableArray calls all these cases as stack allocation >>> and I followed this naming. >>> >>> But you are right I can separate 2 last cases into "stack" (stack or embedding) >>> allocation, I still have 1 bit in allocation_type :) >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> So doesn't this triple the amount of time taken by CTW? That seems kind of extreme for the default mode. Maybe it >>>> should be under a flag? The allocation.hpp changes look a little sketchy. + if (~(_allocation | allocation_mask) != >>>> (uintptr_t)this) { >>>> + set_allocation_type((address)this, RESOURCE_AREA); >>>> >>>> Why is this case called RESOURCE_AREA? Isn't this the stack or embedding case? >>>> >>>> This doesn't make sense either. >>>> >>>> ! bool allocated_on_stack() { return get_allocation_type() == RESOURCE_AREA; } >>>> >>>> Anyway, the existing logic around this seemed sketchy so I can't quite say whether this is better or not. I'll have >>>> to leave that to someone else. >>>> >>>> The GrowableArray changes themselves look fine. >>>> >>>> tom >>>> >>>> On Aug 2, 2010, at 3:01 PM, Vladimir Kozlov wrote: >>>> >>>>> Forwarding to GC and Runtime groups since it is common code. >>>>> >>>>> Vladimir >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA >>>>> Date: Mon, 02 Aug 2010 14:57:25 -0700 >>>>> From: Vladimir Kozlov >>>>> To: hotspot compiler >>>>> >>>>> http://cr.openjdk.java.net/~kvn/6973963/webrev >>>>> >>>>> Fixed 6973963: SEGV in ciBlock::start_bci() with EA >>>>> >>>>> I added stress recompilation during CompileTheWorld and found this case. >>>>> It is similar to 6968368. BCEscapeAnalyzer::do_analysis() calls >>>>> ciMethod::get_method_blocks() which calls constructor ciMethodBlocks. >>>>> This constructor allocates GrowableArray elements on stack (thread >>>>> local resource area). As result when the method recompiled without EA >>>>> _blocks->_data is NULL. >>>>> >>>>> Solution: >>>>> Added stress recompilation during CompileTheWorld: recompile with >>>>> subsume_loads = false and do_escape_analysis = false. >>>>> Added more checks into ResourceObj and growableArray to verify correctness >>>>> of allocation. I have to relax the new assert in GrowableArray when >>>>> elements are allocated on arena to allow allocattion of GrowableArray object >>>>> as a part of an other object (for example, in ConnectionGraph and SuperWord). >>>>> >>>>> Tested with failed cases, CTW. >>>> From David.Holmes at oracle.com Tue Aug 3 05:13:37 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 03 Aug 2010 22:13:37 +1000 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] In-Reply-To: <4C57E268.5060602@oracle.com> References: <4C57401E.5040204@oracle.com> <4C574904.2050307@oracle.com> <4C57ACE6.6090702@oracle.com> <4C57B5D0.4090807@oracle.com> <4C57E268.5060602@oracle.com> Message-ID: <4C5807F1.1070607@oracle.com> Vladimir Kozlov said the following on 08/03/10 19:33: > On 8/2/10 11:23 PM, David Holmes wrote: >> src/share/vm/asm/codeBuffer.cpp >> >> + void CodeBuffer::operator delete(void* p) { >> + ResourceObj::operator delete(p); >> #ifdef ASSERT >> ! Copy::fill_to_bytes(p, sizeof(CodeBuffer), badResourceValue); >> #endif >> } >> >> You moved the copy from the destructor to operator delete, but now you >> access p after you have deleted it. > > Yes, you are right. But CodeBuffer is never allocated on C heap and > ResourceObj::delete(p) > should be called only for allocation on C_HEAP. So this code should > never be executed, I'm confused. CodeBuffer is a StackObj, not a ResourceObj, so why would you call ResourceObj::delete in the first place ?? > I will replace it with ShouldNotCallThis() in CodeBuffer::delete(void* p). > Which leaves the original problem: I need to find how to zap CodeBuffer > after ResourceObj destructor > which is called after CodeBuffer destructor. Again I'm missing something - what is the connection between CodeBuffer and ResourceObj ? > Note: the problem here is not CodeBuffer but its field: OopRecorder > _default_oop_recorder; Explain that to me off-list if you like, I'm not familiar with this part of the code. >> src/share/vm/memory/allocation.hpp >> >> ! ~ResourceObj(); >> >> You've added a destructor, but subclasses define their own destructors >> - so doesn't this need to be virtual? > > Constructor and destructor are special methods. Super class's default > destructor are always called from > subclass's destructor. The only case when you need to declare it as > virtual if subclass object is assigned to > local/field of super class type and compiler does not know what the > original subclass was. > > ResourceObj *f = new OopRecorder(); > ... > delete f; > > We don't use such constructions. Ok. Just wanted to check. In another codebase we got bitten by a cleanup method in the superclass that did "delete this;" which did not invoke the destructor for the dynamic type of 'this' because the destructor was not virtual. Cheers, David From forax at univ-mlv.fr Tue Aug 3 06:05:32 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 03 Aug 2010 15:05:32 +0200 Subject: Research into modifications on the primordial class loader In-Reply-To: References: Message-ID: <4C58141C.90708@univ-mlv.fr> There is already a patch in mlvm repository for adding/removing fields/methods. see http://wikis.sun.com/display/mlvm/HotSwap R?mi Le 03/08/2010 07:20, Apurba Nath a ?crit : > Hi Ivo > > I am not an expert, read at your own risk, am looking into the same > problem myself. I understand that your original problem was "dynamic > continuous integration at run-time and dynamic self-modification", if > that is the case we are interested in reloading a different version of > the same class, if so unloading the class and loading the new class is > going to be pretty complicated, as we would need to move all the > existing objects from the previous class definition to the new, also > remember its impact on all the classes that extend this. > > I am trying to currently soup up the vtable and itable portions in the > class definition, the idea is that when we provide a new version of an > existing class, we analyse the methods that have been modified and the > ones that have been added and make the corresponding changes in the > vtable. The current vtable implementation needs to be modified to make > it grow dynamically at class levels, if you or anyone else is > interested, can send details of the changes that I am trying to > implement. > > Thanks > Apurba > > > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 2 Aug 2010 21:17:25 +0100 >> From: "kammerath i. (ik3g09)" >> Subject: Research into modifications on the primordial class loader >> To: "hotspot-runtime-dev at openjdk.java.net" >> , "hotspot-dev at openjdk.java.net" >> , "core-libs-dev at openjdk.java.net" >> >> Message-ID: >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members, >> >> After initial contact with core-libs-owner, I have been able to get a lot further. >> The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. >> >> When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). >> >> Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. >> >> Where am I: >> >> Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not). >> >> Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play? >> I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"? >> >> I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. >> >> Many thanks in advance >> Ivo >> ________________________________________ >> From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu] >> Sent: 01 August 2010 03:35 >> To: kammerath i. (ik3g09) >> Subject: RE: Research on the primordial class loader >> >> Hi, Ivo. >> >> I didn't receive your original message. I don't know what happened as it >> isn't in the set of pending moderator requests and your message didn't seem >> to make it into our archive (see the "archive link") near the top of this >> page: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev >> >> One way to avoid the need for moderation is to become a subscriber. There >> is a digest mode if you get inundated with mail. Alternatively, you could >> just unsubscribe as soon as you get the information you need. >> >> I think that core-libs-dev is a fine place to ask your question. >> Alternatively hotspot-dev or hotspot-runtime-dev may also be good >> candidates as that is where a great deal of heavy lifting occurs for class >> loading. Here are some pointers for you to begin your investigation. I've >> selected subversion files from the JDK7 tl repository, but these files will >> reside in similar locations in other JDK repositories. >> >> http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j >> ava/lang/ClassLoader.java >> java.lang.ClassLoader provides the specification for the delegation model >> and is the primary implementation. Note that specification comments such >> as this: "If the parent is "null", the class loader built-in to the >> virtual machine..." and the corresponding null checks are references to >> class loader implemented by the VM. >> >> http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja >> va/lang/ClassLoader.c >> The supporting libraries C code for j.l.ClassLoader. This is where >> libraries makes the calls into the VM. >> >> http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl >> assfile/ >> I am by no means a VM expert, but I believe that this is where the VM >> implements most of class loading. A VM engineer will be able to provide >> more details. >> >> http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html >> I'm sure you've' already found it, but just in case... The VM >> specification, >> Chapter 5 contains the complete spec for loading, linking, and >> initializing: >> >> Hope this gets you started. My apologies for not seeing your earlier >> message. >> >> Thanks, >> iris >> ________________________________________ >> From: Ivo >> Sent: 29 July 2010 17:15 >> To: core-libs-dev at openjdk.java.net >> Subject: Research on the primordial class loader >> >> Hello core-libs-dev members, >> >> In my research on dynamic continuous integration at run-time and dynamic >> self-modification. >> I reached a point where I would like to have a look at the implementation of >> the 'Primordial ClassLoader'. >> Which, according to what I read so far, is responsible for loading all >> classes, excluding those loaded by any >> custom ClassLaoder. >> >> When I downloaded the OpenJDK source I felt a little lost, I could not quite >> work out where to look. >> As far as I understood, the Primordial ClassLoader is more than just a >> bunch of Java classes. >> Correct me if I am wrong, but I assume it involves a few C/C++ >> classes/procedures? >> >> So my question is: >> Which classes are involved in the primordial classloading and which files of >> the HotSpot are involved in the process? >> >> many thanks in advance >> Ivo >> >> From rasbold at google.com Tue Aug 3 09:18:54 2010 From: rasbold at google.com (Chuck Rasbold) Date: Tue, 3 Aug 2010 09:18:54 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. Message-ID: http://cr.openjdk.java.net/~rasbold/6378314/ Fixed: 6378314: Bad warning message when agent library not found. local directory is not searched. Contributed-by: jeremymanson at google.com Print a more detailed error message for agent library load failure. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100803/1fd8af4b/attachment.html From bob.vandette at oracle.com Tue Aug 3 10:21:14 2010 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Tue, 03 Aug 2010 17:21:14 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6953477: Increase portability and flexibility of building Hotspot Message-ID: <20100803172122.A7ABE47EA4@hg.openjdk.java.net> Changeset: 126ea7725993 Author: bobv Date: 2010-08-03 08:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/126ea7725993 6953477: Increase portability and flexibility of building Hotspot Summary: A collection of portability improvements including shared code support for PPC, ARM platforms, software floating point, cross compilation support and improvements in error crash detail. Reviewed-by: phh, never, coleenp, dholmes ! agent/src/os/linux/ps_proc.c ! make/Makefile ! make/defs.make ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/product.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/javaFrameAnchor_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/linux/launcher/java_md.c ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/arrayKlassKlass.hpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassKlass.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp From vladimir.kozlov at oracle.com Tue Aug 3 11:33:38 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Aug 2010 11:33:38 -0700 Subject: [Fwd: Request for reviews (M): 6973963: SEGV in ciBlock::start_bci() with EA] In-Reply-To: <4C5807F1.1070607@oracle.com> References: <4C57401E.5040204@oracle.com> <4C574904.2050307@oracle.com> <4C57ACE6.6090702@oracle.com> <4C57B5D0.4090807@oracle.com> <4C57E268.5060602@oracle.com> <4C5807F1.1070607@oracle.com> Message-ID: <4C586102.3050508@oracle.com> I updated webrev http://cr.openjdk.java.net/~kvn/6973963/webrev.02 I added 'virtual' to ~ResourceObj() to avoid any surprises as Dave pointed. I save/restore allocation type around Copy::fill_to_bytes() in ~CodeBuffer() to solve my problem. Vladimir David Holmes wrote: > Vladimir Kozlov said the following on 08/03/10 19:33: >> On 8/2/10 11:23 PM, David Holmes wrote: >>> src/share/vm/asm/codeBuffer.cpp >>> >>> + void CodeBuffer::operator delete(void* p) { >>> + ResourceObj::operator delete(p); >>> #ifdef ASSERT >>> ! Copy::fill_to_bytes(p, sizeof(CodeBuffer), badResourceValue); >>> #endif >>> } >>> >>> You moved the copy from the destructor to operator delete, but now >>> you access p after you have deleted it. >> >> Yes, you are right. But CodeBuffer is never allocated on C heap and >> ResourceObj::delete(p) >> should be called only for allocation on C_HEAP. So this code should >> never be executed, > > I'm confused. CodeBuffer is a StackObj, not a ResourceObj, so why would > you call ResourceObj::delete in the first place ?? > >> I will replace it with ShouldNotCallThis() in CodeBuffer::delete(void* >> p). >> Which leaves the original problem: I need to find how to zap >> CodeBuffer after ResourceObj destructor >> which is called after CodeBuffer destructor. > > Again I'm missing something - what is the connection between CodeBuffer > and ResourceObj ? > >> Note: the problem here is not CodeBuffer but its field: OopRecorder >> _default_oop_recorder; > > Explain that to me off-list if you like, I'm not familiar with this part > of the code. > >>> src/share/vm/memory/allocation.hpp >>> >>> ! ~ResourceObj(); >>> >>> You've added a destructor, but subclasses define their own >>> destructors - so doesn't this need to be virtual? >> >> Constructor and destructor are special methods. Super class's default >> destructor are always called from >> subclass's destructor. The only case when you need to declare it as >> virtual if subclass object is assigned to >> local/field of super class type and compiler does not know what the >> original subclass was. >> >> ResourceObj *f = new OopRecorder(); >> ... >> delete f; >> >> We don't use such constructions. > > Ok. Just wanted to check. In another codebase we got bitten by a cleanup > method in the superclass that did "delete this;" which did not invoke > the destructor for the dynamic type of 'this' because the destructor was > not virtual. > > Cheers, > David From guanxiaohua at gmail.com Tue Aug 3 16:20:26 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Tue, 3 Aug 2010 18:20:26 -0500 Subject: how to bring jvm to safepoint In-Reply-To: References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> <4C53BB1E.9070401@oracle.com> <4C54ED7D.50202@oracle.com> Message-ID: Hi David, I changed dtrace_method_exit to JRT_ENTRY from JRT_LEAF, and still stopped by the same failure. Does it have anything to do with the method sun.misc.Unsafe.park()? Thanks! Tony (Xiaohua Guan) On Sun, Aug 1, 2010 at 3:50 PM, Tony Guan wrote: > Hi David, > > Thanks for the explanation, now I get to understand it. > > Have to say, it's a nice failure for me. :) > > Tony (Xiaohua Guan) > > > > On Sat, Jul 31, 2010 at 10:43 PM, David Holmes wrote: >> Hi Tony, >> >> Now it is all clear :) >> >>> It's exactly how the error occurred, I am monitoring the >>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>> intercepting inside jvm implementation), once this method gets called, >>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>> GC using VMThread::Execute(&op). >> >> Right, you are using: >> >> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >> >> but dtrace_method_exit is defined as a runtime "leaf" method (JRT_LEAF). >> "leaf" methods are not allowed to perform certain actions and in debug mode >> we have JRT_Leaf_Verifier that is used to check those actions. A >> JRT_Leaf_Verifier is a No_Safepoint_Verifier - hence as I said before you >> get the assertion failure due to this. >> >> When you do the VMThread::execute to initiate the safepoint operation for >> your GC action, the current thread will block waiting for it to complete. >> Part of that blocking involves a safepoint check and hence the system finds >> that the thread is attempting to enter a safepoint from a "leaf" method - >> and that is not allowed. >> >> You might just try changing the definition of dtrace_method_exit to be >> JRT_ENTRY rather than JRT_LEAF, but I don't know if that will have >> unexpected side-effects. >> >> There are lots of rules (not necessarily clearly documented) that control >> how you can call into the VM runtime and how different parts of the VM >> runtime can call other parts of the runtime. >> >> Cheers, >> David Holmes >> >> Tony Guan said the following on 08/01/10 08:10: >>> >>> Hi David & Tom, >>> >>> Please see the decoded stack below(also full decoded log is attached): >>> >>> " >>> Current thread (0x00000000012ed000): ?JavaThread "RMI TCP >>> Connection(idle)" daemon [_thread_in_Java, id=30929, >>> stack(0x000000004073b000,0x000000004083c000)] >>> >>> Stack: [0x000000004073b000,0x000000004083c000], >>> sp=0x0000000040839d60, ?free space=3fb0000000000000000k >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>> code) >>> V ?[libjvm.so+0x8cad18];; ?_ZN7VMError6reportEP12outputStream+0xb72 >>> V ?[libjvm.so+0x8cbe38];; ?_ZN7VMError14report_and_dieEv+0x5f6 >>> V ?[libjvm.so+0x4039f1];; ?_Z12report_fatalPKciS0_+0x6b >>> V ?[libjvm.so+0x87a183];; >>> ?_ZN6Thread31check_for_valid_safepoint_stateEb+0x33 >>> V ?[libjvm.so+0x8e1127];; ?_ZN8VMThread7executeEP12VM_Operation+0x49 >>> V ?[libjvm.so+0x4d52ab];; >>> _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 >>> V ?[libjvm.so+0x7ee63d];; >>> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >>> j ?sun.misc.Unsafe.park(ZJ)V+0 >>> j >>> ?java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>> j >>> ?java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>> j >>> ?java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>> j >>> ?java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>> j >>> ?java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>> j >>> ?java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>> j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 >>> j ?java.lang.Thread.run()V+11 >>> v ?~StubRoutines::call_stub >>> V ?[libjvm.so+0x555ecc];; >>> >>> _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 >>> V ?[libjvm.so+0x747a34];; >>> >>> _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 >>> V ?[libjvm.so+0x554b55];; >>> >>> _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f >>> V ?[libjvm.so+0x5551f0];; >>> >>> _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 >>> V ?[libjvm.so+0x5553cc];; >>> >>> _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 >>> V ?[libjvm.so+0x5be6cd];; ?_Z12thread_entryP10JavaThreadP6Thread+0x9f >>> V ?[libjvm.so+0x879869];; ?_ZN10JavaThread17thread_main_innerEv+0xc9 >>> V ?[libjvm.so+0x87c1b5];; ?_ZN10JavaThread3runEv+0x2c1 >>> V ?[libjvm.so+0x750455];; ?_Z10java_startP6Thread+0x16f >>> " >>> >>> It's exactly how the error occurred, I am monitoring the >>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>> intercepting inside jvm implementation), once this method gets called, >>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>> GC using VMThread::Execute(&op). >>> >>> At the beginning of VMTHread::Execute(), >>> check_for_valid_safepoint_state is called like this: >>> >>> void VMThread::execute(VM_Operation* op) { >>> ?Thread* t = Thread::current(); >>> ?if (!t->is_VM_thread()) { >>> ? ?// JavaThread or WatcherThread >>> ? ?t->check_for_valid_safepoint_state(true); ?//And we failed here!! >>> ? ?// New request from Java thread, evaluate prologue >>> ? ?if (!op->doit_prologue()) { >>> ? ? ?return; ? // op was cancelled >>> ? ?} >>> ... >>> } >>> >>> That's why I said the current thread is not a VM_thread. I think I can >>> make a workaround by invoking the GC at the next allocation request, >>> which should be in the safepoint. But would be great if I can learn >>> more about hotspot solving this problem. >>> >>> Thanks a lot! >>> >>> Tony (Xiaohua Guan) >>> >>> >>> >>> On Sat, Jul 31, 2010 at 12:56 AM, David Holmes >>> wrote: >>>> >>>> Tom Rodriguez said the following on 07/31/10 05:01: >>>>> >>>>> Actually I think the problem is that the thread is in thread_in_Java >>>>> state. I don't believe you can safepoint from that state, only >>>>> thread_in_vm. >>>> >>>> The reported failure: >>>> >>>> # ?Error: Possible safepoint reached by thread that does not allow it >>>> >>>> is here: >>>> >>>> void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) >>>> { >>>> ? // Check if current thread is allowed to block at a safepoint >>>> ? if (!(_allow_safepoint_count == 0)) >>>> ? ? fatal("Possible safepoint reached by thread that does not allow it"); >>>> >>>> as far as I can see the only code that touches _allow_safepoint_count are >>>> the No_Safepoint_Verifier classes. >>>> >>>> Also the stack shows: >>>> >>>> V ?[libjvm.so+0x7ee63d] >>>> j ?sun.misc.Unsafe.park(ZJ)V+0 >>>> >>>> and so we should have transitioned to _thread_in_vm here. >>>> >>>> That said, Tony also stated: >>>> >>>>> The reason for the fail is that >>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>> the currentThread is not a VMThread. >>>> >>>> But that is not supported by the error produced. >>>> >>>> Tony: why did you make the above comment? >>>> >>>> Either way we need to see a decoded stack to get an idea of what is going >>>> wrong. >>>> >>>> Cheers, >>>> David >>>> >>>>> tom >>>>> >>>>> On Jul 30, 2010, at 12:04 AM, David Holmes >>>>> wrote: >>>>> >>>>>> Sorry Tony I keep forgetting that I don't have a way to decode a >>>>>> crash log from a VM that you built yourself. :( However you may be >>>>>> able to decode it yourself please see: >>>>>> >>>>>> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >>>>>> >>>>>> for a perl script. >>>>>> >>>>>> That said looking at the actual assertion failure I am guessing >>>>>> that you initiated the VM operation from code where a >>>>>> No_Safepoint_verifier is active. >>>>>> >>>>>> David >>>>>> >>>>>> Tony Guan said the following on 07/30/10 15:58: >>>>>>> >>>>>>> Hi David, Thanks a lot! I am copying the content to below, and >>>>>>> for convenience, the full log file is attached. cat >>>>>>> hs_err_pid30894.log # # A fatal error has been detected by the >>>>>>> Java Runtime Environment: # # ?Internal Error >>>>>>> >>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>> ?pid=30894, tid=1082374480 # ?Error: Possible safepoint reached >>>>>>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>>>>>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>>>>>> mode linux-amd64 ) # If you would like to submit a bug report, >>>>>>> please visit: # ? http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>> ?# --------------- ?T H R E A D ?--------------- Current thread >>>>>>> (0x00000000012ed000): ?JavaThread "RMI TCP Connection(idle)" >>>>>>> daemon [_thread_in_Java, id=30929, >>>>>>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>>>>>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>>>>>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>>>>>> code, j=interpreted, Vv=VM code, C=native code) V >>>>>>> [libjvm.so+0x8cad18] V ?[libjvm.so+0x8cbe38] V >>>>>>> [libjvm.so+0x4039f1] V ?[libjvm.so+0x87a183] V >>>>>>> [libjvm.so+0x8e1127] V ?[libjvm.so+0x4d52ab] V >>>>>>> [libjvm.so+0x7ee63d] j ?sun.misc.Unsafe.park(ZJ)V+0 j >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>>>> ?j >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>>>> ?j >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>>>> ?j >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>>>> ?j >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>>>> ?j >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>>>> ?j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>>>>>> java.lang.Thread.run()V+11 v ?~StubRoutines::call_stub V >>>>>>> [libjvm.so+0x555ecc] V ?[libjvm.so+0x747a34] V >>>>>>> [libjvm.so+0x554b55] V ?[libjvm.so+0x5551f0] V >>>>>>> [libjvm.so+0x5553cc] V ?[libjvm.so+0x5be6cd] V >>>>>>> [libjvm.so+0x879869] V ?[libjvm.so+0x87c1b5] V >>>>>>> [libjvm.so+0x750455] .... (above is the stack, please see the >>>>>>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>>>>>> 29, 2010 at 8:07 PM, David Holmes >>>>>>> wrote: >>>>>>>> >>>>>>>> Tony, >>>>>>>> >>>>>>>> I don't see anything obviously wrong with what you attempted. >>>>>>>> Can you show the full stack dump from the error. >>>>>>>> >>>>>>>> David Holmes >>>>>>>> >>>>>>>> Tony Guan said the following on 07/30/10 07:29: >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> I want to invoke the GC at a certain time, for example, when >>>>>>>>> a certain method is called at runtime, so I created a new >>>>>>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>>>>>> object op, finally, executed using:VMThread::execute(&op) >>>>>>>>> >>>>>>>>> then I got the following error message: >>>>>>>>> >>>>>>>>> # ?Internal Error >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>>> ?pid=29652, tid=1096460624 # ?Error: Possible safepoint >>>>>>>>> reached by thread that does not allow it >>>>>>>>> >>>>>>>>> The reason for the fail is that >>>>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>>>> the currentThread is not a VMThread. >>>>>>>>> >>>>>>>>> My question is: how do I bring the current thread to a >>>>>>>>> safepoint? or how do I call a GC operation properly? is there >>>>>>>>> any prerequisite for doing so? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Tony (Xiaohua Guan) >> > From John.Coomes at oracle.com Tue Aug 3 16:36:23 2010 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 3 Aug 2010 16:36:23 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: References: Message-ID: <19544.42999.632063.746834@oracle.com> Chuck Rasbold (rasbold at google.com) wrote: > http://cr.openjdk.java.net/~rasbold/6378314/ > > Fixed: 6378314: Bad warning message when agent library not found. local > directory is not searched. > Contributed-by: jeremymanson at google.com > > Print a more detailed error message for agent library load failure. Hi Chuck & Jeremy, Looks ok to me, aside from a couple of nits: use jio_snprintf instead of sprintf, and strlen returns a size_t, so use that to declare len. -John From guanxiaohua at gmail.com Tue Aug 3 16:38:32 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Tue, 3 Aug 2010 18:38:32 -0500 Subject: how to bring jvm to safepoint In-Reply-To: References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> <4C53BB1E.9070401@oracle.com> <4C54ED7D.50202@oracle.com> Message-ID: Hi Everyone, Please ignore my previous message, I just forgot to update the jvm for testing. Actually, changing dtrace_method_exit to be JRT_ENTRY solved the problem! It works out. Thank you, David! Cheers! Tony (Xiaohua Guan) On Tue, Aug 3, 2010 at 6:20 PM, Tony Guan wrote: > Hi David, > > I changed dtrace_method_exit to JRT_ENTRY from JRT_LEAF, and still > stopped by the same failure. Does it have anything to do with the > method sun.misc.Unsafe.park()? > > Thanks! > > Tony (Xiaohua Guan) > > > > On Sun, Aug 1, 2010 at 3:50 PM, Tony Guan wrote: >> Hi David, >> >> Thanks for the explanation, now I get to understand it. >> >> Have to say, it's a nice failure for me. :) >> >> Tony (Xiaohua Guan) >> >> >> >> On Sat, Jul 31, 2010 at 10:43 PM, David Holmes wrote: >>> Hi Tony, >>> >>> Now it is all clear :) >>> >>>> It's exactly how the error occurred, I am monitoring the >>>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>>> intercepting inside jvm implementation), once this method gets called, >>>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>>> GC using VMThread::Execute(&op). >>> >>> Right, you are using: >>> >>> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >>> >>> but dtrace_method_exit is defined as a runtime "leaf" method (JRT_LEAF). >>> "leaf" methods are not allowed to perform certain actions and in debug mode >>> we have JRT_Leaf_Verifier that is used to check those actions. A >>> JRT_Leaf_Verifier is a No_Safepoint_Verifier - hence as I said before you >>> get the assertion failure due to this. >>> >>> When you do the VMThread::execute to initiate the safepoint operation for >>> your GC action, the current thread will block waiting for it to complete. >>> Part of that blocking involves a safepoint check and hence the system finds >>> that the thread is attempting to enter a safepoint from a "leaf" method - >>> and that is not allowed. >>> >>> You might just try changing the definition of dtrace_method_exit to be >>> JRT_ENTRY rather than JRT_LEAF, but I don't know if that will have >>> unexpected side-effects. >>> >>> There are lots of rules (not necessarily clearly documented) that control >>> how you can call into the VM runtime and how different parts of the VM >>> runtime can call other parts of the runtime. >>> >>> Cheers, >>> David Holmes >>> >>> Tony Guan said the following on 08/01/10 08:10: >>>> >>>> Hi David & Tom, >>>> >>>> Please see the decoded stack below(also full decoded log is attached): >>>> >>>> " >>>> Current thread (0x00000000012ed000): ?JavaThread "RMI TCP >>>> Connection(idle)" daemon [_thread_in_Java, id=30929, >>>> stack(0x000000004073b000,0x000000004083c000)] >>>> >>>> Stack: [0x000000004073b000,0x000000004083c000], >>>> sp=0x0000000040839d60, ?free space=3fb0000000000000000k >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>>> code) >>>> V ?[libjvm.so+0x8cad18];; ?_ZN7VMError6reportEP12outputStream+0xb72 >>>> V ?[libjvm.so+0x8cbe38];; ?_ZN7VMError14report_and_dieEv+0x5f6 >>>> V ?[libjvm.so+0x4039f1];; ?_Z12report_fatalPKciS0_+0x6b >>>> V ?[libjvm.so+0x87a183];; >>>> ?_ZN6Thread31check_for_valid_safepoint_stateEb+0x33 >>>> V ?[libjvm.so+0x8e1127];; ?_ZN8VMThread7executeEP12VM_Operation+0x49 >>>> V ?[libjvm.so+0x4d52ab];; >>>> _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 >>>> V ?[libjvm.so+0x7ee63d];; >>>> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >>>> j ?sun.misc.Unsafe.park(ZJ)V+0 >>>> j >>>> ?java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>> j >>>> ?java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>> j >>>> ?java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>> j >>>> ?java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>> j >>>> ?java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>> j >>>> ?java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>> j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 >>>> j ?java.lang.Thread.run()V+11 >>>> v ?~StubRoutines::call_stub >>>> V ?[libjvm.so+0x555ecc];; >>>> >>>> _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 >>>> V ?[libjvm.so+0x747a34];; >>>> >>>> _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 >>>> V ?[libjvm.so+0x554b55];; >>>> >>>> _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f >>>> V ?[libjvm.so+0x5551f0];; >>>> >>>> _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 >>>> V ?[libjvm.so+0x5553cc];; >>>> >>>> _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 >>>> V ?[libjvm.so+0x5be6cd];; ?_Z12thread_entryP10JavaThreadP6Thread+0x9f >>>> V ?[libjvm.so+0x879869];; ?_ZN10JavaThread17thread_main_innerEv+0xc9 >>>> V ?[libjvm.so+0x87c1b5];; ?_ZN10JavaThread3runEv+0x2c1 >>>> V ?[libjvm.so+0x750455];; ?_Z10java_startP6Thread+0x16f >>>> " >>>> >>>> It's exactly how the error occurred, I am monitoring the >>>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>>> intercepting inside jvm implementation), once this method gets called, >>>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>>> GC using VMThread::Execute(&op). >>>> >>>> At the beginning of VMTHread::Execute(), >>>> check_for_valid_safepoint_state is called like this: >>>> >>>> void VMThread::execute(VM_Operation* op) { >>>> ?Thread* t = Thread::current(); >>>> ?if (!t->is_VM_thread()) { >>>> ? ?// JavaThread or WatcherThread >>>> ? ?t->check_for_valid_safepoint_state(true); ?//And we failed here!! >>>> ? ?// New request from Java thread, evaluate prologue >>>> ? ?if (!op->doit_prologue()) { >>>> ? ? ?return; ? // op was cancelled >>>> ? ?} >>>> ... >>>> } >>>> >>>> That's why I said the current thread is not a VM_thread. I think I can >>>> make a workaround by invoking the GC at the next allocation request, >>>> which should be in the safepoint. But would be great if I can learn >>>> more about hotspot solving this problem. >>>> >>>> Thanks a lot! >>>> >>>> Tony (Xiaohua Guan) >>>> >>>> >>>> >>>> On Sat, Jul 31, 2010 at 12:56 AM, David Holmes >>>> wrote: >>>>> >>>>> Tom Rodriguez said the following on 07/31/10 05:01: >>>>>> >>>>>> Actually I think the problem is that the thread is in thread_in_Java >>>>>> state. I don't believe you can safepoint from that state, only >>>>>> thread_in_vm. >>>>> >>>>> The reported failure: >>>>> >>>>> # ?Error: Possible safepoint reached by thread that does not allow it >>>>> >>>>> is here: >>>>> >>>>> void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) >>>>> { >>>>> ? // Check if current thread is allowed to block at a safepoint >>>>> ? if (!(_allow_safepoint_count == 0)) >>>>> ? ? fatal("Possible safepoint reached by thread that does not allow it"); >>>>> >>>>> as far as I can see the only code that touches _allow_safepoint_count are >>>>> the No_Safepoint_Verifier classes. >>>>> >>>>> Also the stack shows: >>>>> >>>>> V ?[libjvm.so+0x7ee63d] >>>>> j ?sun.misc.Unsafe.park(ZJ)V+0 >>>>> >>>>> and so we should have transitioned to _thread_in_vm here. >>>>> >>>>> That said, Tony also stated: >>>>> >>>>>> The reason for the fail is that >>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>> the currentThread is not a VMThread. >>>>> >>>>> But that is not supported by the error produced. >>>>> >>>>> Tony: why did you make the above comment? >>>>> >>>>> Either way we need to see a decoded stack to get an idea of what is going >>>>> wrong. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> tom >>>>>> >>>>>> On Jul 30, 2010, at 12:04 AM, David Holmes >>>>>> wrote: >>>>>> >>>>>>> Sorry Tony I keep forgetting that I don't have a way to decode a >>>>>>> crash log from a VM that you built yourself. :( However you may be >>>>>>> able to decode it yourself please see: >>>>>>> >>>>>>> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >>>>>>> >>>>>>> for a perl script. >>>>>>> >>>>>>> That said looking at the actual assertion failure I am guessing >>>>>>> that you initiated the VM operation from code where a >>>>>>> No_Safepoint_verifier is active. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> Tony Guan said the following on 07/30/10 15:58: >>>>>>>> >>>>>>>> Hi David, Thanks a lot! I am copying the content to below, and >>>>>>>> for convenience, the full log file is attached. cat >>>>>>>> hs_err_pid30894.log # # A fatal error has been detected by the >>>>>>>> Java Runtime Environment: # # ?Internal Error >>>>>>>> >>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>> ?pid=30894, tid=1082374480 # ?Error: Possible safepoint reached >>>>>>>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>>>>>>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>>>>>>> mode linux-amd64 ) # If you would like to submit a bug report, >>>>>>>> please visit: # ? http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>> ?# --------------- ?T H R E A D ?--------------- Current thread >>>>>>>> (0x00000000012ed000): ?JavaThread "RMI TCP Connection(idle)" >>>>>>>> daemon [_thread_in_Java, id=30929, >>>>>>>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>>>>>>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>>>>>>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>>>>>>> code, j=interpreted, Vv=VM code, C=native code) V >>>>>>>> [libjvm.so+0x8cad18] V ?[libjvm.so+0x8cbe38] V >>>>>>>> [libjvm.so+0x4039f1] V ?[libjvm.so+0x87a183] V >>>>>>>> [libjvm.so+0x8e1127] V ?[libjvm.so+0x4d52ab] V >>>>>>>> [libjvm.so+0x7ee63d] j ?sun.misc.Unsafe.park(ZJ)V+0 j >>>>>>>> >>>>>>>> >>>>>>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>>>>> ?j >>>>>>>> >>>>>>>> >>>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>>>>> ?j >>>>>>>> >>>>>>>> >>>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>>>>> ?j >>>>>>>> >>>>>>>> >>>>>>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>>>>> ?j >>>>>>>> >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>>>>> ?j >>>>>>>> >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>>>>> ?j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>>>>>>> java.lang.Thread.run()V+11 v ?~StubRoutines::call_stub V >>>>>>>> [libjvm.so+0x555ecc] V ?[libjvm.so+0x747a34] V >>>>>>>> [libjvm.so+0x554b55] V ?[libjvm.so+0x5551f0] V >>>>>>>> [libjvm.so+0x5553cc] V ?[libjvm.so+0x5be6cd] V >>>>>>>> [libjvm.so+0x879869] V ?[libjvm.so+0x87c1b5] V >>>>>>>> [libjvm.so+0x750455] .... (above is the stack, please see the >>>>>>>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>>>>>>> 29, 2010 at 8:07 PM, David Holmes >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Tony, >>>>>>>>> >>>>>>>>> I don't see anything obviously wrong with what you attempted. >>>>>>>>> Can you show the full stack dump from the error. >>>>>>>>> >>>>>>>>> David Holmes >>>>>>>>> >>>>>>>>> Tony Guan said the following on 07/30/10 07:29: >>>>>>>>>> >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> I want to invoke the GC at a certain time, for example, when >>>>>>>>>> a certain method is called at runtime, so I created a new >>>>>>>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>>>>>>> object op, finally, executed using:VMThread::execute(&op) >>>>>>>>>> >>>>>>>>>> then I got the following error message: >>>>>>>>>> >>>>>>>>>> # ?Internal Error >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>>>> ?pid=29652, tid=1096460624 # ?Error: Possible safepoint >>>>>>>>>> reached by thread that does not allow it >>>>>>>>>> >>>>>>>>>> The reason for the fail is that >>>>>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>>>>> the currentThread is not a VMThread. >>>>>>>>>> >>>>>>>>>> My question is: how do I bring the current thread to a >>>>>>>>>> safepoint? or how do I call a GC operation properly? is there >>>>>>>>>> any prerequisite for doing so? >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Tony (Xiaohua Guan) >>> >> > From tom.rodriguez at oracle.com Tue Aug 3 16:51:52 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 3 Aug 2010 16:51:52 -0700 Subject: how to bring jvm to safepoint In-Reply-To: References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> <4C53BB1E.9070401@oracle.com> <4C54ED7D.50202@oracle.com> Message-ID: I suspect this isn't going work properly with compiled code. In general you can't simply change JRT_LEAF to JRT_ENTRY because JRT_ENTRY functions must be called from locations that include proper debug info and we don't emit any for leaf calls. It will likely work for the interpreter since the stack is simpler to walk but I expect you will have problems of some sort. I guess you add debug info to those calls in compiled code but it's not obvious to me where you would get that from. tom On Aug 3, 2010, at 4:38 PM, Tony Guan wrote: > Hi Everyone, > > Please ignore my previous message, I just forgot to update the jvm for testing. > > Actually, changing dtrace_method_exit to be JRT_ENTRY solved the > problem! It works out. > > Thank you, David! > > > Cheers! > > Tony (Xiaohua Guan) > > > > On Tue, Aug 3, 2010 at 6:20 PM, Tony Guan wrote: >> Hi David, >> >> I changed dtrace_method_exit to JRT_ENTRY from JRT_LEAF, and still >> stopped by the same failure. Does it have anything to do with the >> method sun.misc.Unsafe.park()? >> >> Thanks! >> >> Tony (Xiaohua Guan) >> >> >> >> On Sun, Aug 1, 2010 at 3:50 PM, Tony Guan wrote: >>> Hi David, >>> >>> Thanks for the explanation, now I get to understand it. >>> >>> Have to say, it's a nice failure for me. :) >>> >>> Tony (Xiaohua Guan) >>> >>> >>> >>> On Sat, Jul 31, 2010 at 10:43 PM, David Holmes wrote: >>>> Hi Tony, >>>> >>>> Now it is all clear :) >>>> >>>>> It's exactly how the error occurred, I am monitoring the >>>>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>>>> intercepting inside jvm implementation), once this method gets called, >>>>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>>>> GC using VMThread::Execute(&op). >>>> >>>> Right, you are using: >>>> >>>> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >>>> >>>> but dtrace_method_exit is defined as a runtime "leaf" method (JRT_LEAF). >>>> "leaf" methods are not allowed to perform certain actions and in debug mode >>>> we have JRT_Leaf_Verifier that is used to check those actions. A >>>> JRT_Leaf_Verifier is a No_Safepoint_Verifier - hence as I said before you >>>> get the assertion failure due to this. >>>> >>>> When you do the VMThread::execute to initiate the safepoint operation for >>>> your GC action, the current thread will block waiting for it to complete. >>>> Part of that blocking involves a safepoint check and hence the system finds >>>> that the thread is attempting to enter a safepoint from a "leaf" method - >>>> and that is not allowed. >>>> >>>> You might just try changing the definition of dtrace_method_exit to be >>>> JRT_ENTRY rather than JRT_LEAF, but I don't know if that will have >>>> unexpected side-effects. >>>> >>>> There are lots of rules (not necessarily clearly documented) that control >>>> how you can call into the VM runtime and how different parts of the VM >>>> runtime can call other parts of the runtime. >>>> >>>> Cheers, >>>> David Holmes >>>> >>>> Tony Guan said the following on 08/01/10 08:10: >>>>> >>>>> Hi David & Tom, >>>>> >>>>> Please see the decoded stack below(also full decoded log is attached): >>>>> >>>>> " >>>>> Current thread (0x00000000012ed000): JavaThread "RMI TCP >>>>> Connection(idle)" daemon [_thread_in_Java, id=30929, >>>>> stack(0x000000004073b000,0x000000004083c000)] >>>>> >>>>> Stack: [0x000000004073b000,0x000000004083c000], >>>>> sp=0x0000000040839d60, free space=3fb0000000000000000k >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>>>> code) >>>>> V [libjvm.so+0x8cad18];; _ZN7VMError6reportEP12outputStream+0xb72 >>>>> V [libjvm.so+0x8cbe38];; _ZN7VMError14report_and_dieEv+0x5f6 >>>>> V [libjvm.so+0x4039f1];; _Z12report_fatalPKciS0_+0x6b >>>>> V [libjvm.so+0x87a183];; >>>>> _ZN6Thread31check_for_valid_safepoint_stateEb+0x33 >>>>> V [libjvm.so+0x8e1127];; _ZN8VMThread7executeEP12VM_Operation+0x49 >>>>> V [libjvm.so+0x4d52ab];; >>>>> _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 >>>>> V [libjvm.so+0x7ee63d];; >>>>> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >>>>> j sun.misc.Unsafe.park(ZJ)V+0 >>>>> j >>>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>> j >>>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>> j >>>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>> j >>>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>> j >>>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>> j >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>> j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 >>>>> j java.lang.Thread.run()V+11 >>>>> v ~StubRoutines::call_stub >>>>> V [libjvm.so+0x555ecc];; >>>>> >>>>> _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 >>>>> V [libjvm.so+0x747a34];; >>>>> >>>>> _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 >>>>> V [libjvm.so+0x554b55];; >>>>> >>>>> _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f >>>>> V [libjvm.so+0x5551f0];; >>>>> >>>>> _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 >>>>> V [libjvm.so+0x5553cc];; >>>>> >>>>> _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 >>>>> V [libjvm.so+0x5be6cd];; _Z12thread_entryP10JavaThreadP6Thread+0x9f >>>>> V [libjvm.so+0x879869];; _ZN10JavaThread17thread_main_innerEv+0xc9 >>>>> V [libjvm.so+0x87c1b5];; _ZN10JavaThread3runEv+0x2c1 >>>>> V [libjvm.so+0x750455];; _Z10java_startP6Thread+0x16f >>>>> " >>>>> >>>>> It's exactly how the error occurred, I am monitoring the >>>>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>>>> intercepting inside jvm implementation), once this method gets called, >>>>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>>>> GC using VMThread::Execute(&op). >>>>> >>>>> At the beginning of VMTHread::Execute(), >>>>> check_for_valid_safepoint_state is called like this: >>>>> >>>>> void VMThread::execute(VM_Operation* op) { >>>>> Thread* t = Thread::current(); >>>>> if (!t->is_VM_thread()) { >>>>> // JavaThread or WatcherThread >>>>> t->check_for_valid_safepoint_state(true); //And we failed here!! >>>>> // New request from Java thread, evaluate prologue >>>>> if (!op->doit_prologue()) { >>>>> return; // op was cancelled >>>>> } >>>>> ... >>>>> } >>>>> >>>>> That's why I said the current thread is not a VM_thread. I think I can >>>>> make a workaround by invoking the GC at the next allocation request, >>>>> which should be in the safepoint. But would be great if I can learn >>>>> more about hotspot solving this problem. >>>>> >>>>> Thanks a lot! >>>>> >>>>> Tony (Xiaohua Guan) >>>>> >>>>> >>>>> >>>>> On Sat, Jul 31, 2010 at 12:56 AM, David Holmes >>>>> wrote: >>>>>> >>>>>> Tom Rodriguez said the following on 07/31/10 05:01: >>>>>>> >>>>>>> Actually I think the problem is that the thread is in thread_in_Java >>>>>>> state. I don't believe you can safepoint from that state, only >>>>>>> thread_in_vm. >>>>>> >>>>>> The reported failure: >>>>>> >>>>>> # Error: Possible safepoint reached by thread that does not allow it >>>>>> >>>>>> is here: >>>>>> >>>>>> void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) >>>>>> { >>>>>> // Check if current thread is allowed to block at a safepoint >>>>>> if (!(_allow_safepoint_count == 0)) >>>>>> fatal("Possible safepoint reached by thread that does not allow it"); >>>>>> >>>>>> as far as I can see the only code that touches _allow_safepoint_count are >>>>>> the No_Safepoint_Verifier classes. >>>>>> >>>>>> Also the stack shows: >>>>>> >>>>>> V [libjvm.so+0x7ee63d] >>>>>> j sun.misc.Unsafe.park(ZJ)V+0 >>>>>> >>>>>> and so we should have transitioned to _thread_in_vm here. >>>>>> >>>>>> That said, Tony also stated: >>>>>> >>>>>>> The reason for the fail is that >>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>> the currentThread is not a VMThread. >>>>>> >>>>>> But that is not supported by the error produced. >>>>>> >>>>>> Tony: why did you make the above comment? >>>>>> >>>>>> Either way we need to see a decoded stack to get an idea of what is going >>>>>> wrong. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> tom >>>>>>> >>>>>>> On Jul 30, 2010, at 12:04 AM, David Holmes >>>>>>> wrote: >>>>>>> >>>>>>>> Sorry Tony I keep forgetting that I don't have a way to decode a >>>>>>>> crash log from a VM that you built yourself. :( However you may be >>>>>>>> able to decode it yourself please see: >>>>>>>> >>>>>>>> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >>>>>>>> >>>>>>>> for a perl script. >>>>>>>> >>>>>>>> That said looking at the actual assertion failure I am guessing >>>>>>>> that you initiated the VM operation from code where a >>>>>>>> No_Safepoint_verifier is active. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> Tony Guan said the following on 07/30/10 15:58: >>>>>>>>> >>>>>>>>> Hi David, Thanks a lot! I am copying the content to below, and >>>>>>>>> for convenience, the full log file is attached. cat >>>>>>>>> hs_err_pid30894.log # # A fatal error has been detected by the >>>>>>>>> Java Runtime Environment: # # Internal Error >>>>>>>>> >>>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>>> pid=30894, tid=1082374480 # Error: Possible safepoint reached >>>>>>>>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>>>>>>>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>>>>>>>> mode linux-amd64 ) # If you would like to submit a bug report, >>>>>>>>> please visit: # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>>> # --------------- T H R E A D --------------- Current thread >>>>>>>>> (0x00000000012ed000): JavaThread "RMI TCP Connection(idle)" >>>>>>>>> daemon [_thread_in_Java, id=30929, >>>>>>>>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>>>>>>>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>>>>>>>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) V >>>>>>>>> [libjvm.so+0x8cad18] V [libjvm.so+0x8cbe38] V >>>>>>>>> [libjvm.so+0x4039f1] V [libjvm.so+0x87a183] V >>>>>>>>> [libjvm.so+0x8e1127] V [libjvm.so+0x4d52ab] V >>>>>>>>> [libjvm.so+0x7ee63d] j sun.misc.Unsafe.park(ZJ)V+0 j >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>>>>>> j >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>>>>>> j >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>>>>>> j >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>>>>>> j >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>>>>>> j >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>>>>>> j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>>>>>>>> java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V >>>>>>>>> [libjvm.so+0x555ecc] V [libjvm.so+0x747a34] V >>>>>>>>> [libjvm.so+0x554b55] V [libjvm.so+0x5551f0] V >>>>>>>>> [libjvm.so+0x5553cc] V [libjvm.so+0x5be6cd] V >>>>>>>>> [libjvm.so+0x879869] V [libjvm.so+0x87c1b5] V >>>>>>>>> [libjvm.so+0x750455] .... (above is the stack, please see the >>>>>>>>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>>>>>>>> 29, 2010 at 8:07 PM, David Holmes >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Tony, >>>>>>>>>> >>>>>>>>>> I don't see anything obviously wrong with what you attempted. >>>>>>>>>> Can you show the full stack dump from the error. >>>>>>>>>> >>>>>>>>>> David Holmes >>>>>>>>>> >>>>>>>>>> Tony Guan said the following on 07/30/10 07:29: >>>>>>>>>>> >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> I want to invoke the GC at a certain time, for example, when >>>>>>>>>>> a certain method is called at runtime, so I created a new >>>>>>>>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>>>>>>>> object op, finally, executed using:VMThread::execute(&op) >>>>>>>>>>> >>>>>>>>>>> then I got the following error message: >>>>>>>>>>> >>>>>>>>>>> # Internal Error >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>>>>> pid=29652, tid=1096460624 # Error: Possible safepoint >>>>>>>>>>> reached by thread that does not allow it >>>>>>>>>>> >>>>>>>>>>> The reason for the fail is that >>>>>>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>>>>>> the currentThread is not a VMThread. >>>>>>>>>>> >>>>>>>>>>> My question is: how do I bring the current thread to a >>>>>>>>>>> safepoint? or how do I call a GC operation properly? is there >>>>>>>>>>> any prerequisite for doing so? >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Tony (Xiaohua Guan) >>>> >>> >> From guanxiaohua at gmail.com Tue Aug 3 16:58:26 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Tue, 3 Aug 2010 18:58:26 -0500 Subject: how to bring jvm to safepoint In-Reply-To: References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> <4C53BB1E.9070401@oracle.com> <4C54ED7D.50202@oracle.com> Message-ID: Hi Tom, Thanks for the reminder, I will keep that in mind. I will call GC at allocation time anyway (without modifying dtrace_method_exit) for I think I have a better idea for my current project. Thanks a lot, everyone! Tony (Xiaohua Guan) On Tue, Aug 3, 2010 at 6:51 PM, Tom Rodriguez wrote: > I suspect this isn't going work properly with compiled code. ?In general you can't simply change JRT_LEAF to JRT_ENTRY because JRT_ENTRY functions must be called from locations that include proper debug info and we don't emit any for leaf calls. ?It will likely work for the interpreter since the stack is simpler to walk but I expect you will have problems of some sort. ?I guess you add debug info to those calls in compiled code but it's not obvious to me where you would get that from. > > tom > > On Aug 3, 2010, at 4:38 PM, Tony Guan wrote: > >> Hi Everyone, >> >> Please ignore my previous message, I just forgot to update the jvm for testing. >> >> Actually, changing dtrace_method_exit to be JRT_ENTRY solved the >> problem! It works out. >> >> Thank you, David! >> >> >> Cheers! >> >> Tony (Xiaohua Guan) >> >> >> >> On Tue, Aug 3, 2010 at 6:20 PM, Tony Guan wrote: >>> Hi David, >>> >>> I changed dtrace_method_exit to JRT_ENTRY from JRT_LEAF, and still >>> stopped by the same failure. Does it have anything to do with the >>> method sun.misc.Unsafe.park()? >>> >>> Thanks! >>> >>> Tony (Xiaohua Guan) >>> >>> >>> >>> On Sun, Aug 1, 2010 at 3:50 PM, Tony Guan wrote: >>>> Hi David, >>>> >>>> Thanks for the explanation, now I get to understand it. >>>> >>>> Have to say, it's a nice failure for me. :) >>>> >>>> Tony (Xiaohua Guan) >>>> >>>> >>>> >>>> On Sat, Jul 31, 2010 at 10:43 PM, David Holmes wrote: >>>>> Hi Tony, >>>>> >>>>> Now it is all clear :) >>>>> >>>>>> It's exactly how the error occurred, I am monitoring the >>>>>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>>>>> intercepting inside jvm implementation), once this method gets called, >>>>>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>>>>> GC using VMThread::Execute(&op). >>>>> >>>>> Right, you are using: >>>>> >>>>> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >>>>> >>>>> but dtrace_method_exit is defined as a runtime "leaf" method (JRT_LEAF). >>>>> "leaf" methods are not allowed to perform certain actions and in debug mode >>>>> we have JRT_Leaf_Verifier that is used to check those actions. A >>>>> JRT_Leaf_Verifier is a No_Safepoint_Verifier - hence as I said before you >>>>> get the assertion failure due to this. >>>>> >>>>> When you do the VMThread::execute to initiate the safepoint operation for >>>>> your GC action, the current thread will block waiting for it to complete. >>>>> Part of that blocking involves a safepoint check and hence the system finds >>>>> that the thread is attempting to enter a safepoint from a "leaf" method - >>>>> and that is not allowed. >>>>> >>>>> You might just try changing the definition of dtrace_method_exit to be >>>>> JRT_ENTRY rather than JRT_LEAF, but I don't know if that will have >>>>> unexpected side-effects. >>>>> >>>>> There are lots of rules (not necessarily clearly documented) that control >>>>> how you can call into the VM runtime and how different parts of the VM >>>>> runtime can call other parts of the runtime. >>>>> >>>>> Cheers, >>>>> David Holmes >>>>> >>>>> Tony Guan said the following on 08/01/10 08:10: >>>>>> >>>>>> Hi David & Tom, >>>>>> >>>>>> Please see the decoded stack below(also full decoded log is attached): >>>>>> >>>>>> " >>>>>> Current thread (0x00000000012ed000): ?JavaThread "RMI TCP >>>>>> Connection(idle)" daemon [_thread_in_Java, id=30929, >>>>>> stack(0x000000004073b000,0x000000004083c000)] >>>>>> >>>>>> Stack: [0x000000004073b000,0x000000004083c000], >>>>>> sp=0x0000000040839d60, ?free space=3fb0000000000000000k >>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>>>>> code) >>>>>> V ?[libjvm.so+0x8cad18];; ?_ZN7VMError6reportEP12outputStream+0xb72 >>>>>> V ?[libjvm.so+0x8cbe38];; ?_ZN7VMError14report_and_dieEv+0x5f6 >>>>>> V ?[libjvm.so+0x4039f1];; ?_Z12report_fatalPKciS0_+0x6b >>>>>> V ?[libjvm.so+0x87a183];; >>>>>> ?_ZN6Thread31check_for_valid_safepoint_stateEb+0x33 >>>>>> V ?[libjvm.so+0x8e1127];; ?_ZN8VMThread7executeEP12VM_Operation+0x49 >>>>>> V ?[libjvm.so+0x4d52ab];; >>>>>> _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 >>>>>> V ?[libjvm.so+0x7ee63d];; >>>>>> _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 >>>>>> j ?sun.misc.Unsafe.park(ZJ)V+0 >>>>>> j >>>>>> ?java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>>> j >>>>>> ?java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>>> j >>>>>> ?java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>>> j >>>>>> ?java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>>> j >>>>>> ?java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>>> j >>>>>> ?java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>>> j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 >>>>>> j ?java.lang.Thread.run()V+11 >>>>>> v ?~StubRoutines::call_stub >>>>>> V ?[libjvm.so+0x555ecc];; >>>>>> >>>>>> _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 >>>>>> V ?[libjvm.so+0x747a34];; >>>>>> >>>>>> _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 >>>>>> V ?[libjvm.so+0x554b55];; >>>>>> >>>>>> _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f >>>>>> V ?[libjvm.so+0x5551f0];; >>>>>> >>>>>> _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 >>>>>> V ?[libjvm.so+0x5553cc];; >>>>>> >>>>>> _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 >>>>>> V ?[libjvm.so+0x5be6cd];; ?_Z12thread_entryP10JavaThreadP6Thread+0x9f >>>>>> V ?[libjvm.so+0x879869];; ?_ZN10JavaThread17thread_main_innerEv+0xc9 >>>>>> V ?[libjvm.so+0x87c1b5];; ?_ZN10JavaThread3runEv+0x2c1 >>>>>> V ?[libjvm.so+0x750455];; ?_Z10java_startP6Thread+0x16f >>>>>> " >>>>>> >>>>>> It's exactly how the error occurred, I am monitoring the >>>>>> sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just >>>>>> intercepting inside jvm implementation), once this method gets called, >>>>>> I will call GenCollectedHeap::invoke_transEden_collection() to start a >>>>>> GC using VMThread::Execute(&op). >>>>>> >>>>>> At the beginning of VMTHread::Execute(), >>>>>> check_for_valid_safepoint_state is called like this: >>>>>> >>>>>> void VMThread::execute(VM_Operation* op) { >>>>>> ?Thread* t = Thread::current(); >>>>>> ?if (!t->is_VM_thread()) { >>>>>> ? ?// JavaThread or WatcherThread >>>>>> ? ?t->check_for_valid_safepoint_state(true); ?//And we failed here!! >>>>>> ? ?// New request from Java thread, evaluate prologue >>>>>> ? ?if (!op->doit_prologue()) { >>>>>> ? ? ?return; ? // op was cancelled >>>>>> ? ?} >>>>>> ... >>>>>> } >>>>>> >>>>>> That's why I said the current thread is not a VM_thread. I think I can >>>>>> make a workaround by invoking the GC at the next allocation request, >>>>>> which should be in the safepoint. But would be great if I can learn >>>>>> more about hotspot solving this problem. >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>>> Tony (Xiaohua Guan) >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jul 31, 2010 at 12:56 AM, David Holmes >>>>>> wrote: >>>>>>> >>>>>>> Tom Rodriguez said the following on 07/31/10 05:01: >>>>>>>> >>>>>>>> Actually I think the problem is that the thread is in thread_in_Java >>>>>>>> state. I don't believe you can safepoint from that state, only >>>>>>>> thread_in_vm. >>>>>>> >>>>>>> The reported failure: >>>>>>> >>>>>>> # ?Error: Possible safepoint reached by thread that does not allow it >>>>>>> >>>>>>> is here: >>>>>>> >>>>>>> void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) >>>>>>> { >>>>>>> ? // Check if current thread is allowed to block at a safepoint >>>>>>> ? if (!(_allow_safepoint_count == 0)) >>>>>>> ? ? fatal("Possible safepoint reached by thread that does not allow it"); >>>>>>> >>>>>>> as far as I can see the only code that touches _allow_safepoint_count are >>>>>>> the No_Safepoint_Verifier classes. >>>>>>> >>>>>>> Also the stack shows: >>>>>>> >>>>>>> V ?[libjvm.so+0x7ee63d] >>>>>>> j ?sun.misc.Unsafe.park(ZJ)V+0 >>>>>>> >>>>>>> and so we should have transitioned to _thread_in_vm here. >>>>>>> >>>>>>> That said, Tony also stated: >>>>>>> >>>>>>>> The reason for the fail is that >>>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>>> the currentThread is not a VMThread. >>>>>>> >>>>>>> But that is not supported by the error produced. >>>>>>> >>>>>>> Tony: why did you make the above comment? >>>>>>> >>>>>>> Either way we need to see a decoded stack to get an idea of what is going >>>>>>> wrong. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>> On Jul 30, 2010, at 12:04 AM, David Holmes >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Sorry Tony I keep forgetting that I don't have a way to decode a >>>>>>>>> crash log from a VM that you built yourself. :( However you may be >>>>>>>>> able to decode it yourself please see: >>>>>>>>> >>>>>>>>> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >>>>>>>>> >>>>>>>>> for a perl script. >>>>>>>>> >>>>>>>>> That said looking at the actual assertion failure I am guessing >>>>>>>>> that you initiated the VM operation from code where a >>>>>>>>> No_Safepoint_verifier is active. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> Tony Guan said the following on 07/30/10 15:58: >>>>>>>>>> >>>>>>>>>> Hi David, Thanks a lot! I am copying the content to below, and >>>>>>>>>> for convenience, the full log file is attached. cat >>>>>>>>>> hs_err_pid30894.log # # A fatal error has been detected by the >>>>>>>>>> Java Runtime Environment: # # ?Internal Error >>>>>>>>>> >>>>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>>>> ?pid=30894, tid=1082374480 # ?Error: Possible safepoint reached >>>>>>>>>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>>>>>>>>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>>>>>>>>> mode linux-amd64 ) # If you would like to submit a bug report, >>>>>>>>>> please visit: # ? http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>>>> ?# --------------- ?T H R E A D ?--------------- Current thread >>>>>>>>>> (0x00000000012ed000): ?JavaThread "RMI TCP Connection(idle)" >>>>>>>>>> daemon [_thread_in_Java, id=30929, >>>>>>>>>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>>>>>>>>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>>>>>>>>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) V >>>>>>>>>> [libjvm.so+0x8cad18] V ?[libjvm.so+0x8cbe38] V >>>>>>>>>> [libjvm.so+0x4039f1] V ?[libjvm.so+0x87a183] V >>>>>>>>>> [libjvm.so+0x8e1127] V ?[libjvm.so+0x4d52ab] V >>>>>>>>>> [libjvm.so+0x7ee63d] j ?sun.misc.Unsafe.park(ZJ)V+0 j >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>>>>>>> ?j >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>>>>>>> ?j >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>>>>>>> ?j >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>>>>>>> ?j >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>>>>>>> ?j >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>>>>>>> ?j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>>>>>>>>> java.lang.Thread.run()V+11 v ?~StubRoutines::call_stub V >>>>>>>>>> [libjvm.so+0x555ecc] V ?[libjvm.so+0x747a34] V >>>>>>>>>> [libjvm.so+0x554b55] V ?[libjvm.so+0x5551f0] V >>>>>>>>>> [libjvm.so+0x5553cc] V ?[libjvm.so+0x5be6cd] V >>>>>>>>>> [libjvm.so+0x879869] V ?[libjvm.so+0x87c1b5] V >>>>>>>>>> [libjvm.so+0x750455] .... (above is the stack, please see the >>>>>>>>>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>>>>>>>>> 29, 2010 at 8:07 PM, David Holmes >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Tony, >>>>>>>>>>> >>>>>>>>>>> I don't see anything obviously wrong with what you attempted. >>>>>>>>>>> Can you show the full stack dump from the error. >>>>>>>>>>> >>>>>>>>>>> David Holmes >>>>>>>>>>> >>>>>>>>>>> Tony Guan said the following on 07/30/10 07:29: >>>>>>>>>>>> >>>>>>>>>>>> Dear all, >>>>>>>>>>>> >>>>>>>>>>>> I want to invoke the GC at a certain time, for example, when >>>>>>>>>>>> a certain method is called at runtime, so I created a new >>>>>>>>>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>>>>>>>>> object op, finally, executed using:VMThread::execute(&op) >>>>>>>>>>>> >>>>>>>>>>>> then I got the following error message: >>>>>>>>>>>> >>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>>>>>>> ?pid=29652, tid=1096460624 # ?Error: Possible safepoint >>>>>>>>>>>> reached by thread that does not allow it >>>>>>>>>>>> >>>>>>>>>>>> The reason for the fail is that >>>>>>>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>>>>>>> the currentThread is not a VMThread. >>>>>>>>>>>> >>>>>>>>>>>> My question is: how do I bring the current thread to a >>>>>>>>>>>> safepoint? or how do I call a GC operation properly? is there >>>>>>>>>>>> any prerequisite for doing so? >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Tony (Xiaohua Guan) >>>>> >>>> >>> > > From jacklusf at gmail.com Tue Aug 3 17:55:41 2010 From: jacklusf at gmail.com (Xiaobin Lu) Date: Tue, 3 Aug 2010 17:55:41 -0700 Subject: UseCodeCacheUnloading question Message-ID: Hi folks, I heard Erik from AMD from the JVM language summit about his recent work to improve Code cache. He mentioned the flag will enable eviction of unused compiled method from code cache when it becomes full. The flag he mentioned is -XX:+UseCodeCacheUnloading. But I can't seem to find that flag from globals.hpp. Would anyone please shed some light upon this? Thanks so much! -Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100803/e2d10bd6/attachment.html From vladimir.kozlov at oracle.com Tue Aug 3 17:57:35 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Aug 2010 17:57:35 -0700 Subject: UseCodeCacheUnloading question In-Reply-To: References: Message-ID: <4C58BAFF.8030700@oracle.com> -XX:+UseCodeCacheFlushing Vladimir Xiaobin Lu wrote: > Hi folks, > > I heard Erik from AMD from the JVM language summit about his recent work > to improve Code cache. He mentioned the flag will enable eviction of > unused compiled method from code cache when it becomes full. The flag he > mentioned is -XX:+UseCodeCacheUnloading. But I can't seem to find that > flag from globals.hpp. > > Would anyone please shed some light upon this? > > Thanks so much! > > -Jack From y.s.ramakrishna at oracle.com Tue Aug 3 18:25:49 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Tue, 03 Aug 2010 18:25:49 -0700 Subject: UseCodeCacheUnloading question In-Reply-To: References: Message-ID: <4C58C19D.9020707@oracle.com> Hi Xiaobin -- "Unloading" should be "Flushing". i.e. "UseCodeCacheFlushing" -- ramki Xiaobin Lu wrote: > Hi folks, > > I heard Erik from AMD from the JVM language summit about his recent work to > improve Code cache. He mentioned the flag will enable eviction of unused > compiled method from code cache when it becomes full. The flag he mentioned > is -XX:+UseCodeCacheUnloading. But I can't seem to find that flag from > globals.hpp. > > Would anyone please shed some light upon this? > > Thanks so much! > > -Jack > From rasbold at google.com Wed Aug 4 11:20:17 2010 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 4 Aug 2010 11:20:17 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: <19544.42999.632063.746834@oracle.com> References: <19544.42999.632063.746834@oracle.com> Message-ID: Thanks, John. The nits have been fixed and the webrev updated. http://cr.openjdk.java.net/~rasbold/6378314/ -- Chuck On Tue, Aug 3, 2010 at 4:36 PM, John Coomes wrote: > Chuck Rasbold (rasbold at google.com) wrote: > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > Fixed: 6378314: Bad warning message when agent library not found. local > > directory is not searched. > > Contributed-by: jeremymanson at google.com > > > > Print a more detailed error message for agent library load failure. > > Hi Chuck & Jeremy, > > Looks ok to me, aside from a couple of nits: use jio_snprintf instead > of sprintf, and strlen returns a size_t, so use that to declare len. > > -John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100804/a85b7fca/attachment.html From tom.rodriguez at oracle.com Wed Aug 4 11:43:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 4 Aug 2010 11:43:21 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: References: <19544.42999.632063.746834@oracle.com> Message-ID: <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> The SunStudio compiler doesn't like this construct: + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) + strlen(ebuf) + 1; + char buf[len]; so I think you'll have to use another fixed size buffer. tom On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: > Thanks, John. > > The nits have been fixed and the webrev updated. > > http://cr.openjdk.java.net/~rasbold/6378314/ > > -- Chuck > > On Tue, Aug 3, 2010 at 4:36 PM, John Coomes wrote: > Chuck Rasbold (rasbold at google.com) wrote: > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > Fixed: 6378314: Bad warning message when agent library not found. local > > directory is not searched. > > Contributed-by: jeremymanson at google.com > > > > Print a more detailed error message for agent library load failure. > > Hi Chuck & Jeremy, > > Looks ok to me, aside from a couple of nits: use jio_snprintf instead > of sprintf, and strlen returns a size_t, so use that to declare len. > > -John > > From kelly.ohair at oracle.com Wed Aug 4 13:15:36 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 4 Aug 2010 13:15:36 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> Message-ID: On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: > The SunStudio compiler doesn't like this construct: > > + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) > + strlen(ebuf) + 1; > + char buf[len]; > I wondered about that. > so I think you'll have to use another fixed size buffer. or char * buf = new char[len]; and a delete [] buf ??? -kto > > tom > > On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: > >> Thanks, John. >> >> The nits have been fixed and the webrev updated. >> >> http://cr.openjdk.java.net/~rasbold/6378314/ >> >> -- Chuck >> >> On Tue, Aug 3, 2010 at 4:36 PM, John Coomes >> wrote: >> Chuck Rasbold (rasbold at google.com) wrote: >>> http://cr.openjdk.java.net/~rasbold/6378314/ >>> >>> Fixed: 6378314: Bad warning message when agent library not found. >>> local >>> directory is not searched. >>> Contributed-by: jeremymanson at google.com >>> >>> Print a more detailed error message for agent library load failure. >> >> Hi Chuck & Jeremy, >> >> Looks ok to me, aside from a couple of nits: use jio_snprintf >> instead >> of sprintf, and strlen returns a size_t, so use that to declare len. >> >> -John >> >> > From paul.hohensee at oracle.com Wed Aug 4 13:28:26 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 04 Aug 2010 16:28:26 -0400 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> Message-ID: <4C59CD6A.7030303@oracle.com> No 'new' and 'delete' in the hotspot source code please. Use NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. Paul On 8/4/10 4:15 PM, Kelly O'Hair wrote: > > On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: > >> The SunStudio compiler doesn't like this construct: >> >> + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) >> + strlen(ebuf) + 1; >> + char buf[len]; >> > > I wondered about that. > >> so I think you'll have to use another fixed size buffer. > > or char * buf = new char[len]; > > and a delete [] buf > ??? > > -kto > >> >> tom >> >> On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: >> >>> Thanks, John. >>> >>> The nits have been fixed and the webrev updated. >>> >>> http://cr.openjdk.java.net/~rasbold/6378314/ >>> >>> -- Chuck >>> >>> On Tue, Aug 3, 2010 at 4:36 PM, John Coomes >>> wrote: >>> Chuck Rasbold (rasbold at google.com) wrote: >>>> http://cr.openjdk.java.net/~rasbold/6378314/ >>>> >>>> Fixed: 6378314: Bad warning message when agent library not found. >>>> local >>>> directory is not searched. >>>> Contributed-by: jeremymanson at google.com >>>> >>>> Print a more detailed error message for agent library load failure. >>> >>> Hi Chuck & Jeremy, >>> >>> Looks ok to me, aside from a couple of nits: use jio_snprintf instead >>> of sprintf, and strlen returns a size_t, so use that to declare len. >>> >>> -John >>> >>> >> > From rasbold at google.com Wed Aug 4 15:01:53 2010 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 4 Aug 2010 15:01:53 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: <4C59CD6A.7030303@oracle.com> References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> <4C59CD6A.7030303@oracle.com> Message-ID: Internally, we did discuss the "char buf[len]" construct, but forgot about the SunStudio compilers. Sorry about that. I've changed the new code to use AllocateHeap() and FreeHeap(), as does the currently existing code within the #ifdef KERNEL. And then I put a fix and a clean-up within that #ifdef, so the code is more consistent throughout. http://cr.openjdk.java.net/~rasbold/6378314/ -- Chuck On Wed, Aug 4, 2010 at 1:28 PM, Paul Hohensee wrote: > No 'new' and 'delete' in the hotspot source code please. Use > NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. > > Paul > > > On 8/4/10 4:15 PM, Kelly O'Hair wrote: > >> >> On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: >> >> The SunStudio compiler doesn't like this construct: >>> >>> + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) + >>> strlen(ebuf) + 1; >>> + char buf[len]; >>> >>> >> I wondered about that. >> >> so I think you'll have to use another fixed size buffer. >>> >> >> or char * buf = new char[len]; >> >> and a delete [] buf >> ??? >> >> -kto >> >> >>> tom >>> >>> On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: >>> >>> Thanks, John. >>>> >>>> The nits have been fixed and the webrev updated. >>>> >>>> http://cr.openjdk.java.net/~rasbold/6378314/ >>>> >>>> -- Chuck >>>> >>>> On Tue, Aug 3, 2010 at 4:36 PM, John Coomes >>>> wrote: >>>> Chuck Rasbold (rasbold at google.com) wrote: >>>> >>>>> http://cr.openjdk.java.net/~rasbold/6378314/ >>>>> >>>>> Fixed: 6378314: Bad warning message when agent library not found. local >>>>> directory is not searched. >>>>> Contributed-by: jeremymanson at google.com >>>>> >>>>> Print a more detailed error message for agent library load failure. >>>>> >>>> >>>> Hi Chuck & Jeremy, >>>> >>>> Looks ok to me, aside from a couple of nits: use jio_snprintf instead >>>> of sprintf, and strlen returns a size_t, so use that to declare len. >>>> >>>> -John >>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100804/427e7dd8/attachment.html From tom.rodriguez at oracle.com Wed Aug 4 16:28:29 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 4 Aug 2010 16:28:29 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> <4C59CD6A.7030303@oracle.com> Message-ID: I think simply allocating using NEW_RESOURCE_ARRAY(char, len) will be fine/better. The use of AllocateHeap in the ifdef KERNEL piece is kind of odd to me. Maybe they are being paranoid about what might happen in fork_and_exec. Actually there's a minor bug in that code because of the use of AllocateHeap. FreeHeap(cmd); if (status == -1) { warning(cmd); tom On Aug 4, 2010, at 3:01 PM, Chuck Rasbold wrote: > Internally, we did discuss the "char buf[len]" construct, but forgot about the SunStudio compilers. Sorry about that. > > I've changed the new code to use AllocateHeap() and FreeHeap(), as does the currently existing code within the #ifdef KERNEL. > > And then I put a fix and a clean-up within that #ifdef, so the code is more consistent throughout. > > http://cr.openjdk.java.net/~rasbold/6378314/ > > -- Chuck > > > On Wed, Aug 4, 2010 at 1:28 PM, Paul Hohensee wrote: > No 'new' and 'delete' in the hotspot source code please. Use > NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. > > Paul > > > On 8/4/10 4:15 PM, Kelly O'Hair wrote: > > On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: > > The SunStudio compiler doesn't like this construct: > > + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) + strlen(ebuf) + 1; > + char buf[len]; > > > I wondered about that. > > so I think you'll have to use another fixed size buffer. > > or char * buf = new char[len]; > > and a delete [] buf > ??? > > -kto > > > tom > > On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: > > Thanks, John. > > The nits have been fixed and the webrev updated. > > http://cr.openjdk.java.net/~rasbold/6378314/ > > -- Chuck > > On Tue, Aug 3, 2010 at 4:36 PM, John Coomes wrote: > Chuck Rasbold (rasbold at google.com) wrote: > http://cr.openjdk.java.net/~rasbold/6378314/ > > Fixed: 6378314: Bad warning message when agent library not found. local > directory is not searched. > Contributed-by: jeremymanson at google.com > > Print a more detailed error message for agent library load failure. > > Hi Chuck & Jeremy, > > Looks ok to me, aside from a couple of nits: use jio_snprintf instead > of sprintf, and strlen returns a size_t, so use that to declare len. > > -John > > > > > From rasbold at google.com Thu Aug 5 08:01:07 2010 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 5 Aug 2010 08:01:07 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> <4C59CD6A.7030303@oracle.com> Message-ID: I think it is too soon in VM startup to use resource allocation. I've switched to C_HEAP allocation, instead. I applied changes to the KERNEL chunk of code to make it consistent. I can't/won't test that code. Let me know if you'd rather me leave it alone. Webrev updated. http://cr.openjdk.java.net/~rasbold/6378314/ -- Chuck On Wed, Aug 4, 2010 at 4:28 PM, Tom Rodriguez wrote: > I think simply allocating using NEW_RESOURCE_ARRAY(char, len) will be > fine/better. The use of AllocateHeap in the ifdef KERNEL piece is kind of > odd to me. Maybe they are being paranoid about what might happen in > fork_and_exec. Actually there's a minor bug in that code because of the use > of AllocateHeap. > > FreeHeap(cmd); > if (status == -1) { > warning(cmd); > > tom > > On Aug 4, 2010, at 3:01 PM, Chuck Rasbold wrote: > > > Internally, we did discuss the "char buf[len]" construct, but forgot > about the SunStudio compilers. Sorry about that. > > > > I've changed the new code to use AllocateHeap() and FreeHeap(), as does > the currently existing code within the #ifdef KERNEL. > > > > And then I put a fix and a clean-up within that #ifdef, so the code is > more consistent throughout. > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > -- Chuck > > > > > > On Wed, Aug 4, 2010 at 1:28 PM, Paul Hohensee > wrote: > > No 'new' and 'delete' in the hotspot source code please. Use > > NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. > > > > Paul > > > > > > On 8/4/10 4:15 PM, Kelly O'Hair wrote: > > > > On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: > > > > The SunStudio compiler doesn't like this construct: > > > > + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) + > strlen(ebuf) + 1; > > + char buf[len]; > > > > > > I wondered about that. > > > > so I think you'll have to use another fixed size buffer. > > > > or char * buf = new char[len]; > > > > and a delete [] buf > > ??? > > > > -kto > > > > > > tom > > > > On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: > > > > Thanks, John. > > > > The nits have been fixed and the webrev updated. > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > -- Chuck > > > > On Tue, Aug 3, 2010 at 4:36 PM, John Coomes > wrote: > > Chuck Rasbold (rasbold at google.com) wrote: > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > Fixed: 6378314: Bad warning message when agent library not found. local > > directory is not searched. > > Contributed-by: jeremymanson at google.com > > > > Print a more detailed error message for agent library load failure. > > > > Hi Chuck & Jeremy, > > > > Looks ok to me, aside from a couple of nits: use jio_snprintf instead > > of sprintf, and strlen returns a size_t, so use that to declare len. > > > > -John > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100805/26ddc347/attachment-0001.html From tom.rodriguez at oracle.com Thu Aug 5 10:36:52 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 5 Aug 2010 10:36:52 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> <4C59CD6A.7030303@oracle.com> Message-ID: <4839A7EC-6125-4D65-9930-7D0101ACDCD4@oracle.com> I hadn't considered that. That seems fine then. If no one else has volunteered to push this, I will take care of it. tom On Aug 5, 2010, at 8:01 AM, Chuck Rasbold wrote: > I think it is too soon in VM startup to use resource allocation. I've switched to C_HEAP allocation, instead. > > I applied changes to the KERNEL chunk of code to make it consistent. I can't/won't test that code. Let me know if you'd rather me leave it alone. > > Webrev updated. > > http://cr.openjdk.java.net/~rasbold/6378314/ > > -- Chuck > > On Wed, Aug 4, 2010 at 4:28 PM, Tom Rodriguez wrote: > I think simply allocating using NEW_RESOURCE_ARRAY(char, len) will be fine/better. The use of AllocateHeap in the ifdef KERNEL piece is kind of odd to me. Maybe they are being paranoid about what might happen in fork_and_exec. Actually there's a minor bug in that code because of the use of AllocateHeap. > > FreeHeap(cmd); > if (status == -1) { > warning(cmd); > > tom > > On Aug 4, 2010, at 3:01 PM, Chuck Rasbold wrote: > > > Internally, we did discuss the "char buf[len]" construct, but forgot about the SunStudio compilers. Sorry about that. > > > > I've changed the new code to use AllocateHeap() and FreeHeap(), as does the currently existing code within the #ifdef KERNEL. > > > > And then I put a fix and a clean-up within that #ifdef, so the code is more consistent throughout. > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > -- Chuck > > > > > > On Wed, Aug 4, 2010 at 1:28 PM, Paul Hohensee wrote: > > No 'new' and 'delete' in the hotspot source code please. Use > > NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. > > > > Paul > > > > > > On 8/4/10 4:15 PM, Kelly O'Hair wrote: > > > > On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: > > > > The SunStudio compiler doesn't like this construct: > > > > + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) + strlen(ebuf) + 1; > > + char buf[len]; > > > > > > I wondered about that. > > > > so I think you'll have to use another fixed size buffer. > > > > or char * buf = new char[len]; > > > > and a delete [] buf > > ??? > > > > -kto > > > > > > tom > > > > On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: > > > > Thanks, John. > > > > The nits have been fixed and the webrev updated. > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > -- Chuck > > > > On Tue, Aug 3, 2010 at 4:36 PM, John Coomes wrote: > > Chuck Rasbold (rasbold at google.com) wrote: > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > Fixed: 6378314: Bad warning message when agent library not found. local > > directory is not searched. > > Contributed-by: jeremymanson at google.com > > > > Print a more detailed error message for agent library load failure. > > > > Hi Chuck & Jeremy, > > > > Looks ok to me, aside from a couple of nits: use jio_snprintf instead > > of sprintf, and strlen returns a size_t, so use that to declare len. > > > > -John > > > > > > > > > > > > From rasbold at google.com Thu Aug 5 11:10:21 2010 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 5 Aug 2010 11:10:21 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: <4839A7EC-6125-4D65-9930-7D0101ACDCD4@oracle.com> References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> <4C59CD6A.7030303@oracle.com> <4839A7EC-6125-4D65-9930-7D0101ACDCD4@oracle.com> Message-ID: I haven't had any other volunteers yet. Thanks for making it happen. On Thu, Aug 5, 2010 at 10:36 AM, Tom Rodriguez wrote: > I hadn't considered that. That seems fine then. If no one else has > volunteered to push this, I will take care of it. > > tom > > On Aug 5, 2010, at 8:01 AM, Chuck Rasbold wrote: > > > I think it is too soon in VM startup to use resource allocation. I've > switched to C_HEAP allocation, instead. > > > > I applied changes to the KERNEL chunk of code to make it consistent. I > can't/won't test that code. Let me know if you'd rather me leave it alone. > > > > Webrev updated. > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > -- Chuck > > > > On Wed, Aug 4, 2010 at 4:28 PM, Tom Rodriguez > wrote: > > I think simply allocating using NEW_RESOURCE_ARRAY(char, len) will be > fine/better. The use of AllocateHeap in the ifdef KERNEL piece is kind of > odd to me. Maybe they are being paranoid about what might happen in > fork_and_exec. Actually there's a minor bug in that code because of the use > of AllocateHeap. > > > > FreeHeap(cmd); > > if (status == -1) { > > warning(cmd); > > > > tom > > > > On Aug 4, 2010, at 3:01 PM, Chuck Rasbold wrote: > > > > > Internally, we did discuss the "char buf[len]" construct, but forgot > about the SunStudio compilers. Sorry about that. > > > > > > I've changed the new code to use AllocateHeap() and FreeHeap(), as does > the currently existing code within the #ifdef KERNEL. > > > > > > And then I put a fix and a clean-up within that #ifdef, so the code is > more consistent throughout. > > > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > > > -- Chuck > > > > > > > > > On Wed, Aug 4, 2010 at 1:28 PM, Paul Hohensee < > paul.hohensee at oracle.com> wrote: > > > No 'new' and 'delete' in the hotspot source code please. Use > > > NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. > > > > > > Paul > > > > > > > > > On 8/4/10 4:15 PM, Kelly O'Hair wrote: > > > > > > On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: > > > > > > The SunStudio compiler doesn't like this construct: > > > > > > + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) + > strlen(ebuf) + 1; > > > + char buf[len]; > > > > > > > > > I wondered about that. > > > > > > so I think you'll have to use another fixed size buffer. > > > > > > or char * buf = new char[len]; > > > > > > and a delete [] buf > > > ??? > > > > > > -kto > > > > > > > > > tom > > > > > > On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: > > > > > > Thanks, John. > > > > > > The nits have been fixed and the webrev updated. > > > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > > > -- Chuck > > > > > > On Tue, Aug 3, 2010 at 4:36 PM, John Coomes > wrote: > > > Chuck Rasbold (rasbold at google.com) wrote: > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > > > Fixed: 6378314: Bad warning message when agent library not found. local > > > directory is not searched. > > > Contributed-by: jeremymanson at google.com > > > > > > Print a more detailed error message for agent library load failure. > > > > > > Hi Chuck & Jeremy, > > > > > > Looks ok to me, aside from a couple of nits: use jio_snprintf instead > > > of sprintf, and strlen returns a size_t, so use that to declare len. > > > > > > -John > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100805/5b1667b9/attachment.html From coleen.phillimore at oracle.com Thu Aug 5 11:33:00 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 05 Aug 2010 14:33:00 -0400 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> <4C59CD6A.7030303@oracle.com> <4839A7EC-6125-4D65-9930-7D0101ACDCD4@oracle.com> Message-ID: <4C5B03DC.7090903@oracle.com> Tom and Chuck, I can push it since it fixed my bug under kernel, it's the least I can do. And the code looks fine except vm_exit_during_initialization doesn't return so I don't think these things aren't actually freed. It doens't matter because vm_exit_during_initialization() currently exits. Thanks, Coleen On 08/05/10 14:10, Chuck Rasbold wrote: > I haven't had any other volunteers yet. > > Thanks for making it happen. > > On Thu, Aug 5, 2010 at 10:36 AM, Tom Rodriguez > > wrote: > > I hadn't considered that. That seems fine then. If no one else > has volunteered to push this, I will take care of it. > > tom > > On Aug 5, 2010, at 8:01 AM, Chuck Rasbold wrote: > > > I think it is too soon in VM startup to use resource allocation. > I've switched to C_HEAP allocation, instead. > > > > I applied changes to the KERNEL chunk of code to make it > consistent. I can't/won't test that code. Let me know if you'd > rather me leave it alone. > > > > Webrev updated. > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > > -- Chuck > > > > On Wed, Aug 4, 2010 at 4:28 PM, Tom Rodriguez > > wrote: > > I think simply allocating using NEW_RESOURCE_ARRAY(char, len) > will be fine/better. The use of AllocateHeap in the ifdef KERNEL > piece is kind of odd to me. Maybe they are being paranoid about > what might happen in fork_and_exec. Actually there's a minor bug > in that code because of the use of AllocateHeap. > > > > FreeHeap(cmd); > > if (status == -1) { > > warning(cmd); > > > > tom > > > > On Aug 4, 2010, at 3:01 PM, Chuck Rasbold wrote: > > > > > Internally, we did discuss the "char buf[len]" construct, but > forgot about the SunStudio compilers. Sorry about that. > > > > > > I've changed the new code to use AllocateHeap() and > FreeHeap(), as does the currently existing code within the #ifdef > KERNEL. > > > > > > And then I put a fix and a clean-up within that #ifdef, so the > code is more consistent throughout. > > > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > > > > -- Chuck > > > > > > > > > On Wed, Aug 4, 2010 at 1:28 PM, Paul Hohensee > > wrote: > > > No 'new' and 'delete' in the hotspot source code please. Use > > > NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. > > > > > > Paul > > > > > > > > > On 8/4/10 4:15 PM, Kelly O'Hair wrote: > > > > > > On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: > > > > > > The SunStudio compiler doesn't like this construct: > > > > > > + size_t len = strlen(msg) + strlen(name) + > strlen(sub_msg) + strlen(ebuf) + 1; > > > + char buf[len]; > > > > > > > > > I wondered about that. > > > > > > so I think you'll have to use another fixed size buffer. > > > > > > or char * buf = new char[len]; > > > > > > and a delete [] buf > > > ??? > > > > > > -kto > > > > > > > > > tom > > > > > > On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: > > > > > > Thanks, John. > > > > > > The nits have been fixed and the webrev updated. > > > > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > > > > -- Chuck > > > > > > On Tue, Aug 3, 2010 at 4:36 PM, John Coomes > > wrote: > > > Chuck Rasbold (rasbold at google.com ) > wrote: > > > http://cr.openjdk.java.net/~rasbold/6378314/ > > > > > > > Fixed: 6378314: Bad warning message when agent library not > found. local > > > directory is not searched. > > > Contributed-by: jeremymanson at google.com > > > > > > > Print a more detailed error message for agent library load > failure. > > > > > > Hi Chuck & Jeremy, > > > > > > Looks ok to me, aside from a couple of nits: use jio_snprintf > instead > > > of sprintf, and strlen returns a size_t, so use that to > declare len. > > > > > > -John > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100805/badc7d9c/attachment-0001.html From rasbold at google.com Thu Aug 5 15:24:02 2010 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 5 Aug 2010 15:24:02 -0700 Subject: Review request: 6378314: Bad warning message when agent library not found. local directory is not searched. In-Reply-To: <4C5B03DC.7090903@oracle.com> References: <19544.42999.632063.746834@oracle.com> <640919F7-9D1A-477E-B81A-94C96BB22A31@oracle.com> <4C59CD6A.7030303@oracle.com> <4839A7EC-6125-4D65-9930-7D0101ACDCD4@oracle.com> <4C5B03DC.7090903@oracle.com> Message-ID: Thanks, Coleen. Agreed that vm_exit_during_initialization makes dead code out of the calls to FREE_C_HEAP_ARRAY. Just trying to be a good citizen in case that vm_exit call turns into something else. -- Chuck On Thu, Aug 5, 2010 at 11:33 AM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > Tom and Chuck, I can push it since it fixed my bug under kernel, it's the > least I can do. And the code looks fine except vm_exit_during_initialization > doesn't return so I don't think these things aren't actually freed. It > doens't matter because vm_exit_during_initialization() currently exits. > Thanks, > Coleen > > > On 08/05/10 14:10, Chuck Rasbold wrote: > > I haven't had any other volunteers yet. > > Thanks for making it happen. > > On Thu, Aug 5, 2010 at 10:36 AM, Tom Rodriguez wrote: > >> I hadn't considered that. That seems fine then. If no one else has >> volunteered to push this, I will take care of it. >> >> tom >> >> On Aug 5, 2010, at 8:01 AM, Chuck Rasbold wrote: >> >> > I think it is too soon in VM startup to use resource allocation. I've >> switched to C_HEAP allocation, instead. >> > >> > I applied changes to the KERNEL chunk of code to make it consistent. I >> can't/won't test that code. Let me know if you'd rather me leave it alone. >> > >> > Webrev updated. >> > >> > http://cr.openjdk.java.net/~rasbold/6378314/ >> > >> > -- Chuck >> > >> > On Wed, Aug 4, 2010 at 4:28 PM, Tom Rodriguez >> wrote: >> > I think simply allocating using NEW_RESOURCE_ARRAY(char, len) will be >> fine/better. The use of AllocateHeap in the ifdef KERNEL piece is kind of >> odd to me. Maybe they are being paranoid about what might happen in >> fork_and_exec. Actually there's a minor bug in that code because of the use >> of AllocateHeap. >> > >> > FreeHeap(cmd); >> > if (status == -1) { >> > warning(cmd); >> > >> > tom >> > >> > On Aug 4, 2010, at 3:01 PM, Chuck Rasbold wrote: >> > >> > > Internally, we did discuss the "char buf[len]" construct, but forgot >> about the SunStudio compilers. Sorry about that. >> > > >> > > I've changed the new code to use AllocateHeap() and FreeHeap(), as >> does the currently existing code within the #ifdef KERNEL. >> > > >> > > And then I put a fix and a clean-up within that #ifdef, so the code is >> more consistent throughout. >> > > >> > > http://cr.openjdk.java.net/~rasbold/6378314/ >> > > >> > > -- Chuck >> > > >> > > >> > > On Wed, Aug 4, 2010 at 1:28 PM, Paul Hohensee < >> paul.hohensee at oracle.com> wrote: >> > > No 'new' and 'delete' in the hotspot source code please. Use >> > > NEW_RESOURCE_ARRAY and FREE_RESOURCE_ARRAY. >> > > >> > > Paul >> > > >> > > >> > > On 8/4/10 4:15 PM, Kelly O'Hair wrote: >> > > >> > > On Aug 4, 2010, at 11:43 AM, Tom Rodriguez wrote: >> > > >> > > The SunStudio compiler doesn't like this construct: >> > > >> > > + size_t len = strlen(msg) + strlen(name) + strlen(sub_msg) + >> strlen(ebuf) + 1; >> > > + char buf[len]; >> > > >> > > >> > > I wondered about that. >> > > >> > > so I think you'll have to use another fixed size buffer. >> > > >> > > or char * buf = new char[len]; >> > > >> > > and a delete [] buf >> > > ??? >> > > >> > > -kto >> > > >> > > >> > > tom >> > > >> > > On Aug 4, 2010, at 11:20 AM, Chuck Rasbold wrote: >> > > >> > > Thanks, John. >> > > >> > > The nits have been fixed and the webrev updated. >> > > >> > > http://cr.openjdk.java.net/~rasbold/6378314/ >> > > >> > > -- Chuck >> > > >> > > On Tue, Aug 3, 2010 at 4:36 PM, John Coomes >> wrote: >> > > Chuck Rasbold (rasbold at google.com) wrote: >> > > http://cr.openjdk.java.net/~rasbold/6378314/ >> > > >> > > Fixed: 6378314: Bad warning message when agent library not found. >> local >> > > directory is not searched. >> > > Contributed-by: jeremymanson at google.com >> > > >> > > Print a more detailed error message for agent library load failure. >> > > >> > > Hi Chuck & Jeremy, >> > > >> > > Looks ok to me, aside from a couple of nits: use jio_snprintf instead >> > > of sprintf, and strlen returns a size_t, so use that to declare len. >> > > >> > > -John >> > > >> > > >> > > >> > > >> > > >> > >> > >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100805/8dc7286a/attachment.html From coleen.phillimore at oracle.com Tue Aug 10 19:53:25 2010 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 11 Aug 2010 02:53:25 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6378314: Bad warning message when agent library not found. local directory is not searched. Message-ID: <20100811025327.63CC247083@hg.openjdk.java.net> Changeset: ab3fd720516c Author: rasbold Date: 2010-08-10 19:17 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ab3fd720516c 6378314: Bad warning message when agent library not found. local directory is not searched. Summary: Print a more detailed error message for agent library load failure. Reviewed-by: jcoomes, never, ohair, coleenp Contributed-by: jeremymanson at google.com ! src/share/vm/runtime/thread.cpp From jeremymanson at google.com Thu Aug 12 11:01:53 2010 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 12 Aug 2010 11:01:53 -0700 Subject: RDTSCP and System.nanoTime Message-ID: Hi folks, Motivation: the overhead of System.nanoTime and System.currentTimeMillis on Linux is pretty awful if you are trying to use them frequently. The motivation for not replacing System.nanoTime with a RDTSC-based approach was, as I understand it, based on two things: 1) The older timestamp counters were processor-cycle based, and shut down when the system was in power-savings mode, and 2) It used to be impossible to compensate for TSC drift between processors. The Nehalem architecture seems to have fixed these problems with Invariant TSC (which runs at a constant rate regardless of power state) and support for the IA32_TSC_AUX register (which tells you what CPU you are using when you read the counter). See section 16.11.1 and 16.11.2 of: http://www.intel.com/Assets/PDF/manual/253668.pdf I don't see code that looks like this in os_linux.cpp, so I was wondering if you guys had any plans to support it. Thanks! Jeremy From David.Holmes at ORACLE.COM Thu Aug 12 13:37:47 2010 From: David.Holmes at ORACLE.COM (David Holmes) Date: Fri, 13 Aug 2010 06:37:47 +1000 Subject: RDTSCP and System.nanoTime In-Reply-To: References: Message-ID: <4C645B9B.9090600@oracle.com> Hi Jeremy, nanoTime has always been implemented using the highest-resolution time source exposed by the OS, so as soon as Linux uses a reliable-TSC (for CLOCK_MONOTONIC) the VM would utilize it. (Solaris jumps through hoops to make the TSC "reliable"). Doing a CPU specific nanoTime could be entertained if it were worthwhile. (But people have more issues with currentTimeMillis() performance than nanoTime in general). It's a pity that Intel didn't also make the frequency available as calculating that is a PITA. :) Also note: "IA32_TSC_AUX provides a 32-bit field that is initialized by privileged software with a signature value (for example, a logical processor ID)." the content of the aux reg is not required to be a processor id. I don't see anything that tells you how to find out what it actually is. Cheers, David Holmes Jeremy Manson said the following on 08/13/10 04:01: > Hi folks, > > Motivation: the overhead of System.nanoTime and > System.currentTimeMillis on Linux is pretty awful if you are trying to > use them frequently. > > The motivation for not replacing System.nanoTime with a RDTSC-based > approach was, as I understand it, based on two things: > > 1) The older timestamp counters were processor-cycle based, and shut > down when the system was in power-savings mode, and > > 2) It used to be impossible to compensate for TSC drift between processors. > > The Nehalem architecture seems to have fixed these problems with > Invariant TSC (which runs at a constant rate regardless of power > state) and support for the IA32_TSC_AUX register (which tells you what > CPU you are using when you read the counter). See section 16.11.1 and > 16.11.2 of: > > http://www.intel.com/Assets/PDF/manual/253668.pdf > > I don't see code that looks like this in os_linux.cpp, so I was > wondering if you guys had any plans to support it. > > Thanks! > > Jeremy From forax at univ-mlv.fr Fri Aug 13 05:41:31 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 13 Aug 2010 14:41:31 +0200 Subject: Updated ARM Spec In-Reply-To: References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> Message-ID: <4C653D7B.6020001@univ-mlv.fr> Le 13/08/2010 05:28, Neal Gafter a ?crit : > When a stack overflow exception suppresses another exception, I assume > it's suppressed exception list will be set. But since there is only > one such exception allocated by the VM, this will overwrite any data > previously stored there. Will the VM be modified to comply with this > specification by allocating a new stack-overflow exception each time? > Same question for out-of-memory error. > This problem already exists with jdk6. This code change the stack trace of permanently allocated OutOfMerroryError. public static void main(String[] args) { Error last = null; for(int i=0; i<100; i++) { try { Object o = new int[Integer.MAX_VALUE]; } catch (Error e) { StackTraceElement[] stackTrace = e.getStackTrace(); if (stackTrace != null && stackTrace.length>0 && stackTrace[0].getLineNumber() == -3) { e.printStackTrace(); return; } if (last == e) { StackTraceElement element = new StackTraceElement("Foo", "foo", null, -3); e.setStackTrace(new StackTraceElement[]{element}); } last = e; } } } To avoid that the VM has to clear the stacktrace when using the default error: in universe.cpp, in Universe::gen_out_of_memory_error: if (next < 0) { // all preallocated errors have been used. // return default + java_lang_Throwable::clear_stacktrace(default_err); return default_err; } else { And we should do the same for the field suppressed exceptions. R?mi From guanxiaohua at gmail.com Fri Aug 13 09:28:23 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Fri, 13 Aug 2010 11:28:23 -0500 Subject: write barrier and card marking Message-ID: Hi there, I wrote one collector of my own in hotspot, but now I have a problem. In the new collector, I inserted another generation between the defNewGeneration and TenuredGeneration. To collect this new generation, I modified the defNewGeneration collector, which is gc by copying survivors. After the collection on this generation, I am now having an Null pointer exception in the java program. My guess is that the collector failed to identify the live objects in the generation. Here I need some one to tell me if there is any missed modification on the write barrier or card marking. As far as I know, the write barrier works whenever a field write happens, without regards to which generation is influenced. So this means that the card of the written field will be marked. So my problem should be in the closures that check if there are any live objects in the generation. Am I right? Or other than the card scanning, is there anything special that I should process? Thanks a lot! Tony (Xiaohua Guan) From jeremymanson at google.com Fri Aug 13 10:52:25 2010 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 13 Aug 2010 10:52:25 -0700 Subject: RDTSCP and System.nanoTime In-Reply-To: <4C645B9B.9090600@oracle.com> References: <4C645B9B.9090600@oracle.com> Message-ID: Hi David, If the TSC is reliable, and we know its rate, then currentTimeMillis can be calculated by taking the time the usual way once at (roughly) the same time as you read the TSC. You can then figure out the time later by simply reading the TSC and doing arithmetic. You would want to resynchronize pretty often, but not more than, say, once every few seconds. I read "IA32_TSC_AUX provides a 32-bit field that is initialized by privileged software with a signature value (for example, a logical processor ID)." as meaning that it had to be a value unique to that processor, but now that you mention it, I'm not sure where "signature" is defined. Presumably, something very definite and/or well-defined is done by Linux and Windows. It sounds as if the best thing to do is wait and see how these features get implemented. There are probably kernel people we can ask. Jeremy On Thu, Aug 12, 2010 at 1:37 PM, David Holmes wrote: > Hi Jeremy, > > nanoTime has always been implemented using the highest-resolution time > source exposed by the OS, so as soon as Linux uses a reliable-TSC (for > CLOCK_MONOTONIC) the VM would utilize it. (Solaris jumps through hoops to > make the TSC "reliable"). > > Doing a CPU specific nanoTime could be entertained if it were worthwhile. > (But people have more issues with currentTimeMillis() performance than > nanoTime in general). > > It's a pity that Intel didn't also make the frequency available as > calculating that is a PITA. :) > > Also note: > > "IA32_TSC_AUX provides a 32-bit field that is initialized by privileged > software with a signature value (for example, a logical processor ID)." > > the content of the aux reg is not required to be a processor id. I don't see > anything that tells you how to find out what it actually is. > > Cheers, > David Holmes > > Jeremy Manson said the following on 08/13/10 04:01: >> >> Hi folks, >> >> Motivation: the overhead of System.nanoTime and >> System.currentTimeMillis on Linux is pretty awful if you are trying to >> use them frequently. >> >> The motivation for not replacing System.nanoTime with a RDTSC-based >> approach was, as I understand it, based on two things: >> >> 1) The older timestamp counters were processor-cycle based, and shut >> down when the system was in power-savings mode, and >> >> 2) It used to be impossible to compensate for TSC drift between >> processors. >> >> The Nehalem architecture seems to have fixed these problems with >> Invariant TSC (which runs at a constant rate regardless of power >> state) and support for the IA32_TSC_AUX register (which tells you what >> CPU you are using when you read the counter). ?See section 16.11.1 and >> 16.11.2 of: >> >> http://www.intel.com/Assets/PDF/manual/253668.pdf >> >> I don't see code that looks like this in os_linux.cpp, so I was >> wondering if you guys had any plans to support it. >> >> Thanks! >> >> Jeremy > From David.Holmes at oracle.com Fri Aug 13 16:29:24 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 14 Aug 2010 09:29:24 +1000 Subject: RDTSCP and System.nanoTime In-Reply-To: References: <4C645B9B.9090600@oracle.com> Message-ID: <4C65D554.6080308@oracle.com> Jeremy Manson said the following on 08/14/10 03:52: > If the TSC is reliable, and we know its rate, then currentTimeMillis > can be calculated by taking the time the usual way once at (roughly) > the same time as you read the TSC. You can then figure out the time > later by simply reading the TSC and doing arithmetic. You would want > to resynchronize pretty often, but not more than, say, once every few > seconds. I have no problem with the OS doing this, but I wouldn't want the VM to have to do it. :) > I read "IA32_TSC_AUX provides a 32-bit field that is initialized by > privileged software with a signature value (for example, a logical > processor ID)." as meaning that it had to be a value unique to that > processor, but now that you mention it, I'm not sure where "signature" > is defined. Presumably, something very definite and/or well-defined > is done by Linux and Windows. True even if not a processor id it likely has to be unique to a processor. > It sounds as if the best thing to do is wait and see how these > features get implemented. There are probably kernel people we can > ask. I'm sure if you search lkml there will be some existing discussions on this topic. David > > Jeremy > > On Thu, Aug 12, 2010 at 1:37 PM, David Holmes wrote: >> Hi Jeremy, >> >> nanoTime has always been implemented using the highest-resolution time >> source exposed by the OS, so as soon as Linux uses a reliable-TSC (for >> CLOCK_MONOTONIC) the VM would utilize it. (Solaris jumps through hoops to >> make the TSC "reliable"). >> >> Doing a CPU specific nanoTime could be entertained if it were worthwhile. >> (But people have more issues with currentTimeMillis() performance than >> nanoTime in general). >> >> It's a pity that Intel didn't also make the frequency available as >> calculating that is a PITA. :) >> >> Also note: >> >> "IA32_TSC_AUX provides a 32-bit field that is initialized by privileged >> software with a signature value (for example, a logical processor ID)." >> >> the content of the aux reg is not required to be a processor id. I don't see >> anything that tells you how to find out what it actually is. >> >> Cheers, >> David Holmes >> >> Jeremy Manson said the following on 08/13/10 04:01: >>> Hi folks, >>> >>> Motivation: the overhead of System.nanoTime and >>> System.currentTimeMillis on Linux is pretty awful if you are trying to >>> use them frequently. >>> >>> The motivation for not replacing System.nanoTime with a RDTSC-based >>> approach was, as I understand it, based on two things: >>> >>> 1) The older timestamp counters were processor-cycle based, and shut >>> down when the system was in power-savings mode, and >>> >>> 2) It used to be impossible to compensate for TSC drift between >>> processors. >>> >>> The Nehalem architecture seems to have fixed these problems with >>> Invariant TSC (which runs at a constant rate regardless of power >>> state) and support for the IA32_TSC_AUX register (which tells you what >>> CPU you are using when you read the counter). See section 16.11.1 and >>> 16.11.2 of: >>> >>> http://www.intel.com/Assets/PDF/manual/253668.pdf >>> >>> I don't see code that looks like this in os_linux.cpp, so I was >>> wondering if you guys had any plans to support it. >>> >>> Thanks! >>> >>> Jeremy From daniel.daugherty at oracle.com Fri Aug 13 22:18:43 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 14 Aug 2010 05:18:43 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 13 new changesets Message-ID: <20100814051912.7D6B04718A@hg.openjdk.java.net> Changeset: e5dfb3ccb88b Author: kvn Date: 2010-07-23 10:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e5dfb3ccb88b 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() Summary: Add missing is_static guard. Reviewed-by: twisti ! src/share/vm/ci/ciField.cpp ! src/share/vm/opto/macro.cpp Changeset: 99ceb0e99c9e Author: never Date: 2010-07-26 15:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/99ceb0e99c9e Merge Changeset: 66c5dadb4d61 Author: kvn Date: 2010-07-30 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/66c5dadb4d61 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() Summary: set Z = 0 (not equal) before repne_scan() to indicate that class was not found when RCX == 0. Reviewed-by: never, phh ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 0e35fa8ebccd Author: kvn Date: 2010-08-03 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0e35fa8ebccd 6973963: SEGV in ciBlock::start_bci() with EA Summary: Added more checks into ResourceObj and growableArray to verify correctness of allocation type. Reviewed-by: never, coleenp, dholmes ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/utilities/growableArray.hpp Changeset: 0e09207fc81b Author: kvn Date: 2010-08-04 17:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0e09207fc81b 6974682: CTW: assert(target != NULL) failed: must not be null Summary: Add address table size to constant section size. Reviewed-by: never ! src/share/vm/opto/output.cpp Changeset: fb8abd207dbe Author: kvn Date: 2010-08-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fb8abd207dbe 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 Summary: Tell C++ to not inline so much by using flag -xspace. Reviewed-by: ysr ! make/solaris/makefiles/sparcWorks.make Changeset: 2dfd013a7465 Author: kvn Date: 2010-08-09 15:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2dfd013a7465 6975078: assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena() Summary: Pass the check in ResourceObj() if _allocation value is already set and object is allocated on stack. Reviewed-by: dholmes, johnc ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: f4f596978298 Author: never Date: 2010-08-09 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f4f596978298 Merge ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 36519c19beeb Author: never Date: 2010-08-10 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/36519c19beeb 6975027: use of movptr to set length of array Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 4a665be40fd3 Author: twisti Date: 2010-08-11 01:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4a665be40fd3 6975855: don't emit deopt MH handler in C1 if not required Summary: This CR implements the same for C1 as 6926782 for C2. Reviewed-by: never ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/code/nmethod.cpp Changeset: d2ede61b7a12 Author: twisti Date: 2010-08-11 05:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d2ede61b7a12 6976186: integrate Shark HotSpot changes Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure. Reviewed-by: kvn, twisti Contributed-by: Gary Benson ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/gcc.make + make/linux/makefiles/shark.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! src/cpu/zero/vm/disassembler_zero.hpp + src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.cpp + src/share/vm/includeDB_shark ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp + src/share/vm/shark/llvmHeaders.hpp + src/share/vm/shark/llvmValue.hpp + src/share/vm/shark/sharkBlock.cpp + src/share/vm/shark/sharkBlock.hpp + src/share/vm/shark/sharkBuilder.cpp + src/share/vm/shark/sharkBuilder.hpp + src/share/vm/shark/sharkCacheDecache.cpp + src/share/vm/shark/sharkCacheDecache.hpp + src/share/vm/shark/sharkCodeBuffer.hpp + src/share/vm/shark/sharkCompiler.cpp + src/share/vm/shark/sharkCompiler.hpp + src/share/vm/shark/sharkConstant.cpp + src/share/vm/shark/sharkConstant.hpp + src/share/vm/shark/sharkContext.cpp + src/share/vm/shark/sharkContext.hpp + src/share/vm/shark/sharkEntry.hpp + src/share/vm/shark/sharkFunction.cpp + src/share/vm/shark/sharkFunction.hpp + src/share/vm/shark/sharkInliner.cpp + src/share/vm/shark/sharkInliner.hpp + src/share/vm/shark/sharkIntrinsics.cpp + src/share/vm/shark/sharkIntrinsics.hpp + src/share/vm/shark/sharkInvariants.cpp + src/share/vm/shark/sharkInvariants.hpp + src/share/vm/shark/sharkMemoryManager.cpp + src/share/vm/shark/sharkMemoryManager.hpp + src/share/vm/shark/sharkNativeWrapper.cpp + src/share/vm/shark/sharkNativeWrapper.hpp + src/share/vm/shark/sharkRuntime.cpp + src/share/vm/shark/sharkRuntime.hpp + src/share/vm/shark/sharkStack.cpp + src/share/vm/shark/sharkStack.hpp + src/share/vm/shark/sharkState.cpp + src/share/vm/shark/sharkState.hpp + src/share/vm/shark/sharkStateScanner.cpp + src/share/vm/shark/sharkStateScanner.hpp + src/share/vm/shark/sharkTopLevelBlock.cpp + src/share/vm/shark/sharkTopLevelBlock.hpp + src/share/vm/shark/sharkType.hpp + src/share/vm/shark/sharkValue.cpp + src/share/vm/shark/sharkValue.hpp + src/share/vm/shark/shark_globals.cpp + src/share/vm/shark/shark_globals.hpp ! src/share/vm/utilities/macros.hpp Changeset: 6c9cc03d8726 Author: kvn Date: 2010-08-11 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6c9cc03d8726 6973329: C2 with Zero based COOP produces code with broken anti-dependency on x86 Summary: Recompile without subsuming loads if RA try to clone a node with anti_dependence. Reviewed-by: never ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/reg_split.cpp + test/compiler/6973329/Test.java Changeset: 21e519b91576 Author: dcubed Date: 2010-08-13 07:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/21e519b91576 Merge ! src/share/vm/runtime/thread.cpp From David.Holmes at oracle.com Fri Aug 13 16:23:10 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 14 Aug 2010 09:23:10 +1000 Subject: write barrier and card marking In-Reply-To: References: Message-ID: <4C65D3DE.5050803@oracle.com> Tony, This is a GC question not a runtime question so I've cc'ed the GC list and bcc'ed the runtime list. David Tony Guan said the following on 08/14/10 02:28: > Hi there, > > I wrote one collector of my own in hotspot, but now I have a problem. > In the new collector, I inserted another generation between the > defNewGeneration and TenuredGeneration. To collect this new > generation, I modified the defNewGeneration collector, which is gc by > copying survivors. > > After the collection on this generation, I am now having an Null > pointer exception in the java program. My guess is that the collector > failed to identify the live objects in the generation. Here I need > some one to tell me if there is any missed modification on the write > barrier or card marking. > > As far as I know, the write barrier works whenever a field write > happens, without regards to which generation is influenced. So this > means that the card of the written field will be marked. So my problem > should be in the closures that check if there are any live objects in > the generation. Am I right? > > Or other than the card scanning, is there anything special that I > should process? > > Thanks a lot! > > > Tony (Xiaohua Guan) From coleen.phillimore at oracle.com Thu Aug 19 18:47:03 2010 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 20 Aug 2010 01:47:03 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6885308: The incorrect -XX:StackRedPages, -XX:StackShadowPages, -XX:StackYellowPages could cause VM crash Message-ID: <20100820014705.A4CDE472E6@hg.openjdk.java.net> Changeset: f8c5d1bdaad4 Author: ptisnovs Date: 2010-08-19 14:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f8c5d1bdaad4 6885308: The incorrect -XX:StackRedPages, -XX:StackShadowPages, -XX:StackYellowPages could cause VM crash Summary: Test minimal stack sizes given (also fixed linux compilation error) Reviewed-by: never, phh, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp From mandy.chung at oracle.com Fri Aug 20 14:50:52 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Aug 2010 14:50:52 -0700 Subject: Updated ARM Spec In-Reply-To: <4C653D7B.6020001@univ-mlv.fr> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> Message-ID: <4C6EF8BC.6000407@oracle.com> Hi Remi, R?mi Forax wrote: > Le 13/08/2010 05:28, Neal Gafter a ?crit : >> When a stack overflow exception suppresses another exception, I assume >> it's suppressed exception list will be set. But since there is only >> one such exception allocated by the VM, this will overwrite any data >> previously stored there. Will the VM be modified to comply with this >> specification by allocating a new stack-overflow exception each time? >> Same question for out-of-memory error. >> > > This problem already exists with jdk6. > This code change the stack trace of permanently allocated > OutOfMerroryError. > > public static void main(String[] args) { > Error last = null; > > for(int i=0; i<100; i++) { > try { > Object o = new int[Integer.MAX_VALUE]; > } catch (Error e) { > StackTraceElement[] stackTrace = e.getStackTrace(); > if (stackTrace != null && stackTrace.length>0 && > stackTrace[0].getLineNumber() == -3) { > e.printStackTrace(); > return; > } > > if (last == e) { > StackTraceElement element = new StackTraceElement("Foo", > "foo", null, -3); > e.setStackTrace(new StackTraceElement[]{element}); > } > last = e; > } > } > } > > > > To avoid that the VM has to clear the stacktrace when using the > default error: > in universe.cpp, in Universe::gen_out_of_memory_error: > > if (next < 0) { > // all preallocated errors have been used. > // return default > + java_lang_Throwable::clear_stacktrace(default_err); > return default_err; > } else { > > This is indeed a bug and I file 6978918 to fix it. We should clear the stacktrace and the suppressed exception fields as you suggest. Thanks Mandy > And we should do the same for the field suppressed exceptions. > > R?mi > From forax at univ-mlv.fr Sat Aug 21 02:27:27 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 21 Aug 2010 11:27:27 +0200 Subject: Updated ARM Spec In-Reply-To: <4C6EF8BC.6000407@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C6EF8BC.6000407@oracle.com> Message-ID: <4C6F9BFF.6000101@univ-mlv.fr> Le 20/08/2010 23:50, Mandy Chung a ?crit : > Hi Remi, Thanks Mandy. R?mi > > R?mi Forax wrote: >> Le 13/08/2010 05:28, Neal Gafter a ?crit : >>> When a stack overflow exception suppresses another exception, I assume >>> it's suppressed exception list will be set. But since there is only >>> one such exception allocated by the VM, this will overwrite any data >>> previously stored there. Will the VM be modified to comply with this >>> specification by allocating a new stack-overflow exception each time? >>> Same question for out-of-memory error. >> >> This problem already exists with jdk6. >> This code change the stack trace of permanently allocated >> OutOfMerroryError. >> >> public static void main(String[] args) { >> Error last = null; >> >> for(int i=0; i<100; i++) { >> try { >> Object o = new int[Integer.MAX_VALUE]; >> } catch (Error e) { >> StackTraceElement[] stackTrace = e.getStackTrace(); >> if (stackTrace != null && stackTrace.length>0 && >> stackTrace[0].getLineNumber() == -3) { >> e.printStackTrace(); >> return; >> } >> >> if (last == e) { >> StackTraceElement element = new StackTraceElement("Foo", >> "foo", null, -3); >> e.setStackTrace(new StackTraceElement[]{element}); >> } >> last = e; >> } >> } >> } >> >> >> >> To avoid that the VM has to clear the stacktrace when using the >> default error: >> in universe.cpp, in Universe::gen_out_of_memory_error: >> >> if (next < 0) { >> // all preallocated errors have been used. >> // return default >> + java_lang_Throwable::clear_stacktrace(default_err); >> return default_err; >> } else { >> >> > > This is indeed a bug and I file 6978918 to fix it. We should clear > the stacktrace and the suppressed exception fields as you suggest. > Thanks > Mandy > >> And we should do the same for the field suppressed exceptions. >> >> R?mi >> > From David.Holmes at oracle.com Mon Aug 23 02:35:59 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2010 19:35:59 +1000 Subject: Updated ARM Spec In-Reply-To: <4C653D7B.6020001@univ-mlv.fr> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> Message-ID: <4C7240FF.7020209@oracle.com> Remi, I think there is some confusion over the use of pre-allocated exceptions here. For OutOfMemoryEror we have two kinds of pre-allocated exceptions for the general case of exhausting the Java heap. First we have PreallocatedOutOfMemoryErrorCount (default 4) OOME instances, which have space for a backtrace allocated. These instances can only be thrown once and so can only have one real backtrace. Of course application code can mutate that stacktrace but that won't affect any other point where OOME is thrown as it won't be that OOME. In addition there is one preallocated OOME instance that has no backtrace allocated for it. Hence when it gets thrown no backtrace is filled in and there is nothing for the application code to mutate. This single instance can be thrown by multiple threads in multiple circumstances without harm. Similarly there are a bunch of pre-allocated OOME objects, without backtraces, for special conditions like maximum array size being exceeded etc. None of the other special pre-allocated instances (NPE, ArithmeticException, ...) have a backtrace either. So there is no need for the VM to clear the backtrace before throwing any pre-allocated exception instance. The "suppressedException" array as I currently understand it would need to be cleared, if the pre-allocated instances with no backtrace can still contain "suppressedExceptions" - which I believe they can. Aside: StackOverflowException is created on demand, not pre-allocated, in Hotspot. David Holmes ------------ R?mi Forax said the following on 08/13/10 22:41: > Le 13/08/2010 05:28, Neal Gafter a ?crit : >> When a stack overflow exception suppresses another exception, I assume >> it's suppressed exception list will be set. But since there is only >> one such exception allocated by the VM, this will overwrite any data >> previously stored there. Will the VM be modified to comply with this >> specification by allocating a new stack-overflow exception each time? >> Same question for out-of-memory error. >> > > This problem already exists with jdk6. > This code change the stack trace of permanently allocated > OutOfMerroryError. > > public static void main(String[] args) { > Error last = null; > > for(int i=0; i<100; i++) { > try { > Object o = new int[Integer.MAX_VALUE]; > } catch (Error e) { > StackTraceElement[] stackTrace = e.getStackTrace(); > if (stackTrace != null && stackTrace.length>0 && > stackTrace[0].getLineNumber() == -3) { > e.printStackTrace(); > return; > } > > if (last == e) { > StackTraceElement element = new StackTraceElement("Foo", > "foo", null, -3); > e.setStackTrace(new StackTraceElement[]{element}); > } > last = e; > } > } > } > > > > To avoid that the VM has to clear the stacktrace when using the default > error: > in universe.cpp, in Universe::gen_out_of_memory_error: > > if (next < 0) { > // all preallocated errors have been used. > // return default > + java_lang_Throwable::clear_stacktrace(default_err); > return default_err; > } else { > > > And we should do the same for the field suppressed exceptions. > > R?mi > From David.Holmes at oracle.com Mon Aug 23 02:50:41 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2010 19:50:41 +1000 Subject: Updated ARM Spec In-Reply-To: <4C7240FF.7020209@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> Message-ID: <4C724471.9010606@oracle.com> I said the following on 08/23/10 19:35: > ... > The "suppressedException" array as I currently understand it would need > to be cleared, if the pre-allocated instances with no backtrace can > still contain "suppressedExceptions" - which I believe they can. I just realized however that clearing the suppressed-exception state is simply not an option as the same exception instance could be thrown concurrently in multiple threads. In short these shared immutable exception instances must remain immutable if they are to be shared. Hence they can not contain suppressed-exception information. David Holmes PS: I am not a subscriber to coin-dev. > Aside: StackOverflowException is created on demand, not pre-allocated, > in Hotspot. > > David Holmes > ------------ > > > R?mi Forax said the following on 08/13/10 22:41: >> Le 13/08/2010 05:28, Neal Gafter a ?crit : >>> When a stack overflow exception suppresses another exception, I assume >>> it's suppressed exception list will be set. But since there is only >>> one such exception allocated by the VM, this will overwrite any data >>> previously stored there. Will the VM be modified to comply with this >>> specification by allocating a new stack-overflow exception each time? >>> Same question for out-of-memory error. >>> >> >> This problem already exists with jdk6. >> This code change the stack trace of permanently allocated >> OutOfMerroryError. >> >> public static void main(String[] args) { >> Error last = null; >> >> for(int i=0; i<100; i++) { >> try { >> Object o = new int[Integer.MAX_VALUE]; >> } catch (Error e) { >> StackTraceElement[] stackTrace = e.getStackTrace(); >> if (stackTrace != null && stackTrace.length>0 && >> stackTrace[0].getLineNumber() == -3) { >> e.printStackTrace(); >> return; >> } >> >> if (last == e) { >> StackTraceElement element = new StackTraceElement("Foo", >> "foo", null, -3); >> e.setStackTrace(new StackTraceElement[]{element}); >> } >> last = e; >> } >> } >> } >> >> >> >> To avoid that the VM has to clear the stacktrace when using the >> default error: >> in universe.cpp, in Universe::gen_out_of_memory_error: >> >> if (next < 0) { >> // all preallocated errors have been used. >> // return default >> + java_lang_Throwable::clear_stacktrace(default_err); >> return default_err; >> } else { >> >> >> And we should do the same for the field suppressed exceptions. >> >> R?mi >> From forax at univ-mlv.fr Mon Aug 23 03:06:03 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 23 Aug 2010 12:06:03 +0200 Subject: Updated ARM Spec In-Reply-To: <4C724471.9010606@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> Message-ID: <4C72480B.3050104@univ-mlv.fr> Le 23/08/2010 11:50, David Holmes a ?crit : > I said the following on 08/23/10 19:35: >> ... >> The "suppressedException" array as I currently understand it would >> need to be cleared, if the pre-allocated instances with no backtrace >> can still contain "suppressedExceptions" - which I believe they can. > > I just realized however that clearing the suppressed-exception state > is simply not an option as the same exception instance could be thrown > concurrently in multiple threads. In short these shared immutable > exception instances must remain immutable if they are to be shared. > Hence they can not contain suppressed-exception information. > > David Holmes > > PS: I am not a subscriber to coin-dev. You can explicitly call setStackTrace() on a shared immutable exception, hence there is a problem. addSupressedExceptions() will have the same issue. I think the fix is to: - silently discard the stack trace taken as argument of setStackTrace() if the cause is 'null' (or not 'this') - silently don't register suppressed-exceptions if cause is 'null' R?mi > >> Aside: StackOverflowException is created on demand, not >> pre-allocated, in Hotspot. >> >> David Holmes >> ------------ >> >> >> R?mi Forax said the following on 08/13/10 22:41: >>> Le 13/08/2010 05:28, Neal Gafter a ?crit : >>>> When a stack overflow exception suppresses another exception, I assume >>>> it's suppressed exception list will be set. But since there is only >>>> one such exception allocated by the VM, this will overwrite any data >>>> previously stored there. Will the VM be modified to comply with this >>>> specification by allocating a new stack-overflow exception each time? >>>> Same question for out-of-memory error. >>> >>> This problem already exists with jdk6. >>> This code change the stack trace of permanently allocated >>> OutOfMerroryError. >>> >>> public static void main(String[] args) { >>> Error last = null; >>> >>> for(int i=0; i<100; i++) { >>> try { >>> Object o = new int[Integer.MAX_VALUE]; >>> } catch (Error e) { >>> StackTraceElement[] stackTrace = e.getStackTrace(); >>> if (stackTrace != null && stackTrace.length>0 && >>> stackTrace[0].getLineNumber() == -3) { >>> e.printStackTrace(); >>> return; >>> } >>> >>> if (last == e) { >>> StackTraceElement element = new StackTraceElement("Foo", >>> "foo", null, -3); >>> e.setStackTrace(new StackTraceElement[]{element}); >>> } >>> last = e; >>> } >>> } >>> } >>> >>> >>> >>> To avoid that the VM has to clear the stacktrace when using the >>> default error: >>> in universe.cpp, in Universe::gen_out_of_memory_error: >>> >>> if (next < 0) { >>> // all preallocated errors have been used. >>> // return default >>> + java_lang_Throwable::clear_stacktrace(default_err); >>> return default_err; >>> } else { >>> >>> >>> And we should do the same for the field suppressed exceptions. >>> >>> R?mi >>> From forax at univ-mlv.fr Mon Aug 23 03:12:34 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 23 Aug 2010 12:12:34 +0200 Subject: Updated ARM Spec In-Reply-To: <4C72480B.3050104@univ-mlv.fr> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> Message-ID: <4C724992.1020108@univ-mlv.fr> Le 23/08/2010 12:06, R?mi Forax a ?crit : > Le 23/08/2010 11:50, David Holmes a ?crit : >> I said the following on 08/23/10 19:35: >>> ... >>> The "suppressedException" array as I currently understand it would >>> need to be cleared, if the pre-allocated instances with no backtrace >>> can still contain "suppressedExceptions" - which I believe they can. >> >> I just realized however that clearing the suppressed-exception state >> is simply not an option as the same exception instance could be >> thrown concurrently in multiple threads. In short these shared >> immutable exception instances must remain immutable if they are to be >> shared. Hence they can not contain suppressed-exception information. >> >> David Holmes >> >> PS: I am not a subscriber to coin-dev. > > You can explicitly call setStackTrace() on a shared immutable > exception, hence there is a problem. > addSupressedExceptions() will have the same issue. > > I think the fix is to: > - silently discard the stack trace taken as argument of > setStackTrace() if the cause is 'null' (or not 'this') if cause is null (not this will not work if the is a real cause). > - silently don't register suppressed-exceptions if cause is 'null' > > R?mi R?mi From David.Holmes at oracle.com Mon Aug 23 03:09:55 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2010 20:09:55 +1000 Subject: Updated ARM Spec In-Reply-To: <4C72480B.3050104@univ-mlv.fr> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> Message-ID: <4C7248F3.4010200@oracle.com> R?mi Forax said the following on 08/23/10 20:06: > Le 23/08/2010 11:50, David Holmes a ?crit : >> I said the following on 08/23/10 19:35: >>> ... >>> The "suppressedException" array as I currently understand it would >>> need to be cleared, if the pre-allocated instances with no backtrace >>> can still contain "suppressedExceptions" - which I believe they can. >> >> I just realized however that clearing the suppressed-exception state >> is simply not an option as the same exception instance could be thrown >> concurrently in multiple threads. In short these shared immutable >> exception instances must remain immutable if they are to be shared. >> Hence they can not contain suppressed-exception information. >> >> David Holmes >> >> PS: I am not a subscriber to coin-dev. > > You can explicitly call setStackTrace() on a shared immutable exception, > hence there is a problem. > addSupressedExceptions() will have the same issue. I stand corrected. The Java side of the code couldn't care less about the VM level backtrace - it just installs a Java array. :( > I think the fix is to: > - silently discard the stack trace taken as argument of setStackTrace() > if the cause is 'null' (or not 'this') > - silently don't register suppressed-exceptions if cause is 'null' I think the Java code should be able to recognize a Throwable instance that should not allow these things to be set, and simply ignore the request. However that is a change in the spec for setStackTrace. Suppressed-exceptions could then be modelled like backtrace support - an optional facility generally used but ignored for the pre-allocated immutable instances. David > R?mi > >> >>> Aside: StackOverflowException is created on demand, not >>> pre-allocated, in Hotspot. >>> >>> David Holmes >>> ------------ >>> >>> >>> R?mi Forax said the following on 08/13/10 22:41: >>>> Le 13/08/2010 05:28, Neal Gafter a ?crit : >>>>> When a stack overflow exception suppresses another exception, I assume >>>>> it's suppressed exception list will be set. But since there is only >>>>> one such exception allocated by the VM, this will overwrite any data >>>>> previously stored there. Will the VM be modified to comply with this >>>>> specification by allocating a new stack-overflow exception each time? >>>>> Same question for out-of-memory error. >>>> >>>> This problem already exists with jdk6. >>>> This code change the stack trace of permanently allocated >>>> OutOfMerroryError. >>>> >>>> public static void main(String[] args) { >>>> Error last = null; >>>> >>>> for(int i=0; i<100; i++) { >>>> try { >>>> Object o = new int[Integer.MAX_VALUE]; >>>> } catch (Error e) { >>>> StackTraceElement[] stackTrace = e.getStackTrace(); >>>> if (stackTrace != null && stackTrace.length>0 && >>>> stackTrace[0].getLineNumber() == -3) { >>>> e.printStackTrace(); >>>> return; >>>> } >>>> >>>> if (last == e) { >>>> StackTraceElement element = new StackTraceElement("Foo", >>>> "foo", null, -3); >>>> e.setStackTrace(new StackTraceElement[]{element}); >>>> } >>>> last = e; >>>> } >>>> } >>>> } >>>> >>>> >>>> >>>> To avoid that the VM has to clear the stacktrace when using the >>>> default error: >>>> in universe.cpp, in Universe::gen_out_of_memory_error: >>>> >>>> if (next < 0) { >>>> // all preallocated errors have been used. >>>> // return default >>>> + java_lang_Throwable::clear_stacktrace(default_err); >>>> return default_err; >>>> } else { >>>> >>>> >>>> And we should do the same for the field suppressed exceptions. >>>> >>>> R?mi >>>> > From forax at univ-mlv.fr Mon Aug 23 03:23:34 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 23 Aug 2010 12:23:34 +0200 Subject: Updated ARM Spec In-Reply-To: <4C7248F3.4010200@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> Message-ID: <4C724C26.6040709@univ-mlv.fr> Le 23/08/2010 12:09, David Holmes a ?crit : > R?mi Forax said the following on 08/23/10 20:06: >> Le 23/08/2010 11:50, David Holmes a ?crit : >>> I said the following on 08/23/10 19:35: >>>> ... >>>> The "suppressedException" array as I currently understand it would >>>> need to be cleared, if the pre-allocated instances with no >>>> backtrace can still contain "suppressedExceptions" - which I >>>> believe they can. >>> >>> I just realized however that clearing the suppressed-exception state >>> is simply not an option as the same exception instance could be >>> thrown concurrently in multiple threads. In short these shared >>> immutable exception instances must remain immutable if they are to >>> be shared. Hence they can not contain suppressed-exception information. >>> >>> David Holmes >>> >>> PS: I am not a subscriber to coin-dev. >> >> You can explicitly call setStackTrace() on a shared immutable >> exception, hence there is a problem. >> addSupressedExceptions() will have the same issue. > > I stand corrected. The Java side of the code couldn't care less about > the VM level backtrace - it just installs a Java array. :( > >> I think the fix is to: >> - silently discard the stack trace taken as argument of >> setStackTrace() if the cause is 'null' (or not 'this') >> - silently don't register suppressed-exceptions if cause is 'null' > > I think the Java code should be able to recognize a Throwable instance > that should not allow these things to be set, and simply ignore the > request. However that is a change in the spec for setStackTrace. Yes, setStackTrace() can 'not succeed'. And the way to recognize such Throwable instance is to check is the field 'cause' is null. > > Suppressed-exceptions could then be modelled like backtrace support - > an optional facility generally used but ignored for the pre-allocated > immutable instances. Yes, and the spec must be also updated accordingly. > > David R?mi From David.Holmes at oracle.com Mon Aug 23 03:29:50 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2010 20:29:50 +1000 Subject: Updated ARM Spec In-Reply-To: <4C724C26.6040709@univ-mlv.fr> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> Message-ID: <4C724D9E.8030100@oracle.com> R?mi Forax said the following on 08/23/10 20:23: > Le 23/08/2010 12:09, David Holmes a ?crit : >> R?mi Forax said the following on 08/23/10 20:06: >>> You can explicitly call setStackTrace() on a shared immutable >>> exception, hence there is a problem. >>> addSupressedExceptions() will have the same issue. >> >> I stand corrected. The Java side of the code couldn't care less about >> the VM level backtrace - it just installs a Java array. :( >> >>> I think the fix is to: >>> - silently discard the stack trace taken as argument of >>> setStackTrace() if the cause is 'null' (or not 'this') >>> - silently don't register suppressed-exceptions if cause is 'null' >> >> I think the Java code should be able to recognize a Throwable instance >> that should not allow these things to be set, and simply ignore the >> request. However that is a change in the spec for setStackTrace. > > Yes, setStackTrace() can 'not succeed'. > And the way to recognize such Throwable instance is to check is the > field 'cause' is null. Except if someone invokes setCause(null). By the way, probing further, the non-OOME shared pre-allocated instances do not guard themselves against fillInStackTrace being invoked upon them. That is arguably an additional bug. I say arguably simply because in the circumstances under which those other exceptions are thrown, having a misleading stacktrace is probably the least of the application's worries. David >> Suppressed-exceptions could then be modelled like backtrace support - >> an optional facility generally used but ignored for the pre-allocated >> immutable instances. > > Yes, and the spec must be also updated accordingly. > >> >> David > > R?mi From forax at univ-mlv.fr Mon Aug 23 05:56:56 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 23 Aug 2010 14:56:56 +0200 Subject: Updated ARM Spec In-Reply-To: <4C724D9E.8030100@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> Message-ID: <4C727018.5090409@univ-mlv.fr> Le 23/08/2010 12:29, David Holmes a ?crit : > R?mi Forax said the following on 08/23/10 20:23: >> Le 23/08/2010 12:09, David Holmes a ?crit : >>> R?mi Forax said the following on 08/23/10 20:06: >>>> You can explicitly call setStackTrace() on a shared immutable >>>> exception, hence there is a problem. >>>> addSupressedExceptions() will have the same issue. >>> >>> I stand corrected. The Java side of the code couldn't care less >>> about the VM level backtrace - it just installs a Java array. :( >>> >>>> I think the fix is to: >>>> - silently discard the stack trace taken as argument of >>>> setStackTrace() if the cause is 'null' (or not 'this') >>>> - silently don't register suppressed-exceptions if cause is 'null' >>> >>> I think the Java code should be able to recognize a Throwable >>> instance that should not allow these things to be set, and simply >>> ignore the request. However that is a change in the spec for >>> setStackTrace. >> >> Yes, setStackTrace() can 'not succeed'. >> And the way to recognize such Throwable instance is to check is the >> field 'cause' is null. > > Except if someone invokes setCause(null). setCause(null) should set the field cause to this. For Throwable(null) and Throwable(message, null), null should also be escaped. The other solution is to use the field suppressedExceptions with the invariant that if it's null, it's an immutable shared exception. > > By the way, probing further, the non-OOME shared pre-allocated > instances do not guard themselves against fillInStackTrace being > invoked upon them. That is arguably an additional bug. I say arguably > simply because in the circumstances under which those other exceptions > are thrown, having a misleading stacktrace is probably the least of > the application's worries. yes, you right. > > David R?mi > > >>> Suppressed-exceptions could then be modelled like backtrace support >>> - an optional facility generally used but ignored for the >>> pre-allocated immutable instances. >> >> Yes, and the spec must be also updated accordingly. >> >>> >>> David >> >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100823/cc5eb61f/attachment.html From joe.darcy at oracle.com Mon Aug 23 12:45:19 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 23 Aug 2010 12:45:19 -0700 Subject: Updated ARM Spec In-Reply-To: <4C727018.5090409@univ-mlv.fr> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> Message-ID: <4C72CFCF.5060904@oracle.com> R?mi Forax wrote: > Le 23/08/2010 12:29, David Holmes a ?crit : > >> R?mi Forax said the following on 08/23/10 20:23: >> >>> Le 23/08/2010 12:09, David Holmes a ?crit : >>> >>>> R?mi Forax said the following on 08/23/10 20:06: >>>> >>>>> You can explicitly call setStackTrace() on a shared immutable >>>>> exception, hence there is a problem. >>>>> addSupressedExceptions() will have the same issue. >>>>> >>>> I stand corrected. The Java side of the code couldn't care less >>>> about the VM level backtrace - it just installs a Java array. :( >>>> >>>> >>>>> I think the fix is to: >>>>> - silently discard the stack trace taken as argument of >>>>> setStackTrace() if the cause is 'null' (or not 'this') >>>>> - silently don't register suppressed-exceptions if cause is 'null' >>>>> >>>> I think the Java code should be able to recognize a Throwable >>>> instance that should not allow these things to be set, and simply >>>> ignore the request. However that is a change in the spec for >>>> setStackTrace. >>>> >>> Yes, setStackTrace() can 'not succeed'. >>> And the way to recognize such Throwable instance is to check is the >>> field 'cause' is null. >>> >> Except if someone invokes setCause(null). >> > > setCause(null) should set the field cause to this. > For Throwable(null) and Throwable(message, null), null should also be > escaped. > > The other solution is to use the field suppressedExceptions with the > invariant that if > it's null, it's an immutable shared exception. > > >> By the way, probing further, the non-OOME shared pre-allocated >> instances do not guard themselves against fillInStackTrace being >> invoked upon them. That is arguably an additional bug. I say arguably >> simply because in the circumstances under which those other exceptions >> are thrown, having a misleading stacktrace is probably the least of >> the application's worries. >> > > yes, you right. > > To recap, Throwable objects have several pieces of mutable state: * the cause; this is a write-at-most-once value that can be set set via a constructor, like Throwable(Throwable cause) or Throwable(String message, Throwable cause), or set after construction via the Throwable.initCause method. (Setting the cause to null prevents future assignment.) * the stack trace; set by fillInStackTrace() or setStackTrace(StackTraceElement[] stackTrace) -- there doesn't seem to be any API prohibition against setting the stack trace multiple times * suppressed exceptions : new functionality added to support try-with-resources statements/ARM blocks. Modified via calling addSuppressedException Focusing just on suppressed exceptions, to support the JVM reusing exception objects, the Throwable API should have some idiom to indicate suppressed exception information should *not* be recorded. Logically this amount to having the list of exceptions be a zero-length list which just discards adds. I'm hesitant to overload a null cause with discarding suppressed exceptions too. Instead, I propose the following: * a null value of the suppressedException field indicates addSuppressedException is a no-op. * the suppressedException field is initialized to point to a sentinel list in Throwable, something non-null that can be used for == checks. With this protocol, the "raw" Throwable objects created by the JVM get the addSuppressedException is a no-op behavior for free. * if the first call to addSuppressedException has this as an argument, the suppressedException field is null-ed; otherwise, a list is appended to as usual. Comments? -Joe From David.Holmes at oracle.com Mon Aug 23 17:17:52 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 24 Aug 2010 10:17:52 +1000 Subject: Updated ARM Spec In-Reply-To: <4C72CFCF.5060904@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> Message-ID: <4C730FB0.6030100@oracle.com> Joe Darcy said the following on 08/24/10 05:45: > To recap, Throwable objects have several pieces of mutable state: > > * the cause; this is a write-at-most-once value that can be set set via > a constructor, like Throwable(Throwable cause) or Throwable(String > message, Throwable cause), or set after construction via the > Throwable.initCause method. (Setting the cause to null prevents future > assignment.) > > * the stack trace; set by fillInStackTrace() or > setStackTrace(StackTraceElement[] stackTrace) -- there doesn't seem to > be any API prohibition against setting the stack trace multiple times But note that the VM implements fillInStackTrace and can ignore the request, while setStackTrace is pure Java. > * suppressed exceptions : new functionality added to support > try-with-resources statements/ARM blocks. Modified via calling > addSuppressedException > > Focusing just on suppressed exceptions, to support the JVM reusing > exception objects, the Throwable API should have some idiom to indicate > suppressed exception information should *not* be recorded. Logically > this amount to having the list of exceptions be a zero-length list which > just discards adds. > > I'm hesitant to overload a null cause with discarding suppressed > exceptions too. Instead, I propose the following: > > * a null value of the suppressedException field indicates > addSuppressedException is a no-op. > > * the suppressedException field is initialized to point to a sentinel > list in Throwable, something non-null that can be used for == checks. > With this protocol, the "raw" Throwable objects created by the JVM get > the addSuppressedException is a no-op behavior for free. > > * if the first call to addSuppressedException has this as an argument, > the suppressedException field is null-ed; otherwise, a list is appended > to as usual. > > Comments? It seems to me, inline with what has been written, that Throwable should adopt the overall approach that for each of the cause, stacktrace and suppressedExceptions fields: - null indicates that these fields can not be modified (and is the default we get from the instances pre-allocated in the VM) - the default initialization, via the constructor, is always a non-NULL sentinel value This requires several changes to the existing method specifications. David From daniel.daugherty at oracle.com Mon Aug 23 19:16:27 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 24 Aug 2010 02:16:27 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 49 new changesets Message-ID: <20100824021758.12B66473D7@hg.openjdk.java.net> Changeset: f6f3eef8a521 Author: kevinw Date: 2010-07-30 22:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f6f3eef8a521 6581734: CMS Old Gen's collection usage is zero after GC which is incorrect Summary: Management code enabled for use by a concurrent collector. Reviewed-by: mchung, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/6581734/Test6581734.java Changeset: 63f4675ac87d Author: kevinw Date: 2010-07-31 15:10 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/63f4675ac87d Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp - src/share/vm/runtime/vtune.hpp Changeset: 2d160770d2e5 Author: johnc Date: 2010-08-02 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2d160770d2e5 6814437: G1: remove the _new_refs array Summary: The per-worker _new_refs array is used to hold references that point into the collection set. It is populated during RSet updating and subsequently processed. In the event of an evacuation failure it processed again to recreate the RSets of regions in the collection set. Remove the per-worker _new_refs array by processing the references directly. Use a DirtyCardQueue to hold the cards containing the references so that the RSets of regions in the collection set can be recreated when handling an evacuation failure. Reviewed-by: iveresov, jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.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/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 9d7a8ab3736b Author: tonyp Date: 2010-07-22 10:27 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9d7a8ab3736b 6962589: remove breadth first scanning code from parallel gc Summary: Remove the breadth-first copying order from ParallelScavenge and use depth-first by default. Reviewed-by: jcoomes, ysr, johnc ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/symbolKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 0ce1569c90e5 Author: tonyp Date: 2010-08-04 13:03 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0ce1569c90e5 6963209: G1: remove the concept of abandoned pauses Summary: As part of 6944166 we disabled the concept of abandoned pauses (i.e., if the collection set is empty, we would still try to do a pause even if it is to update the RSets and scan the roots). This changeset removes the code and structures associated with abandoned pauses. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: a03ae377b2e8 Author: johnc Date: 2010-08-06 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a03ae377b2e8 6930581: G1: assert(ParallelGCThreads > 1 || n_yielded() == _hrrs->occupied(),"Should have yielded all the .. Summary: During RSet updating, when ParallelGCThreads is zero, references that point into the collection set are added directly the referenced region's RSet. This can cause the sparse table in the RSet to expand. RSet scanning and the "occupied" routine will then operate on different instances of the sparse table causing the assert to trip. This may also cause some cards added post expansion to be missed during RSet scanning. When ParallelGCThreads is non-zero such references are recorded on the "references to be scanned" queue and the card containing the reference is recorded in a dirty card queue for use in the event of an evacuation failure. Employ the parallel code in the serial case to avoid expanding the RSets of regions in the collection set. Reviewed-by: iveresov, ysr, tonyp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp Changeset: 5f429ee79634 Author: jcoomes Date: 2010-08-09 05:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5f429ee79634 6966222: G1: simplify TaskQueue overflow handling Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 94251661de76 Author: jcoomes Date: 2010-08-09 18:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/94251661de76 6970376: ParNew: shared TaskQueue statistics Reviewed-by: ysr ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp Changeset: a6bff45449bc Author: ysr Date: 2010-08-10 14:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a6bff45449bc 6973570: OrderAccess::storestore() scales poorly on multi-socket x64 and sparc: cache-line ping-ponging Summary: volatile store to static variable removed in favour of a volatile store to stack to avoid excessive cache coherency traffic; verified that the volatile store is not elided by any of our current compilers. Reviewed-by: dholmes, dice, jcoomes, kvn ! src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/runtime/orderAccess.cpp ! src/share/vm/runtime/orderAccess.hpp Changeset: 2d6b74c9a797 Author: jcoomes Date: 2010-08-11 13:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2d6b74c9a797 6976378: ParNew: stats are printed unconditionally in debug builds Reviewed-by: tonyp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp Changeset: 7fcd5f39bd7a Author: johnc Date: 2010-08-14 00:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7fcd5f39bd7a Merge - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: cb4250ef73b2 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cb4250ef73b2 Added tag jdk7-b102 for changeset c5cadf1a0771 ! .hgtags Changeset: efd4401fab1d Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/efd4401fab1d Added tag jdk7-b103 for changeset cb4250ef73b2 ! .hgtags Changeset: cc3fdfeb54b0 Author: trims Date: 2010-07-29 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cc3fdfeb54b0 Merge Changeset: fd2645290e89 Author: trims Date: 2010-07-30 06:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fd2645290e89 6973381: Bump the HS19 build number to 05 Summary: Update the HS19 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 28abe3f6a5f6 Author: trims Date: 2010-08-03 19:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/28abe3f6a5f6 Merge Changeset: b4acf10eb134 Author: trims Date: 2010-08-05 02:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b4acf10eb134 Added tag hs19-b04 for changeset e55900b5c1b8 ! .hgtags Changeset: 6709c14587c2 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6709c14587c2 Added tag jdk7-b104 for changeset b4acf10eb134 ! .hgtags Changeset: 3dc64719cf18 Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3dc64719cf18 Added tag jdk7-b105 for changeset 6709c14587c2 ! .hgtags Changeset: 688a538aa654 Author: trims Date: 2010-08-13 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/688a538aa654 Merge Changeset: 5f3c8db59d83 Author: trims Date: 2010-08-13 10:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5f3c8db59d83 6977051: Bump the HS19 build number to 06 Summary: Update the HS19 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1b81ca701fa5 Author: trims Date: 2010-08-17 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1b81ca701fa5 Merge Changeset: f121b2772674 Author: trims Date: 2010-08-18 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f121b2772674 Merge - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp Changeset: 495caa35b1b5 Author: asaha Date: 2010-08-17 22:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/495caa35b1b5 6977952: Test: Sync missing tests from hs16.3 to hs17.x Reviewed-by: wrockett + test/compiler/6894807/IsInstanceTest.java + test/compiler/6894807/Test6894807.sh + test/runtime/6626217/IFace.java + test/runtime/6626217/Loader2.java + test/runtime/6626217/Test6626217.sh + test/runtime/6626217/You_Have_Been_P0wned.java + test/runtime/6626217/bug_21227.java + test/runtime/6626217/from_loader2.java + test/runtime/6626217/many_loader1.java.foo + test/runtime/6626217/many_loader2.java.foo Changeset: be3f9c242c9d Author: ysr Date: 2010-08-16 15:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/be3f9c242c9d 6948538: CMS: BOT walkers can fall into object allocation and initialization cracks Summary: GC workers now recognize an intermediate transient state of blocks which are allocated but have not yet completed initialization. blk_start() calls do not attempt to determine the size of a block in the transient state, rather waiting for the block to become initialized so that it is safe to query its size. Audited and ensured the order of initialization of object fields (klass, free bit and size) to respect block state transition protocol. Also included some new assertion checking code enabled in debug mode. Reviewed-by: chrisphi, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/includeDB_core ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/blockOffsetTable.inline.hpp ! src/share/vm/runtime/globals.hpp Changeset: 688c3755d7af Author: tonyp Date: 2010-08-17 14:40 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/688c3755d7af 6959014: G1: assert(minimum_desired_capacity <= maximum_desired_capacity) failed: sanity check Summary: There are a few issues in the code that calculates whether to resize the heap and by how much: a) some calculations can overflow 32-bit size_t's, b) min_desired_capacity is not bounded by the max heap size, and c) the assrt that fires is in the wrong place. The fix also includes some tidying up of the related verbose code. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: bb847e31b836 Author: tonyp Date: 2010-08-17 14:40 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bb847e31b836 6974928: G1: sometimes humongous objects are allocated in young regions Summary: as the title says, sometimes we are allocating humongous objects in young regions and we shouldn't. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: b63010841f78 Author: tonyp Date: 2010-08-17 14:40 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b63010841f78 6975964: G1: print out a more descriptive message for evacuation failure when +PrintGCDetails is set Summary: we're renaming "evacuation failure" to "to-space overflow". I'm also piggy-backing a small additional change which removes the "Mark closure took..." output. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 5ed703250bff Author: ysr Date: 2010-08-18 11:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5ed703250bff 6977970: CMS: concurrentMarkSweepGeneration.cpp:7947 assert(addr <= _limit) failed: sweep invariant Summary: Allow for the possibility (when the heap is expanding) that the sweep might skip over and past, rather than necessarily step on, the sweep limit determined at the beginning of a concurrent marking cycle. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 413ad0331a0c Author: johnc Date: 2010-08-18 10:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/413ad0331a0c 6977924: Changes for 6975078 produce build error with certain gcc versions Summary: The changes introduced for 6975078 assign badHeapOopVal to the _allocation field in the ResourceObj class. In 32 bit linux builds with certain versions of gcc this assignment will be flagged as an error while compiling allocation.cpp. In 32 bit builds the constant value badHeapOopVal (which is cast to an intptr_t) is negative. The _allocation field is typed as an unsigned intptr_t and gcc catches this as an error. Reviewed-by: jcoomes, ysr, phh ! src/share/vm/memory/allocation.cpp Changeset: effb55808a18 Author: johnc Date: 2010-08-18 17:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/effb55808a18 Merge Changeset: 1b0104ab1e5e Author: tonyp Date: 2010-08-19 14:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1b0104ab1e5e Merge Changeset: 30266066c77c Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/30266066c77c Added tag jdk7-b106 for changeset 1b81ca701fa5 ! .hgtags Changeset: 295c3ae4ab5b Author: trims Date: 2010-08-19 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/295c3ae4ab5b Added tag hs19-b05 for changeset cc3fdfeb54b0 ! .hgtags Changeset: bf496cbe9b74 Author: trims Date: 2010-08-19 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bf496cbe9b74 Added tag hs19-b06 for changeset 688a538aa654 ! .hgtags Changeset: 0e509ddd9962 Author: trims Date: 2010-08-20 03:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0e509ddd9962 6978726: Bump the HS19 build number to 07 Summary: Update the HS19 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 09cdb1e1c77b Author: trims Date: 2010-08-20 04:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/09cdb1e1c77b Merge - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp Changeset: 71faaa8e3ccc Author: never Date: 2010-08-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/71faaa8e3ccc 6974176: ShouldNotReachHere, instanceKlass.cpp:1426 Reviewed-by: kvn, twisti ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: da877bdc9000 Author: never Date: 2010-08-12 23:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/da877bdc9000 6975006: assert(check.is_deoptimized_frame()) failed: missed deopt Reviewed-by: kvn, twisti ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.cpp Changeset: a62d332029cf Author: never Date: 2010-08-13 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a62d332029cf 6976372: # assert(_owner == Thread::current()) failed: invariant Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 13b87063b4d8 Author: twisti Date: 2010-08-18 01:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/13b87063b4d8 6977640: Zero and Shark fixes Summary: A number of fixes for Zero and Shark. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: f55c4f82ab9d Author: never Date: 2010-08-19 14:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f55c4f82ab9d 6978249: spill between cpu and fpu registers when those moves are fast Reviewed-by: kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/init.cpp Changeset: ee5cc9e78493 Author: never Date: 2010-08-20 09:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ee5cc9e78493 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp Changeset: 52f2bc645da5 Author: ysr Date: 2010-08-19 12:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/52f2bc645da5 6978533: CMS: Elide BOT update asserts until 6977974 is fixed correctly Reviewed-by: jcoomes, jmasa, tonyp ! src/share/vm/memory/blockOffsetTable.hpp Changeset: 66b9f90a9211 Author: tonyp Date: 2010-08-20 13:17 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/66b9f90a9211 Merge Changeset: 26faca352942 Author: tonyp Date: 2010-08-20 12:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/26faca352942 Merge Changeset: 571f6b35140b Author: trims Date: 2010-08-20 12:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/571f6b35140b 6978889: Remove premature change of build number to Hotspot 19 Build 07 Summary: Change the build number back to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b0b9d64ed9bc Author: trims Date: 2010-08-20 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b0b9d64ed9bc 6978915: Remove Mercurial tags for Hotspot 19 Build 06 Summary: Delete the hs19-b06 Hg tag, as it was put on incorrectly Reviewed-by: jcoomes ! .hgtags Changeset: ebfb7c68865e Author: dcubed Date: 2010-08-23 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ebfb7c68865e Merge ! src/share/vm/memory/allocation.cpp ! src/share/vm/runtime/arguments.cpp From david.holmes at oracle.com Thu Aug 26 17:01:21 2010 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 27 Aug 2010 00:01:21 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths Message-ID: <20100827000132.D9F4247483@hg.openjdk.java.net> Changeset: c7004d700b49 Author: dholmes Date: 2010-08-25 21:29 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c7004d700b49 6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths Summary: Disable stack bounds checks in product mode other than for the initial thread Reviewed-by: coleenp, jcoomes, aph ! src/os/linux/vm/os_linux.cpp From keith.mcguigan at oracle.com Fri Aug 27 17:48:48 2010 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Sat, 28 Aug 2010 00:48:48 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6980262: Memory leak when exception is thrown in static initializer Message-ID: <20100828004850.98A00474D1@hg.openjdk.java.net> Changeset: 2528b5bd749c Author: kamg Date: 2010-08-27 15:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2528b5bd749c 6980262: Memory leak when exception is thrown in static initializer Summary: Use resource memory instead of c-heap for the exception message Reviewed-by: phh, jmasa ! src/share/vm/oops/instanceKlass.cpp From daniel.daugherty at oracle.com Fri Aug 27 23:36:26 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 28 Aug 2010 06:36:26 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 5 new changesets Message-ID: <20100828063635.32918474DE@hg.openjdk.java.net> Changeset: 4b29a725c43c Author: jrose Date: 2010-08-20 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4b29a725c43c 6912064: type profiles need to be exploited more for dynamic language support Reviewed-by: kvn ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/globals.hpp Changeset: 53dbe853fb3a Author: kvn Date: 2010-08-23 09:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/53dbe853fb3a 6896381: CTW fails share/vm/ci/bcEscapeAnalyzer.cpp:99, assert(_stack_height < _max_stack,"stack overflow") Summary: Check constant Tag type instead of calling get_constant(). Reviewed-by: never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 3e8fbc61cee8 Author: twisti Date: 2010-08-25 05:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3e8fbc61cee8 6978355: renaming for 6961697 Summary: This is the renaming part of 6961697 to keep the actual changes small for review. Reviewed-by: kvn, never ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/c1/Runtime1.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/ui/FindInCodeCachePanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/libjvm_db.c ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/icache.cpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b4099f5786da Author: never Date: 2010-08-25 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b4099f5786da Merge ! src/share/vm/runtime/globals.hpp Changeset: 8397081c7ac1 Author: dcubed Date: 2010-08-27 21:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8397081c7ac1 Merge From Ivan.Krylov at Sun.COM Mon Aug 30 06:26:25 2010 From: Ivan.Krylov at Sun.COM (Ivan Krylov) Date: Mon, 30 Aug 2010 17:26:25 +0400 Subject: Request for review: 6979444 Message-ID: <4C7BB181.5020009@Sun.Com> Bug Link: http://bugs.sun.com/view_bug.do?bug_id=6979444 Webrev: http://cr.openjdk.java.net/~ikrylov/6979444 The following change effects only nonproduct builds. A new boolean flag is introduced: -XX:+PrintFlagsWithComments It works pretty much like -XX:+PrintFlagsInitial (or -Xprintflags) but adds a doc string to each flag that is present in every flag definition in the corresponding *global*.hpp file. Minor corrections were made to Flag::print_on method to do proper formatting of all 3 flags (more space for flag name and type, printing of double default values). Thanks, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100830/a857991c/attachment.html From keith.mcguigan at oracle.com Mon Aug 30 06:47:58 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 30 Aug 2010 09:47:58 -0400 Subject: Request for review: 6979444 In-Reply-To: <4C7BB181.5020009@Sun.Com> References: <4C7BB181.5020009@Sun.Com> Message-ID: <4C7BB68E.8020009@oracle.com> Looks good. Thanks! -- - Keith Ivan Krylov wrote: > Bug Link: http://bugs.sun.com/view_bug.do?bug_id=6979444 > Webrev: http://cr.openjdk.java.net/~ikrylov/6979444 > > The following change effects only nonproduct builds. A new boolean flag > is introduced: -XX:+PrintFlagsWithComments > It works pretty much like -XX:+PrintFlagsInitial (or -Xprintflags) but > adds a doc string to each flag that is present in every flag definition > in the corresponding *global*.hpp file. > Minor corrections were made to Flag::print_on method to do proper > formatting of all 3 flags (more space for flag name and type, printing > of double default values). > > Thanks, > Ivan > From David.Holmes at oracle.com Mon Aug 30 09:27:02 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 31 Aug 2010 02:27:02 +1000 Subject: Request for review: 6979444 In-Reply-To: <4C7BB181.5020009@Sun.Com> References: <4C7BB181.5020009@Sun.Com> Message-ID: <4C7BDBD6.2020403@oracle.com> Ivan Krylov said the following on 08/30/10 23:26: > Bug Link: http://bugs.sun.com/view_bug.do?bug_id=6979444 > Webrev: http://cr.openjdk.java.net/~ikrylov/6979444 The actual link in your html went to the wrong webrev :) http://cr.openjdk.java.net/%7Ekamg/6930553/webrev.01/ but the real webrev seems ok to me. Thanks, David > > The following change effects only nonproduct builds. A new boolean flag > is introduced: -XX:+PrintFlagsWithComments > It works pretty much like -XX:+PrintFlagsInitial (or -Xprintflags) but > adds a doc string to each flag that is present in every flag definition > in the corresponding *global*.hpp file. > Minor corrections were made to Flag::print_on method to do proper > formatting of all 3 flags (more space for flag name and type, printing > of double default values). > > Thanks, > Ivan > From tom.rodriguez at oracle.com Mon Aug 30 09:55:53 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 30 Aug 2010 09:55:53 -0700 Subject: Request for review: 6979444 In-Reply-To: <4C7BDBD6.2020403@oracle.com> References: <4C7BB181.5020009@Sun.Com> <4C7BDBD6.2020403@oracle.com> Message-ID: <4CECD750-50C7-4C2E-868F-B11F49EF4C3A@oracle.com> I recently moved the PrintFlagsFinal code because there are flags which are adjusted after we complete the flag parsing in arguments.cpp: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/f55c4f82ab9d/src/share/vm/runtime/init.cpp You might want to move your new printing code there, assuming you want to see the final values. tom On Aug 30, 2010, at 9:27 AM, David Holmes wrote: > > > Ivan Krylov said the following on 08/30/10 23:26: >> Bug Link: http://bugs.sun.com/view_bug.do?bug_id=6979444 >> Webrev: http://cr.openjdk.java.net/~ikrylov/6979444 > > The actual link in your html went to the wrong webrev :) > > http://cr.openjdk.java.net/%7Ekamg/6930553/webrev.01/ > > but the real webrev seems ok to me. > > Thanks, > David > >> The following change effects only nonproduct builds. A new boolean flag is introduced: -XX:+PrintFlagsWithComments >> It works pretty much like -XX:+PrintFlagsInitial (or -Xprintflags) but adds a doc string to each flag that is present in every flag definition in the corresponding *global*.hpp file. >> Minor corrections were made to Flag::print_on method to do proper formatting of all 3 flags (more space for flag name and type, printing of double default values). >> Thanks, >> Ivan From Ivan.Krylov at Oracle.com Mon Aug 30 10:11:21 2010 From: Ivan.Krylov at Oracle.com (Ivan Krylov) Date: Mon, 30 Aug 2010 21:11:21 +0400 Subject: Request for review: 6979444 In-Reply-To: <4CECD750-50C7-4C2E-868F-B11F49EF4C3A@oracle.com> References: <4C7BB181.5020009@Sun.Com> <4C7BDBD6.2020403@oracle.com> <4CECD750-50C7-4C2E-868F-B11F49EF4C3A@oracle.com> Message-ID: <4C7BE639.2020000@Oracle.com> > The actual link in your html went to the wrong webrev :) Ah, copy-pasting .. should have sent plain-text.. thanks for catching Tom, To me it does not matter if values are final or initial there. Those values are printed as "typical values". I would actually prefer those values to be consistent for a given platform. The point of this fix is printing flags descriptions. Well, the jprt job is now submitted. I will copy your note to bugster. Thanks, Ivan On 8/30/10 8:55 PM, Tom Rodriguez wrote: > I recently moved the PrintFlagsFinal code because there are flags which are adjusted after we complete the flag parsing in arguments.cpp: > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/f55c4f82ab9d/src/share/vm/runtime/init.cpp > > You might want to move your new printing code there, assuming you want to see the final values. > > tom > > On Aug 30, 2010, at 9:27 AM, David Holmes wrote: > >> >> Ivan Krylov said the following on 08/30/10 23:26: >>> Bug Link: http://bugs.sun.com/view_bug.do?bug_id=6979444 >>> Webrev: http://cr.openjdk.java.net/~ikrylov/6979444 >> The actual link in your html went to the wrong webrev :) >> >> http://cr.openjdk.java.net/%7Ekamg/6930553/webrev.01/ >> >> but the real webrev seems ok to me. >> >> Thanks, >> David >> >>> The following change effects only nonproduct builds. A new boolean flag is introduced: -XX:+PrintFlagsWithComments >>> It works pretty much like -XX:+PrintFlagsInitial (or -Xprintflags) but adds a doc string to each flag that is present in every flag definition in the corresponding *global*.hpp file. >>> Minor corrections were made to Flag::print_on method to do proper formatting of all 3 flags (more space for flag name and type, printing of double default values). >>> Thanks, >>> Ivan -- Oracle Dr. Ivan Krylov | Java SE Licensee Engineer, EMEA | +7.812.334.6368 Oracle Development SPB 10th Krasnoarmeyskaya 22A, Saint-Petersburg, 190103, Russia Software. Hardware. Complete. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100830/171ae656/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100830/171ae656/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: shc.jpg Type: image/jpeg Size: 5215 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100830/171ae656/attachment-0001.jpg