From keith.mcguigan at oracle.com Tue Feb 1 05:11:50 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 1 Feb 2011 08:11:50 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D476DDA.3000207@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> <4D476DDA.3000207@oracle.com> Message-ID: On Jan 31, 2011, at 9:20 PM, David Holmes wrote: > >>> Where we have: >>> >>> 961 void JvmtiDeferredEventQueue::enqueue(const >>> JvmtiDeferredEvent& event) { >>> ... >>> 967 QueueNode* node = new QueueNode(event); >>> >>> and >>> >>> 1007 void JvmtiDeferredEventQueue::add_pending_event( >>> 1008 const JvmtiDeferredEvent& event) { >>> 1009 >>> 1010 QueueNode* node = new QueueNode(event); >>> >>> Will an allocation failure here terminate the VM? I suspect it >>> will but I don't think it should. Can we not add a link field to >>> the event objects rather than have to create Nodes to hold them? >> I can add a NULL check to those spots. There's no need for us to >> segv if we can't allocate memory for this. We do need a C-heap >> allocated object since we're passing these events from thread-to- >> thread. Adding the link in the event object itself wouldn't help - >> it would just mean we have to allocate the event object in C-heap >> instead. > > As per your other email NULL check is pointless as "new" will never > return null but will instead call vm_exit_out_of_memory to abort the > VM - which is exactly my point. I don't believe that a failure to > allocate in this code should be considered a fatal error for the VM. I agree, there may be situations where memory allocation failures should be considered non-fatal, and the Hotspot allocation routines should offer some support for that. However, it's not clear to me that the various specifications we adhere to have "escape-clause" situations where events can be dropped or features scaled back when/if we run into memory constraints. They should, no doubt, but I don't recall seeing anything like that at the present. It's a can of worms that is probably worth opening up, but it's a bigger issue than this bugfix. > I don't understand why we would have to allocate the event objects > in C-heap, all we want is a link field so that they can form their > own queue without the need for wrapper Nodes. > > 447 class JvmtiDeferredEvent VALUE_OBJ_CLASS_SPEC { > 448 friend class JvmtiDeferredEventQueue; > 449 private: > JvmtiDeferredEvent _next; // for chaining events together > public: > JvmtiDeferredEvent next() { return _next; } > void set_next(JvmtiDeferredEvent e) { > assert(_next == NULL, "overwriting linked event!"); > _next = e; > } > > Further this would allow you to dequeue all the events at once > instead of the service thread going through pulling them off one at > a time. That code doesn't work in C++. You can't have a type contain itself. How big would it be? I suppose what you're suggesting is the Java semantics where the '_next' field is a reference/pointer. If so, you've just described the 'QueueNode' class. Could I collapse the definitions and have just one instead of both JvmtiDeferredEvent and QueueNode? Sure, but I see value in having them separate. For one, you can have different allocation schemes - QueueNodes go into the C- heap and JvmtiDeferredEvents can be value objects. Another reason is to separately encapsulate two different concepts that aren't necessarily related (list functionality and event specification). And regardless of where you put the link, the event specification has to be allocated in the C-heap in order to be enqueued on one thread (the compiler thread) and consumed on the other (the service thread) asynchronously. If the compiler thread waited for event to be posted before continuing, then one could conceivably stack-allocate on the compiler thread and pass a reference to the event to the service thread, but making the compiler thread wait introduces deadlock possibilities when run with -Xbatch. Batching is a separate issue altogether. The existing code could be written to batch-process events using the existing classes. >>> 988 if (_queue_head == NULL) { >>> 989 // Just in case this happens in product; it shouldn't be >>> let's not crash >>> 990 return JvmtiDeferredEvent(); >>> 991 } >>> >>> doesn't look right. Are we returning a stack allocated instance >>> here? (There's also a typo in the comment.) >> Yes, we're returning a stack-allocated instance, which returns to >> the caller as a temp and is copied into a local variable there. >> I'll fix the comment. > > It isn't "legal" to return a stack-allocated object from a method. I > expect we'll get away with it but still ... > > Couldn't you just allocate a static instance to use in this case? There's nothing wrong with returning an object by value. > > Ok so in general I like the form of the new architecture but I'm a > bit unclear on the details. In general non-service threads will only > call: > > - enqueue() to add an event > - add_pending_event() to add an event in the special case of a > safepoint being active > - flush_queue() to wait for earlier events to get posted > > The service thread will: > > - loop in wait() until there is an event (enqueue will do the > notifyAll) > - dequeue() to pull off that event Right. > Now it seems that flush_queue is also called by the service thread, > but I can't see where from? It's not called directly, but it could happen if a user's JVMTI compiled-method-load/unload event handler method calls JVMTI's GenerateEvents(), so we need to code defensively here to prevent any inadvertent self-deadlocks. > I'm a little concerned about all the locking/unlocking that seems to > happen; and the fact that there are potentially a lot of spurious > notifications. Though this is mitigated if we only expect a couple > of threads to be involved, there are ways to restructure things so > that event processing can be batched, including a single notifyAll > once all flush events are complete. The enqueue code does not know the state of the service thread (nor should it have to), so it will always have to send a notification to wake it up if it's sleeping (even if the events are batched) And all the waiting code loops checking for conditions, so a spurious notification ought to be harmless. There is a single notifyAll that occurs when flushing is complete. This is implemented by the flush pseudo-event. (see JvmtiDeferredEvent::post()). No doubt this could be restructured a number of different ways, but this way is rather straightforward (easy to analyze) and appears correct. The possibility to batch-process the events in the future is there if we need it for some reason, but I don't see a need for it at the moment. -- - Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110201/b9cfb2c1/attachment-0001.html From coleen.phillimore at oracle.com Tue Feb 1 08:48:14 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Feb 2011 11:48:14 -0500 Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add Message-ID: <4D48394E.3060807@oracle.com> Summary: Write method signature handler under lock to prevent race with growable array resizing Also includes a fix to 6704010 which was broken with -XX:-UseFastSignatureHandlers This change was submitted and tested by the customer. open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 Thanks, Coleen From Dmitry.Samersoff at oracle.com Tue Feb 1 10:14:08 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 1 Feb 2011 10:14:08 -0800 (PST) Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D48394E.3060807@oracle.com> References: <4D48394E.3060807@oracle.com> Message-ID: <4D484D70.20405@oracle.com> Coleen, assert code is not clean for me: if (_handlers != NULL){ } _handlers never checked for NULL before e.g. during printing we use _handlers->length() etc. if we are fighting against race I guess we should take a lock before null check. i.e. MutexLocker mu(SignatureHandlerLibrary_lock); if (_handlers != NULL) { .... -Dmitry On 2011-02-01 19:48, Coleen Phillimore wrote: > Summary: Write method signature handler under lock to prevent race with > growable array resizing > > Also includes a fix to 6704010 which was broken with > -XX:-UseFastSignatureHandlers > > This change was submitted and tested by the customer. > > open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 > > Thanks, > Coleen -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From coleen.phillimore at oracle.com Tue Feb 1 10:20:02 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Feb 2011 10:20:02 -0800 (PST) Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D484D70.20405@oracle.com> References: <4D48394E.3060807@oracle.com> <4D484D70.20405@oracle.com> Message-ID: <4D484ED2.8090802@oracle.com> Dmitry, You are absolutely right. We should check _handlers under the lock too. It could be created in a separate thread. Thanks! Coleen On 2/1/2011 1:14 PM, Dmitry Samersoff wrote: > Coleen, > > assert code is not clean for me: > > if (_handlers != NULL){ > } > > _handlers never checked for NULL before e.g. during printing we > use _handlers->length() etc. > > if we are fighting against race I guess we should take a lock before > null check. > > i.e. > > MutexLocker mu(SignatureHandlerLibrary_lock); > if (_handlers != NULL) { > .... > > -Dmitry > > > On 2011-02-01 19:48, Coleen Phillimore wrote: >> Summary: Write method signature handler under lock to prevent race with >> growable array resizing >> >> Also includes a fix to 6704010 which was broken with >> -XX:-UseFastSignatureHandlers >> >> This change was submitted and tested by the customer. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Tue Feb 1 10:31:23 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 01 Feb 2011 18:31:23 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6588413: Use -fvisibility=hidden for gcc compiles Message-ID: <20110201183129.7055147312@hg.openjdk.java.net> Changeset: d70fe6ab4436 Author: coleenp Date: 2011-02-01 11:23 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d70fe6ab4436 6588413: Use -fvisibility=hidden for gcc compiles Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. Reviewed-by: kamg, never ! make/linux/makefiles/gcc.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h From Dmitry.Samersoff at oracle.com Tue Feb 1 11:42:12 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Feb 2011 22:42:12 +0300 Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D484ED2.8090802@oracle.com> References: <4D48394E.3060807@oracle.com> <4D484D70.20405@oracle.com> <4D484ED2.8090802@oracle.com> Message-ID: <4D486214.9080205@oracle.com> Coleen, Should we NULL-check _handlers in the code also, before accessing it? -Dmitry On 2011-02-01 21:20, Coleen Phillimore wrote: > > Dmitry, You are absolutely right. We should check _handlers under the > lock too. It could be created in a separate thread. > > Thanks! > Coleen > > On 2/1/2011 1:14 PM, Dmitry Samersoff wrote: >> Coleen, >> >> assert code is not clean for me: >> >> if (_handlers != NULL){ >> } >> >> _handlers never checked for NULL before e.g. during printing we >> use _handlers->length() etc. >> >> if we are fighting against race I guess we should take a lock before >> null check. >> >> i.e. >> >> MutexLocker mu(SignatureHandlerLibrary_lock); >> if (_handlers != NULL) { >> .... >> >> -Dmitry >> >> >> On 2011-02-01 19:48, Coleen Phillimore wrote: >>> Summary: Write method signature handler under lock to prevent race with >>> growable array resizing >>> >>> Also includes a fix to 6704010 which was broken with >>> -XX:-UseFastSignatureHandlers >>> >>> This change was submitted and tested by the customer. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 >>> >>> Thanks, >>> Coleen >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From coleen.phillimore at oracle.com Tue Feb 1 11:48:54 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Feb 2011 14:48:54 -0500 Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D486214.9080205@oracle.com> References: <4D48394E.3060807@oracle.com> <4D484D70.20405@oracle.com> <4D484ED2.8090802@oracle.com> <4D486214.9080205@oracle.com> Message-ID: <4D4863A6.7050100@oracle.com> On 2/1/2011 2:42 PM, Dmitry Samersoff wrote: > Coleen, > > Should we NULL-check _handlers in the code also, before accessing it? No, because we create and initialize it just before the code. If 'new' comes back as null, it'll vm_exit_out_of_memory(). see: http://cr.openjdk.java.net/~coleenp/7012088_2/ Thanks, Coleen > > -Dmitry > > > On 2011-02-01 21:20, Coleen Phillimore wrote: >> >> Dmitry, You are absolutely right. We should check _handlers under the >> lock too. It could be created in a separate thread. >> >> Thanks! >> Coleen >> >> On 2/1/2011 1:14 PM, Dmitry Samersoff wrote: >>> Coleen, >>> >>> assert code is not clean for me: >>> >>> if (_handlers != NULL){ >>> } >>> >>> _handlers never checked for NULL before e.g. during printing we >>> use _handlers->length() etc. >>> >>> if we are fighting against race I guess we should take a lock before >>> null check. >>> >>> i.e. >>> >>> MutexLocker mu(SignatureHandlerLibrary_lock); >>> if (_handlers != NULL) { >>> .... >>> >>> -Dmitry >>> >>> >>> On 2011-02-01 19:48, Coleen Phillimore wrote: >>>> Summary: Write method signature handler under lock to prevent race >>>> with >>>> growable array resizing >>>> >>>> Also includes a fix to 6704010 which was broken with >>>> -XX:-UseFastSignatureHandlers >>>> >>>> This change was submitted and tested by the customer. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 >>>> >>>> Thanks, >>>> Coleen >>> >> > > From Dmitry.Samersoff at oracle.com Tue Feb 1 12:01:26 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Feb 2011 23:01:26 +0300 Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D4863A6.7050100@oracle.com> References: <4D48394E.3060807@oracle.com> <4D484D70.20405@oracle.com> <4D484ED2.8090802@oracle.com> <4D486214.9080205@oracle.com> <4D4863A6.7050100@oracle.com> Message-ID: <4D486696.3070809@oracle.com> On 2011-02-01 22:48, Coleen Phillimore wrote: > On 2/1/2011 2:42 PM, Dmitry Samersoff wrote: >> Coleen, >> >> Should we NULL-check _handlers in the code also, before accessing it? > No, because we create and initialize it just before the code. If 'new' > comes back as null, it'll vm_exit_out_of_memory(). > > see: http://cr.openjdk.java.net/~coleenp/7012088_2/ fine for me. -Dmitry > > Thanks, > Coleen >> >> -Dmitry >> >> >> On 2011-02-01 21:20, Coleen Phillimore wrote: >>> >>> Dmitry, You are absolutely right. We should check _handlers under the >>> lock too. It could be created in a separate thread. >>> >>> Thanks! >>> Coleen >>> >>> On 2/1/2011 1:14 PM, Dmitry Samersoff wrote: >>>> Coleen, >>>> >>>> assert code is not clean for me: >>>> >>>> if (_handlers != NULL){ >>>> } >>>> >>>> _handlers never checked for NULL before e.g. during printing we >>>> use _handlers->length() etc. >>>> >>>> if we are fighting against race I guess we should take a lock before >>>> null check. >>>> >>>> i.e. >>>> >>>> MutexLocker mu(SignatureHandlerLibrary_lock); >>>> if (_handlers != NULL) { >>>> .... >>>> >>>> -Dmitry >>>> >>>> >>>> On 2011-02-01 19:48, Coleen Phillimore wrote: >>>>> Summary: Write method signature handler under lock to prevent race >>>>> with >>>>> growable array resizing >>>>> >>>>> Also includes a fix to 6704010 which was broken with >>>>> -XX:-UseFastSignatureHandlers >>>>> >>>>> This change was submitted and tested by the customer. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From coleen.phillimore at oracle.com Tue Feb 1 11:58:56 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Feb 2011 14:58:56 -0500 Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D486696.3070809@oracle.com> References: <4D48394E.3060807@oracle.com> <4D484D70.20405@oracle.com> <4D484ED2.8090802@oracle.com> <4D486214.9080205@oracle.com> <4D4863A6.7050100@oracle.com> <4D486696.3070809@oracle.com> Message-ID: <4D486600.8000004@oracle.com> On 2/1/2011 3:01 PM, Dmitry Samersoff wrote: > On 2011-02-01 22:48, Coleen Phillimore wrote: >> On 2/1/2011 2:42 PM, Dmitry Samersoff wrote: >>> Coleen, >>> >>> Should we NULL-check _handlers in the code also, before accessing it? >> No, because we create and initialize it just before the code. If 'new' >> comes back as null, it'll vm_exit_out_of_memory(). >> >> see: http://cr.openjdk.java.net/~coleenp/7012088_2/ > > fine for me. Thanks Dmitry for finding the assert race. Coleen > > -Dmitry > >> >> Thanks, >> Coleen >>> >>> -Dmitry >>> >>> >>> On 2011-02-01 21:20, Coleen Phillimore wrote: >>>> >>>> Dmitry, You are absolutely right. We should check _handlers under the >>>> lock too. It could be created in a separate thread. >>>> >>>> Thanks! >>>> Coleen >>>> >>>> On 2/1/2011 1:14 PM, Dmitry Samersoff wrote: >>>>> Coleen, >>>>> >>>>> assert code is not clean for me: >>>>> >>>>> if (_handlers != NULL){ >>>>> } >>>>> >>>>> _handlers never checked for NULL before e.g. during printing we >>>>> use _handlers->length() etc. >>>>> >>>>> if we are fighting against race I guess we should take a lock before >>>>> null check. >>>>> >>>>> i.e. >>>>> >>>>> MutexLocker mu(SignatureHandlerLibrary_lock); >>>>> if (_handlers != NULL) { >>>>> .... >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2011-02-01 19:48, Coleen Phillimore wrote: >>>>>> Summary: Write method signature handler under lock to prevent race >>>>>> with >>>>>> growable array resizing >>>>>> >>>>>> Also includes a fix to 6704010 which was broken with >>>>>> -XX:-UseFastSignatureHandlers >>>>>> >>>>>> This change was submitted and tested by the customer. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >>> >> > > From David.Holmes at oracle.com Tue Feb 1 15:38:08 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 02 Feb 2011 09:38:08 +1000 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> <4D476DDA.3000207@oracle.com> Message-ID: <4D489960.7090707@oracle.com> Keith McGuigan said the following on 02/01/11 23:11: > On Jan 31, 2011, at 9:20 PM, David Holmes wrote: >> As per your other email NULL check is pointless as "new" will never >> return null but will instead call vm_exit_out_of_memory to abort the >> VM - which is exactly my point. I don't believe that a failure to >> allocate in this code should be considered a fatal error for the VM. > > I agree, there may be situations where memory allocation failures should > be considered non-fatal, and the Hotspot allocation routines should > offer some support for that. However, it's not clear to me that the > various specifications we adhere to have "escape-clause" situations > where events can be dropped or features scaled back when/if we run into > memory constraints. They should, no doubt, but I don't recall seeing > anything like that at the present. It's a can of worms that is probably > worth opening up, but it's a bigger issue than this bugfix. Given our allocation routines leave a lot to be desired we should strive to avoid the need for dynamic allocation as it introduces new abort points. A program that runs fine today may abort with this fix due to additional C-Heap usage. >> I don't understand why we would have to allocate the event objects in >> C-heap, all we want is a link field so that they can form their own >> queue without the need for wrapper Nodes. >> >> 447 class JvmtiDeferredEvent VALUE_OBJ_CLASS_SPEC { >> 448 friend class JvmtiDeferredEventQueue; >> 449 private: >> JvmtiDeferredEvent _next; // for chaining events together >> public: >> JvmtiDeferredEvent next() { return _next; } >> void set_next(JvmtiDeferredEvent e) { >> assert(_next == NULL, "overwriting linked event!"); >> _next = e; >> } >> >> Further this would allow you to dequeue all the events at once instead >> of the service thread going through pulling them off one at a time. > > That code doesn't work in C++. You can't have a type contain itself. Okay my bad they were supposed to be pointer types (it is a linked-list after all!) > How big would it be? I suppose what you're suggesting is the Java > semantics where the '_next' field is a reference/pointer. If so, you've > just described the 'QueueNode' class. Could I collapse the definitions > and have just one instead of both JvmtiDeferredEvent and QueueNode? > Sure, but I see value in having them separate. For one, you can have > different allocation schemes - QueueNodes go into the C-heap and > JvmtiDeferredEvents can be value objects. Another reason is to > separately encapsulate two different concepts that aren't necessarily > related (list functionality and event specification). The point is to avoid the need to dynamically allocate the QueueNodes. If the elements to be queued are self-linking then you don't need the extra wrapper objects. Take a look at VM_Operations as an example of self-linking objects. It also makes it easy to return a list of events for batch processing, if you chose - ala VM_Operations again. > And regardless of where you put the link, the event specification has to > be allocated in the C-heap ... I don't care about where the events are allocated, that is a totally different issue. The point is to avoid the need to allocate nodes. > Batching is a separate issue altogether. The existing code could be > written to batch-process events using the existing classes. Yes but I think the batching is simpler if the events themselves are linked. >>>> 988 if (_queue_head == NULL) { >>>> 989 // Just in case this happens in product; it shouldn't be >>>> let's not crash >>>> 990 return JvmtiDeferredEvent(); >>>> 991 } >>>> >>>> doesn't look right. Are we returning a stack allocated instance >>>> here? (There's also a typo in the comment.) >>> Yes, we're returning a stack-allocated instance, which returns to the >>> caller as a temp and is copied into a local variable there. I'll fix >>> the comment. >> >> It isn't "legal" to return a stack-allocated object from a method. I >> expect we'll get away with it but still ... >> >> Couldn't you just allocate a static instance to use in this case? > > There's nothing wrong with returning an object by value. Sorry I was thinking this was returning a pointer. So this is utilizing C++ copy-semantics to make a valid copy in the caller when the method returns. Still seems an odd construct to me but I assume C++ deals with it correctly. >> Now it seems that flush_queue is also called by the service thread, >> but I can't see where from? > > It's not called directly, but it could happen if a user's JVMTI > compiled-method-load/unload event handler method calls JVMTI's > GenerateEvents(), so we need to code defensively here to prevent any > inadvertent self-deadlocks. Ok. >> I'm a little concerned about all the locking/unlocking that seems to >> happen; and the fact that there are potentially a lot of spurious >> notifications. ... > > The enqueue code does not know the state of the service thread (nor > should it have to), so it will always have to send a notification to > wake it up if it's sleeping (even if the events are batched) And all the > waiting code loops checking for conditions, so a spurious notification > ought to be harmless. enqueue() is not an issue for notifications, it has to do them. The spurious wakeups are only a performance concern, not a correctness one. > There is a single notifyAll that occurs when flushing is complete. This > is implemented by the flush pseudo-event. (see JvmtiDeferredEvent::post()). But this is a notifyAll per flush-event, which was my point. And combined with the single-event per iteration processing you do get a lot of locking/unlocking (due to the need to unlock when calling event.post()). > No doubt this could be restructured a number of different ways, but this > way is rather straightforward (easy to analyze) and appears correct. > The possibility to batch-process the events in the future is there if we > need it for some reason, but I don't see a need for it at the moment. My mental model for much of this was the vm-operations queue and the batch processing we do there. But if events are sparse then this is not an immediate issue. David > -- > - Keith From coleen.phillimore at oracle.com Tue Feb 1 16:05:14 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Feb 2011 19:05:14 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D489960.7090707@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> <4D476DDA.3000207@oracle.com> <4D489960.7090707@oracle.com> Message-ID: <4D489FBA.7040703@oracle.com> On 2/1/2011 6:38 PM, David Holmes wrote: > Keith McGuigan said the following on 02/01/11 23:11: >> On Jan 31, 2011, at 9:20 PM, David Holmes wrote: >>> As per your other email NULL check is pointless as "new" will never >>> return null but will instead call vm_exit_out_of_memory to abort the >>> VM - which is exactly my point. I don't believe that a failure to >>> allocate in this code should be considered a fatal error for the VM. >> >> I agree, there may be situations where memory allocation failures >> should be considered non-fatal, and the Hotspot allocation routines >> should offer some support for that. However, it's not clear to me >> that the various specifications we adhere to have "escape-clause" >> situations where events can be dropped or features scaled back >> when/if we run into memory constraints. They should, no doubt, but I >> don't recall seeing anything like that at the present. It's a can of >> worms that is probably worth opening up, but it's a bigger issue than >> this bugfix. > > Given our allocation routines leave a lot to be desired we should > strive to avoid the need for dynamic allocation as it introduces new > abort points. A program that runs fine today may abort with this fix > due to additional C-Heap usage. Even though our C heap allocation routines have a mostly undesirable failure mode, these items are not large and cannot be allocated within a ResourceObj or Arena, so really CHeapObj is the only way to allocate them. Are there a lot of these event allocated at one time? Is there a lot of allocation/free calls? Maybe it's worth having some sort of free list to manage these objects, but only if there's an observed performance hit, which is sort of hard to measure with jvmti. Coleen From keith.mcguigan at oracle.com Tue Feb 1 16:26:03 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 1 Feb 2011 19:26:03 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D489960.7090707@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> <4D476DDA.3000207@oracle.com> <4D489960.7090707@oracle.com> Message-ID: On Feb 1, 2011, at 6:38 PM, David Holmes wrote: > The point is to avoid the need to dynamically allocate the > QueueNodes. If the elements to be queued are self-linking then you > don't need the extra wrapper objects. Take a look at VM_Operations > as an example of self-linking objects. > > It also makes it easy to return a list of events for batch > processing, if you chose - ala VM_Operations again. VM_Operations are allocated on the caller's stack and the caller waits and thus his frame exists for the duration of the operation. We can't do that in this situation since the caller of enqueue() does not wait for the event to be dequeued or posted before continuing, thus the caller's frame may be popped and/or reused before the event is picked up by the other (service) thread. So the event needs to live outside of the caller's stack (the caller of enqueue()). The only reasonable place for it to go is into the C-heap. It doesn't matter where the 'next' link lives (internal to or external to JvmtiDeferredEvent), we still going to need to dynamically allocate C-heap memory to store the event. -- - Keith From David.Holmes at oracle.com Tue Feb 1 16:30:45 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 02 Feb 2011 10:30:45 +1000 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> <4D476DDA.3000207@oracle.com> <4D489960.7090707@oracle.com> Message-ID: <4D48A5B5.3010105@oracle.com> Keith McGuigan said the following on 02/02/11 10:26: > On Feb 1, 2011, at 6:38 PM, David Holmes wrote: >> The point is to avoid the need to dynamically allocate the QueueNodes. >> If the elements to be queued are self-linking then you don't need the >> extra wrapper objects. Take a look at VM_Operations as an example of >> self-linking objects. >> >> It also makes it easy to return a list of events for batch processing, >> if you chose - ala VM_Operations again. > > VM_Operations are allocated on the caller's stack and the caller waits > and thus his frame exists for the duration of the operation. We can't > do that in this situation since the caller of enqueue() does not wait > for the event to be dequeued or posted before continuing, thus the > caller's frame may be popped and/or reused before the event is picked up > by the other (service) thread. So the event needs to live outside of > the caller's stack (the caller of enqueue()). The only reasonable place > for it to go is into the C-heap. It doesn't matter where the 'next' > link lives (internal to or external to JvmtiDeferredEvent), we still > going to need to dynamically allocate C-heap memory to store the event. You are completely missing the point. My reference to vm_ops was for their self-linking nature not where they themselves are allocated. Likewise where the events themselves are allocated is not relevant either - we are not changing that. What I am simply saying is that by dynamically allocating QueueNodes on the C-Heap this change introduces a new fatal error condition in the VM. If the events can self-link, as vm-operations do, then you don't need QueueNodes, you don't need dynamic C-Heap allocation and so no new failure mode is introduced. David From David.Holmes at oracle.com Tue Feb 1 16:41:44 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 02 Feb 2011 10:41:44 +1000 Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D4863A6.7050100@oracle.com> References: <4D48394E.3060807@oracle.com> <4D484D70.20405@oracle.com> <4D484ED2.8090802@oracle.com> <4D486214.9080205@oracle.com> <4D4863A6.7050100@oracle.com> Message-ID: <4D48A848.5080602@oracle.com> Coleen Phillimore said the following on 02/02/11 05:48: > On 2/1/2011 2:42 PM, Dmitry Samersoff wrote: >> Coleen, >> >> Should we NULL-check _handlers in the code also, before accessing it? > No, because we create and initialize it just before the code. If 'new' > comes back as null, it'll vm_exit_out_of_memory(). > > see: http://cr.openjdk.java.net/~coleenp/7012088_2/ Here: 1195 #ifdef ASSERT 1196 int handler_index = 0; 1197 int fingerprint_index = 0; 1198 { 1199 // '_handlers' and '_fingerprints' are 'GrowableArray's and are NOT synchronized 1200 // in any way if accessed from multiple threads. To avoid races with another 1201 // thread which may change the arrays in the above, mutex protected block, we 1202 // have to protect this read access here with the same mutex as well! 1203 MutexLocker mu(SignatureHandlerLibrary_lock); 1204 if (_handlers != NULL) { 1205 handler_index = _handlers->find(method->signature_handler()); 1206 fingerprint_index = _fingerprints->find(Fingerprinter(method).fingerprint()); 1207 } 1208 } 1209 assert(method->signature_handler() == Interpreter::slow_signature_handler() || 1210 handler_index == fingerprint_index, "sanity check"); 1211 #endif // ASSERT should we set handler_index and fingerprint_index to different initial values (-1 and -2 ?) so that the assert doesn't accidentally pass? I assume that if _handlers is null then we should have invalid indices but the first clause of the assert should pass. David > Thanks, > Coleen >> >> -Dmitry >> >> >> On 2011-02-01 21:20, Coleen Phillimore wrote: >>> >>> Dmitry, You are absolutely right. We should check _handlers under the >>> lock too. It could be created in a separate thread. >>> >>> Thanks! >>> Coleen >>> >>> On 2/1/2011 1:14 PM, Dmitry Samersoff wrote: >>>> Coleen, >>>> >>>> assert code is not clean for me: >>>> >>>> if (_handlers != NULL){ >>>> } >>>> >>>> _handlers never checked for NULL before e.g. during printing we >>>> use _handlers->length() etc. >>>> >>>> if we are fighting against race I guess we should take a lock before >>>> null check. >>>> >>>> i.e. >>>> >>>> MutexLocker mu(SignatureHandlerLibrary_lock); >>>> if (_handlers != NULL) { >>>> .... >>>> >>>> -Dmitry >>>> >>>> >>>> On 2011-02-01 19:48, Coleen Phillimore wrote: >>>>> Summary: Write method signature handler under lock to prevent race >>>>> with >>>>> growable array resizing >>>>> >>>>> Also includes a fix to 6704010 which was broken with >>>>> -XX:-UseFastSignatureHandlers >>>>> >>>>> This change was submitted and tested by the customer. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> >> > From coleen.phillimore at oracle.com Tue Feb 1 16:49:48 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 01 Feb 2011 19:49:48 -0500 Subject: Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add In-Reply-To: <4D48A848.5080602@oracle.com> References: <4D48394E.3060807@oracle.com> <4D484D70.20405@oracle.com> <4D484ED2.8090802@oracle.com> <4D486214.9080205@oracle.com> <4D4863A6.7050100@oracle.com> <4D48A848.5080602@oracle.com> Message-ID: <4D48AA2C.6020804@oracle.com> On 2/1/2011 7:41 PM, David Holmes wrote: > Coleen Phillimore said the following on 02/02/11 05:48: >> On 2/1/2011 2:42 PM, Dmitry Samersoff wrote: >>> Coleen, >>> >>> Should we NULL-check _handlers in the code also, before accessing it? >> No, because we create and initialize it just before the code. If >> 'new' comes back as null, it'll vm_exit_out_of_memory(). >> >> see: http://cr.openjdk.java.net/~coleenp/7012088_2/ > > Here: > > 1195 #ifdef ASSERT > 1196 int handler_index = 0; > 1197 int fingerprint_index = 0; > 1198 { > 1199 // '_handlers' and '_fingerprints' are 'GrowableArray's and > are NOT synchronized > 1200 // in any way if accessed from multiple threads. To avoid > races with another > 1201 // thread which may change the arrays in the above, mutex > protected block, we > 1202 // have to protect this read access here with the same mutex > as well! > 1203 MutexLocker mu(SignatureHandlerLibrary_lock); > 1204 if (_handlers != NULL) { > 1205 handler_index = _handlers->find(method->signature_handler()); > 1206 fingerprint_index = > _fingerprints->find(Fingerprinter(method).fingerprint()); > 1207 } > 1208 } > 1209 assert(method->signature_handler() == > Interpreter::slow_signature_handler() || > 1210 handler_index == fingerprint_index, "sanity check"); > 1211 #endif // ASSERT > > should we set handler_index and fingerprint_index to different initial > values (-1 and -2 ?) so that the assert doesn't accidentally pass? I > assume that if _handlers is null then we should have invalid indices > but the first clause of the assert should pass. Yeah, that makes sense. Thanks, Coleen > > David > >> Thanks, >> Coleen >>> >>> -Dmitry >>> >>> >>> On 2011-02-01 21:20, Coleen Phillimore wrote: >>>> >>>> Dmitry, You are absolutely right. We should check _handlers >>>> under the >>>> lock too. It could be created in a separate thread. >>>> >>>> Thanks! >>>> Coleen >>>> >>>> On 2/1/2011 1:14 PM, Dmitry Samersoff wrote: >>>>> Coleen, >>>>> >>>>> assert code is not clean for me: >>>>> >>>>> if (_handlers != NULL){ >>>>> } >>>>> >>>>> _handlers never checked for NULL before e.g. during printing we >>>>> use _handlers->length() etc. >>>>> >>>>> if we are fighting against race I guess we should take a lock before >>>>> null check. >>>>> >>>>> i.e. >>>>> >>>>> MutexLocker mu(SignatureHandlerLibrary_lock); >>>>> if (_handlers != NULL) { >>>>> .... >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2011-02-01 19:48, Coleen Phillimore wrote: >>>>>> Summary: Write method signature handler under lock to prevent >>>>>> race with >>>>>> growable array resizing >>>>>> >>>>>> Also includes a fix to 6704010 which was broken with >>>>>> -XX:-UseFastSignatureHandlers >>>>>> >>>>>> This change was submitted and tested by the customer. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >>> >> From David.Holmes at oracle.com Tue Feb 1 17:22:37 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 02 Feb 2011 11:22:37 +1000 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D48A5B5.3010105@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> <4D476DDA.3000207@oracle.com> <4D489960.7090707@oracle.com> <4D48A5B5.3010105@oracle.com> Message-ID: <4D48B1DD.90802@oracle.com> My apologies to Keith, I was completely missing the fact that the QueueNode class has to hold a copy of the event object due to the limited lifetime of the event objects themselves. Sorry. David David Holmes said the following on 02/02/11 10:30: > Keith McGuigan said the following on 02/02/11 10:26: >> On Feb 1, 2011, at 6:38 PM, David Holmes wrote: >>> The point is to avoid the need to dynamically allocate the >>> QueueNodes. If the elements to be queued are self-linking then you >>> don't need the extra wrapper objects. Take a look at VM_Operations as >>> an example of self-linking objects. >>> >>> It also makes it easy to return a list of events for batch >>> processing, if you chose - ala VM_Operations again. >> >> VM_Operations are allocated on the caller's stack and the caller waits >> and thus his frame exists for the duration of the operation. We can't >> do that in this situation since the caller of enqueue() does not wait >> for the event to be dequeued or posted before continuing, thus the >> caller's frame may be popped and/or reused before the event is picked >> up by the other (service) thread. So the event needs to live outside >> of the caller's stack (the caller of enqueue()). The only reasonable >> place for it to go is into the C-heap. It doesn't matter where the >> 'next' link lives (internal to or external to JvmtiDeferredEvent), we >> still going to need to dynamically allocate C-heap memory to store the >> event. > > You are completely missing the point. My reference to vm_ops was for > their self-linking nature not where they themselves are allocated. > Likewise where the events themselves are allocated is not relevant > either - we are not changing that. What I am simply saying is that by > dynamically allocating QueueNodes on the C-Heap this change introduces a > new fatal error condition in the VM. If the events can self-link, as > vm-operations do, then you don't need QueueNodes, you don't need dynamic > C-Heap allocation and so no new failure mode is introduced. > > David From bob.vandette at oracle.com Wed Feb 2 13:52:22 2011 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Wed, 02 Feb 2011 21:52:22 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110202215228.89ACC4736C@hg.openjdk.java.net> Changeset: b92c45f2bc75 Author: bobv Date: 2011-02-02 11:35 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b92c45f2bc75 7016023: Enable building ARM and PPC from src/closed repository Reviewed-by: dholmes, bdelsart ! make/Makefile + make/closed.make ! make/jprt.properties ! make/linux/Makefile ! make/linux/makefiles/adlc.make + make/linux/makefiles/arm.make ! make/linux/makefiles/buildtree.make + make/linux/makefiles/ppc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make + make/linux/platform_arm + make/linux/platform_ppc ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9cd8a2c2d584 Author: bobv Date: 2011-02-02 11:54 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9cd8a2c2d584 Merge ! src/os/linux/vm/os_linux.cpp From coleen.phillimore at oracle.com Thu Feb 3 08:16:18 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Feb 2011 11:16:18 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought Message-ID: <4D4AD4D2.7070009@oracle.com> Summary: Print an additional message for OOM during stack trace printing ie: Exception in thread "main" . Uncaught exception of type java.lang.OutOfMemoryError. open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 thanks, Coleen From coleen.phillimore at oracle.com Thu Feb 3 08:24:12 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 03 Feb 2011 16:24:12 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7012088: jump to 0 address because of lack of memory ordering in SignatureHandlerLibrary::add Message-ID: <20110203162414.78DA74739A@hg.openjdk.java.net> Changeset: face83fc8882 Author: coleenp Date: 2011-02-02 18:38 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/face83fc8882 7012088: jump to 0 address because of lack of memory ordering in SignatureHandlerLibrary::add Summary: Write method signature handler under lock to prevent race with growable array resizing Reviewed-by: dsamersoff, dholmes ! src/share/vm/interpreter/interpreterRuntime.cpp From karen.kinnear at oracle.com Thu Feb 3 08:43:18 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 3 Feb 2011 11:43:18 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4AD4D2.7070009@oracle.com> References: <4D4AD4D2.7070009@oracle.com> Message-ID: Coleen, Code looks good. Having read the evaluation, I now understand that you can't generate a stack trace if you are out of memory. I'm assuming this additional message may also print for a StackOverflowError - that would be very helpful - I just spent too long trying to track one of those down. thanks, Karen On Feb 3, 2011, at 11:16 AM, Coleen Phillimore wrote: > Summary: Print an additional message for OOM during stack trace > printing > > ie: > > Exception in thread "main" . Uncaught exception of type > java.lang.OutOfMemoryError. > > open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 > > thanks, > Coleen > From coleen.phillimore at oracle.com Thu Feb 3 10:05:10 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Feb 2011 13:05:10 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4AD4D2.7070009@oracle.com> References: <4D4AD4D2.7070009@oracle.com> Message-ID: <4D4AEE56.6060804@oracle.com> I was shamed into not duplicating code, please hit reload... thanks, Coleen On 2/3/2011 11:16 AM, Coleen Phillimore wrote: > Summary: Print an additional message for OOM during stack trace printing > > ie: > > Exception in thread "main" . Uncaught exception of type > java.lang.OutOfMemoryError. > > open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 > > thanks, > Coleen > From paul.hohensee at oracle.com Thu Feb 3 11:14:44 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 03 Feb 2011 14:14:44 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4AEE56.6060804@oracle.com> References: <4D4AD4D2.7070009@oracle.com> <4D4AEE56.6060804@oracle.com> Message-ID: <4D4AFEA4.5090607@oracle.com> Nice. Thanks. :) Paul On 2/3/11 1:05 PM, Coleen Phillimore wrote: > > I was shamed into not duplicating code, please hit reload... > thanks, > Coleen > > On 2/3/2011 11:16 AM, Coleen Phillimore wrote: >> Summary: Print an additional message for OOM during stack trace printing >> >> ie: >> >> Exception in thread "main" . Uncaught exception of type >> java.lang.OutOfMemoryError. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 >> >> thanks, >> Coleen >> > From daniel.daugherty at oracle.com Thu Feb 3 13:31:30 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Feb 2011 14:31:30 -0700 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4AD4D2.7070009@oracle.com> References: <4D4AD4D2.7070009@oracle.com> Message-ID: <4D4B1EB2.5090304@oracle.com> Resending... Got a bounce from the hotspot-runtime-dev at openjdk.java.net alias Thumbs up. You might want to make the bug evalation a little more clear that you're adding additional diagnostic, but a stack trace isn't possible due to the out of memory condition. Dan On 2/3/2011 9:16 AM, Coleen Phillimore wrote: > Summary: Print an additional message for OOM during stack trace printing > > ie: > > Exception in thread "main" . Uncaught exception of type > java.lang.OutOfMemoryError. > > open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 > > thanks, > Coleen > > From coleen.phillimore at oracle.com Thu Feb 3 13:32:51 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Feb 2011 16:32:51 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4B1EB2.5090304@oracle.com> References: <4D4AD4D2.7070009@oracle.com> <4D4B1EB2.5090304@oracle.com> Message-ID: <4D4B1F03.3020202@oracle.com> On 2/3/2011 4:31 PM, Daniel D. Daugherty wrote: > Resending... > Got a bounce from the hotspot-runtime-dev at openjdk.java.net alias > > Thumbs up. > > You might want to make the bug evalation a little more clear that > you're adding additional diagnostic, but a stack trace isn't > possible due to the out of memory condition. OK. thanks Dan! Coleen > > Dan > > On 2/3/2011 9:16 AM, Coleen Phillimore wrote: >> Summary: Print an additional message for OOM during stack trace printing >> >> ie: >> >> Exception in thread "main" . Uncaught exception of type >> java.lang.OutOfMemoryError. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 >> >> thanks, >> Coleen >> >> From David.Holmes at oracle.com Thu Feb 3 17:15:13 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 04 Feb 2011 11:15:13 +1000 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4AD4D2.7070009@oracle.com> References: <4D4AD4D2.7070009@oracle.com> Message-ID: <4D4B5321.4090909@oracle.com> Hi Coleen, I think there are two different cases here that need to be handled differently, or at least the message printed needs to be different. jni_ExceptionDescribe is a JNI method that can be called by a thread to do a stack dump of any currently pending exception. It is the native equivalent of doing: catch (Throwable t) { t.printStackTrace(); } However, the method says nothing about the possibility of a secondary exception occurring during this process - afterall this does not have to be implemented using Java code, so exceptions (or not) are an implementation artifact. Hence dropping the exception is not unreasonable. But this is not uncaught-exception handling so I'm not sure we should be reporting this secondary exception. If we do report it then the message should provide some context: "jni_ExceptionDescribe encountered an internal exception: ..." Then for the actual uncaught-exception handler case: "Secondary exception thrown from the UncaughtExceptionHandler: ..." I think it would be confusing to report the same info in both cases as they are very, very different. I also suspect that we may get complaints about "noise" here because we may find that in some circumstances (such as when applets get destroyed etc) that exceptions during uncaughtException handling are common. David Coleen Phillimore said the following on 02/04/11 02:16: > Summary: Print an additional message for OOM during stack trace printing > > ie: > > Exception in thread "main" . Uncaught exception of type > java.lang.OutOfMemoryError. > > open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 > > thanks, > Coleen > From coleen.phillimore at oracle.com Thu Feb 3 20:17:11 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Feb 2011 23:17:11 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4B5321.4090909@oracle.com> References: <4D4AD4D2.7070009@oracle.com> <4D4B5321.4090909@oracle.com> Message-ID: <4D4B7DC7.5010401@oracle.com> Okay, how about this: Exception in thread "main" - java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler And nothing new from jni_ExceptionDescribe. See webrev: local webrev at http://jruntime.east.sun.com/~coleenp/webrev/6472925_3 local bug link http://monaco.sfbay.sun.com/detail.jsf?cr=6472925 thanks, Coleen On 2/3/2011 8:15 PM, David Holmes wrote: > Hi Coleen, > > I think there are two different cases here that need to be handled > differently, or at least the message printed needs to be different. > > jni_ExceptionDescribe is a JNI method that can be called by a thread > to do a stack dump of any currently pending exception. It is the > native equivalent of doing: > > catch (Throwable t) { > t.printStackTrace(); > } > > However, the method says nothing about the possibility of a secondary > exception occurring during this process - afterall this does not have > to be implemented using Java code, so exceptions (or not) are an > implementation artifact. Hence dropping the exception is not > unreasonable. But this is not uncaught-exception handling so I'm not > sure we should be reporting this secondary exception. If we do report > it then the message should provide some context: > > "jni_ExceptionDescribe encountered an internal exception: ..." > > Then for the actual uncaught-exception handler case: > > "Secondary exception thrown from the UncaughtExceptionHandler: ..." > > I think it would be confusing to report the same info in both cases as > they are very, very different. > > I also suspect that we may get complaints about "noise" here because > we may find that in some circumstances (such as when applets get > destroyed etc) that exceptions during uncaughtException handling are > common. > > David > > Coleen Phillimore said the following on 02/04/11 02:16: >> Summary: Print an additional message for OOM during stack trace printing >> >> ie: >> >> Exception in thread "main" . Uncaught exception of type >> java.lang.OutOfMemoryError. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 >> >> thanks, >> Coleen >> From keith.mcguigan at oracle.com Thu Feb 3 20:28:09 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Fri, 04 Feb 2011 04:28:09 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" Message-ID: <20110204042812.A6F06473D5@hg.openjdk.java.net> Changeset: bf8517f4e4d0 Author: kamg Date: 2011-02-02 14:38 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bf8517f4e4d0 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" Summary: Defer posting events from the compiler thread: use service thread Reviewed-by: coleenp, dholmes, never, dcubed - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp + src/share/vm/runtime/serviceThread.cpp + src/share/vm/runtime/serviceThread.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/macros.hpp From coleen.phillimore at oracle.com Thu Feb 3 20:28:33 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Feb 2011 23:28:33 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought In-Reply-To: <4D4B7DC7.5010401@oracle.com> References: <4D4AD4D2.7070009@oracle.com> <4D4B5321.4090909@oracle.com> <4D4B7DC7.5010401@oracle.com> Message-ID: <4D4B8071.1050806@oracle.com> Posted wrong webrev: open webrev at http://cr.openjdk.java.net/~coleenp/6472925_3/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925_3 On 2/3/2011 11:17 PM, Coleen Phillimore wrote: > > Okay, how about this: > > Exception in thread "main" - java.lang.OutOfMemoryError thrown from > the UncaughtExceptionHandler > > And nothing new from jni_ExceptionDescribe. See webrev: > > local webrev at http://jruntime.east.sun.com/~coleenp/webrev/6472925_3 > local bug link http://monaco.sfbay.sun.com/detail.jsf?cr=6472925 > > thanks, > Coleen > > On 2/3/2011 8:15 PM, David Holmes wrote: >> Hi Coleen, >> >> I think there are two different cases here that need to be handled >> differently, or at least the message printed needs to be different. >> >> jni_ExceptionDescribe is a JNI method that can be called by a thread >> to do a stack dump of any currently pending exception. It is the >> native equivalent of doing: >> >> catch (Throwable t) { >> t.printStackTrace(); >> } >> >> However, the method says nothing about the possibility of a secondary >> exception occurring during this process - afterall this does not have >> to be implemented using Java code, so exceptions (or not) are an >> implementation artifact. Hence dropping the exception is not >> unreasonable. But this is not uncaught-exception handling so I'm not >> sure we should be reporting this secondary exception. If we do report >> it then the message should provide some context: >> >> "jni_ExceptionDescribe encountered an internal exception: ..." >> >> Then for the actual uncaught-exception handler case: >> >> "Secondary exception thrown from the UncaughtExceptionHandler: ..." >> >> I think it would be confusing to report the same info in both cases >> as they are very, very different. >> >> I also suspect that we may get complaints about "noise" here because >> we may find that in some circumstances (such as when applets get >> destroyed etc) that exceptions during uncaughtException handling are >> common. >> >> David >> >> Coleen Phillimore said the following on 02/04/11 02:16: >>> Summary: Print an additional message for OOM during stack trace >>> printing >>> >>> ie: >>> >>> Exception in thread "main" . Uncaught exception of type >>> java.lang.OutOfMemoryError. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 >>> >>> thanks, >>> Coleen >>> > From john.coomes at oracle.com Thu Feb 3 20:59:35 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:59:35 +0000 Subject: hg: jdk7/hotspot-rt/corba: Added tag jdk7-b128 for changeset 9baa8f94a11d Message-ID: <20110204045937.645E9473E6@hg.openjdk.java.net> Changeset: 3ff9acc7cc06 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/3ff9acc7cc06 Added tag jdk7-b128 for changeset 9baa8f94a11d ! .hgtags From john.coomes at oracle.com Thu Feb 3 20:59:44 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:59:44 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b128 for changeset a42c6132c746 Message-ID: <20110204045944.4998F473E7@hg.openjdk.java.net> Changeset: f5b60c5a310f Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/f5b60c5a310f Added tag jdk7-b128 for changeset a42c6132c746 ! .hgtags From john.coomes at oracle.com Thu Feb 3 20:59:50 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:59:50 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b128 for changeset 88d74afc5593 Message-ID: <20110204045950.D1736473E8@hg.openjdk.java.net> Changeset: 0f7b39ad9024 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/0f7b39ad9024 Added tag jdk7-b128 for changeset 88d74afc5593 ! .hgtags From David.Holmes at oracle.com Thu Feb 3 21:05:34 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 04 Feb 2011 15:05:34 +1000 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought] Message-ID: <4D4B891E.5070406@oracle.com> Hi Coleen, Coleen Phillimore said the following on 02/04/11 14:28: > Posted wrong webrev: > > open webrev at http://cr.openjdk.java.net/~coleenp/6472925_3/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925_3 Exactly what will appear on the error stream depends on where the secondary exception occurs and on what the UncaughtExceptionHandler actually does - it may not print at all. So the output here needs to be standalone and not make any assumptions about what may or may not have preceded it, so instead of: jio_fprintf(defaultStream::error_stream(), " - %s thrown from the UncaughtExceptionHandler\n", Klass::cast(pending_exception()->klass())->external_name()); I would suggest: jio_fprintf(defaultStream::error_stream(), "\nException: %s thrown from the UncaughtExceptionHandler in thread %s\n", Klass::cast(pending_exception()->klass())->external_name(), get_thread_name()); The name of the thread is important for debugging. Thanks, David > > On 2/3/2011 11:17 PM, Coleen Phillimore wrote: >> >> Okay, how about this: >> >> Exception in thread "main" - java.lang.OutOfMemoryError thrown from >> the UncaughtExceptionHandler >> >> And nothing new from jni_ExceptionDescribe. See webrev: >> >> local webrev at http://jruntime.east.sun.com/~coleenp/webrev/6472925_3 >> local bug link http://monaco.sfbay.sun.com/detail.jsf?cr=6472925 >> >> thanks, >> Coleen >> >> On 2/3/2011 8:15 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> I think there are two different cases here that need to be handled >>> differently, or at least the message printed needs to be different. >>> >>> jni_ExceptionDescribe is a JNI method that can be called by a thread >>> to do a stack dump of any currently pending exception. It is the >>> native equivalent of doing: >>> >>> catch (Throwable t) { >>> t.printStackTrace(); >>> } >>> >>> However, the method says nothing about the possibility of a secondary >>> exception occurring during this process - afterall this does not have >>> to be implemented using Java code, so exceptions (or not) are an >>> implementation artifact. Hence dropping the exception is not >>> unreasonable. But this is not uncaught-exception handling so I'm not >>> sure we should be reporting this secondary exception. If we do report >>> it then the message should provide some context: >>> >>> "jni_ExceptionDescribe encountered an internal exception: ..." >>> >>> Then for the actual uncaught-exception handler case: >>> >>> "Secondary exception thrown from the UncaughtExceptionHandler: ..." >>> >>> I think it would be confusing to report the same info in both cases >>> as they are very, very different. >>> >>> I also suspect that we may get complaints about "noise" here because >>> we may find that in some circumstances (such as when applets get >>> destroyed etc) that exceptions during uncaughtException handling are >>> common. >>> >>> David >>> >>> Coleen Phillimore said the following on 02/04/11 02:16: >>>> Summary: Print an additional message for OOM during stack trace >>>> printing >>>> >>>> ie: >>>> >>>> Exception in thread "main" . Uncaught exception of type >>>> java.lang.OutOfMemoryError. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 >>>> >>>> thanks, >>>> Coleen >>>> >> > From john.coomes at oracle.com Thu Feb 3 21:02:22 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 05:02:22 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 92 new changesets Message-ID: <20110204051821.CAF77473ED@hg.openjdk.java.net> Changeset: 63f5c7704faa Author: prr Date: 2011-01-12 15:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/63f5c7704faa 6958221: java.awt.Font.getFamily() leads to JVM crash on Linux on JDK7 for "custom" fonts Reviewed-by: igor, jgodinez ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/fontpath.c + test/java/awt/FontClass/X11FontPathCrashTest.java Changeset: 5aae8b3162d0 Author: prr Date: 2011-01-13 10:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5aae8b3162d0 7001056: JDK 7 fails on to build on Solaris 10 update 9 - updated Xrender header files Reviewed-by: igor, jgodinez ! make/sun/xawt/Makefile ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 76b8fa7fd229 Author: prr Date: 2011-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/76b8fa7fd229 7012269: mapfile for headless awt needs getFontPathNative defined Reviewed-by: igor ! make/sun/headless/mapfile-vers Changeset: 9f3f38c150b5 Author: prr Date: 2011-01-13 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9f3f38c150b5 6917884: NPE in sun.font.FcFontConfiguration.getPlatformFontNames Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: 987aeabbfda3 Author: prr Date: 2011-01-14 11:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/987aeabbfda3 6951086: Excessive Local References in sun.font.SunLayoutEngine.nativeLayout Reviewed-by: igor, jgodinez ! src/share/native/sun/font/FontInstanceAdapter.cpp Changeset: 646c3cf1ba37 Author: prr Date: 2011-01-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/646c3cf1ba37 6989370: Windows platform fonts may be incorrectly marked as ineligible for the native rasteriser Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java Changeset: 5cb6bb816a34 Author: prr Date: 2011-01-14 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5cb6bb816a34 6925760: Scaled graphics can cause overlapped LCD mode strings on Windows for pixel size > 48 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java + test/java/awt/FontClass/LCDScale.java Changeset: 8b33567d68b0 Author: jgodinez Date: 2011-01-14 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8b33567d68b0 6939417: ArrayIndexOutOfBoundsException in Win 7 on selected printers Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java ! test/javax/print/DialogMargins.java Changeset: c2fcb5530ba5 Author: prr Date: 2011-01-14 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c2fcb5530ba5 6930980: Disable TrueType hinting for fonts known not to hint well Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0bec5d506120 Author: dlila Date: 2011-01-19 09:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0bec5d506120 4724552: CubicCurve2D.contains(Rectangle2D) returns true when only partially contained. Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: c8a10bfd2fcb Author: dlila Date: 2011-01-19 11:31 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c8a10bfd2fcb 4493128: CubicCurve2D intersects method fails Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: 00cc1c09c6dd Author: prr Date: 2011-01-19 09:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/00cc1c09c6dd 6951501: EUDC character is not displayed on Swing Reviewed-by: igor, jgodinez ! src/windows/classes/sun/awt/Win32FontManager.java ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: e58e9e32399a Author: prr Date: 2011-01-19 17:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e58e9e32399a 6983037: closed/java/awt/font/FontNames/Type1Fonts.java failed due to missed font Reviewed-by: igor ! src/share/classes/sun/font/SunFontManager.java ! src/solaris/classes/sun/awt/X11FontManager.java Changeset: fe1b5c15afab Author: prr Date: 2011-01-19 17:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fe1b5c15afab 7013109: windows application manifest problems 6820955: Update application manifests with new Windows 7 dpiAware section Reviewed-by: ohair, art ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! src/windows/resource/java.manifest Changeset: aa1825b1b69d Author: lana Date: 2011-01-19 19:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/aa1825b1b69d Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 0044e8e16a30 Author: prr Date: 2011-01-20 10:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0044e8e16a30 6980204: closed/java/awt/font/LogicalFonts/MappingTest.java fails Reviewed-by: jgodinez ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: b1c41e0321a2 Author: prr Date: 2011-01-20 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b1c41e0321a2 7013646: remove obsolete fontconfig files for linux and solaris Reviewed-by: igor, jgodinez ! make/sun/awt/Makefile - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: b8f08482aca1 Author: prr Date: 2011-01-21 07:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b8f08482aca1 6892493: potential memory leaks in 2D font code indentified by parfait. Reviewed-by: bae, igor ! src/solaris/native/sun/awt/fontpath.c Changeset: c17e5a95aba7 Author: prr Date: 2011-01-21 08:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c17e5a95aba7 6892138: Windows GDI platform font lookup apis affect start-up for small UI apps Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java + test/java/awt/font/FontNames/LocaleFamilyNames.java Changeset: ade796b84e71 Author: bae Date: 2011-01-24 15:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ade796b84e71 7002766: Java2d: Changes to correct c/c++ language issues for use of parfait Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jmorecfg.h ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 63a2e8e00a7b Author: bae Date: 2011-01-24 15:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/63a2e8e00a7b 6999620: [parfait] potential buffer overruns in 2d and awt Reviewed-by: jgodinez, prr ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 74d020ed7f5b Author: lana Date: 2011-01-24 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/74d020ed7f5b Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: 5d4723944cbd Author: dcherepanov Date: 2011-01-20 14:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5d4723944cbd 7011446: ./windows/classes/sun/awt/windows/WToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: 1bb32dc775c8 Author: dcherepanov Date: 2011-01-20 14:28 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1bb32dc775c8 7011443: ./share/classes/sun/awt/SunToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: 4cd8718d4548 Author: dcherepanov Date: 2011-01-20 14:29 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4cd8718d4548 7011442: AppletClassLoader.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/applet/AppletClassLoader.java Changeset: 4c9a9871830f Author: lana Date: 2011-01-20 10:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4c9a9871830f Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: f6b73a9b3895 Author: lana Date: 2011-01-24 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f6b73a9b3895 Merge Changeset: 63972a313ca4 Author: rupashka Date: 2011-01-11 12:51 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/63972a313ca4 6589952: Swing: dead links in API documentation Reviewed-by: alexp ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java Changeset: 2a966dd275fc Author: rupashka Date: 2011-01-13 20:12 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2a966dd275fc 6990651: Regression: NPE when refreshing applet since 6u22-b01 Reviewed-by: peterz ! src/share/classes/javax/swing/text/html/parser/ParserDelegator.java + test/javax/swing/JLabel/7004134/bug7004134.java + test/javax/swing/text/html/parser/Parser/6990651/bug6990651.java Changeset: 5787add5b679 Author: rupashka Date: 2011-01-17 19:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5787add5b679 6342301: Bad interaction between setting the ui and file filters in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6342301/bug6342301.java Changeset: ca3bafeffd3b Author: rupashka Date: 2011-01-19 17:01 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ca3bafeffd3b 6246816: SwingSet2 should be rewritten Reviewed-by: peterz ! make/common/Demo.gmk ! make/mkdemo/jfc/Makefile + make/mkdemo/jfc/SwingSet3/Makefile Changeset: e93106dc798b Author: lana Date: 2011-01-19 21:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e93106dc798b Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: b45ea2c3bd6d Author: rupashka Date: 2011-01-24 18:04 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b45ea2c3bd6d 6735293: javax.swing.text.NavigationFilter.getNextVisualPositionFrom() not always throws BadLocationException Reviewed-by: peterz ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/NavigationFilter/6735293/bug6735293.java Changeset: 1f3ecbfa0c29 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1f3ecbfa0c29 Merge Changeset: b8663921f5d7 Author: chegar Date: 2011-01-07 13:08 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b8663921f5d7 7000511: PrintStream, PrintWriter, Formatter, Scanner leave files open when exception thrown Reviewed-by: alanb, mduigou ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Scanner.java ! test/ProblemList.txt + test/java/io/PrintStream/FailingConstructors.java + test/java/io/PrintWriter/FailingConstructors.java ! test/java/util/Formatter/Constructors.java + test/java/util/Formatter/FailingConstructors.java + test/java/util/Scanner/FailingConstructors.java Changeset: 5124c2a50539 Author: alanb Date: 2011-01-07 15:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5124c2a50539 6993732: Remove the HPI Reviewed-by: ohair, lancea, chegar, mduigou, mchung, mr ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Modules.gmk ! make/common/Release.gmk ! make/java/Makefile ! make/java/fdlibm/Makefile - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile ! make/tools/reorder/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c Changeset: ddaffd64796c Author: alanb Date: 2011-01-07 15:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ddaffd64796c Merge Changeset: 6bf1c5958c22 Author: chegar Date: 2011-01-07 21:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6bf1c5958c22 7009760: Possible stack corruption in Java_java_net_TwoStacksPlainSocketImpl_socketGetOption Summary: SOCKET_ADDRESS -> SOCKETADDRESS Reviewed-by: alanb ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c Changeset: 3dbc783a8073 Author: smarks Date: 2011-01-07 15:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3dbc783a8073 7008728: diamond conversion of basic security, permissions, authentication Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/acl/AclImpl.java ! src/share/classes/sun/security/acl/GroupImpl.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckOptions.java Changeset: ee5bf287d0c4 Author: alanb Date: 2011-01-10 09:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ee5bf287d0c4 7002957: (fc) FileChannel.transferTo fails to load libsendfile on Solaris 64-bit Reviewed-by: chegar ! make/java/nio/Makefile ! src/solaris/native/sun/nio/ch/FileChannelImpl.c Changeset: f4d755bbdabe Author: lancea Date: 2011-01-10 14:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f4d755bbdabe 6544224: Remove the need of sun.reflect.misc Reviewed-by: alanb ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java Changeset: 2a0ff59928de Author: smarks Date: 2011-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2a0ff59928de 7005608: diamond conversion of JCA and crypto providers Reviewed-by: wetmore ! src/share/classes/java/security/Security.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/rsa/RSACore.java ! src/share/classes/sun/security/rsa/SunRsaSign.java Changeset: befe813e24d2 Author: lancea Date: 2011-01-11 12:36 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/befe813e24d2 7000693: java.sql.Timestamp compareTo() issues using low values Reviewed-by: okutsu ! src/share/classes/java/sql/Timestamp.java Changeset: 6d0217114886 Author: smarks Date: 2011-01-11 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6d0217114886 7011095: revert diamond changes from 6880112 that occur in method args Reviewed-by: darcy, alanb ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/util/logging/Logger.java Changeset: cb3ecb5e4ce5 Author: dl Date: 2011-01-12 14:40 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cb3ecb5e4ce5 7005424: Resync java.util.concurrent classes with Dougs CVS - Jan 2011 Reviewed-by: dholmes, chegar, mduigou ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! test/ProblemList.txt ! test/java/util/WeakHashMap/GCDuringIteration.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/Phaser/Basic.java + test/java/util/concurrent/Phaser/FickleRegister.java + test/java/util/concurrent/Phaser/PhaseOverflow.java + test/java/util/concurrent/Phaser/TieredArriveLoops.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Changeset: a5a22f93e4c5 Author: smarks Date: 2011-01-12 13:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a5a22f93e4c5 7008713: diamond conversion of kerberos5 and security tools Reviewed-by: weijun ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/share/classes/sun/security/krb5/internal/KDCReq.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBCred.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/LastReq.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/tools/KtabCheck.java Changeset: f5c0b3cbee2f Author: kamg Date: 2011-01-12 11:47 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f5c0b3cbee2f 6436034: Instance filter doesn't filter event if it occurs in native method Summary: Use 'GetLocalInstance' JVMTI extension if it exists Reviewed-by: coleenp, dcubed ! src/share/back/debugInit.c ! src/share/back/eventFilter.c ! src/share/instrument/JPLISAgent.c ! src/share/javavm/export/jvmti.h + test/com/sun/jdi/NativeInstanceFilter.java + test/com/sun/jdi/NativeInstanceFilterTarg.java Changeset: 295f6b861c12 Author: kamg Date: 2011-01-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/295f6b861c12 Merge Changeset: 538f913777cf Author: michaelm Date: 2011-01-13 11:01 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/538f913777cf 6896088: URLClassLoader.close() apparently not working for JAR URLs on Windows Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B6896088.java Changeset: 9f265d55c1c4 Author: michaelm Date: 2011-01-13 11:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9f265d55c1c4 Merge Changeset: 694951adefec Author: chegar Date: 2011-01-13 13:24 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/694951adefec 6964547: Impossible to set useV4 in SocksSocketImpl Summary: Add socksProxyVersion property Reviewed-by: alanb, michaelm ! make/sun/net/FILES_java.gmk ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/doc-files/net-properties.html + src/share/classes/sun/net/SocksProxy.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/Socks/SocksProxyVersion.java Changeset: 38729ba6eb4f Author: michaelm Date: 2011-01-12 15:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/38729ba6eb4f 6829919: URLClassLoader.close() doesn't close resource file if getResourceAsStream(...) was called before Reviewed-by: chegar ! src/share/classes/java/net/URLClassLoader.java ! test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/Common.java + test/java/net/URLClassLoader/closetest/GetResourceAsStream.java + test/java/net/URLClassLoader/closetest/build2.sh Changeset: ed390b2e5ca4 Author: michaelm Date: 2011-01-13 11:10 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ed390b2e5ca4 Merge Changeset: 067b5f603fc8 Author: michaelm Date: 2011-01-13 14:41 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/067b5f603fc8 Merge Changeset: 3215b22cd90e Author: michaelm Date: 2011-01-13 16:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3215b22cd90e 7003398: NetworkInterface equals() and hashCode() behaviors depend on permissions granted Reviewed-by: chegar, alanb ! src/share/classes/java/net/NetworkInterface.java + test/java/net/NetworkInterface/Equals.java Changeset: 29f2e311cce7 Author: mduigou Date: 2011-01-13 20:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/29f2e311cce7 6728865: Provide a better heuristics for Collections.disjoint method Reviewed-by: alanb, dholmes, chegar, forax ! src/share/classes/java/util/Collections.java Changeset: 59e352561146 Author: darcy Date: 2011-01-13 22:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/59e352561146 7012279: Project Coin: Clarify AutoCloseable and Throwable javadoc Reviewed-by: jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java Changeset: 983364897f72 Author: chegar Date: 2011-01-14 22:34 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/983364897f72 7010903: impl. of http.maxConnections is different from the description in JavaSE document Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java Changeset: d61d9bf190f5 Author: smarks Date: 2011-01-14 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d61d9bf190f5 7012003: diamond conversion for ssl Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java Changeset: 507627325c81 Author: sundar Date: 2011-01-17 13:29 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/507627325c81 6508943: small typo in the documentation 6759414: javascript engine can not write to StringWriter 6869617: RhinoScriptEngine bug : ScriptException cause not set (with fix) 7012701: Add a test to check that Rhino's RegExp parser accepts unescaped '[' Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java + test/javax/script/CauseExceptionTest.java + test/javax/script/StringWriterPrintTest.java + test/javax/script/UnescapedBracketRegExTest.java Changeset: 9596a600758c Author: lana Date: 2011-01-19 19:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9596a600758c Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: e64b1f11cd0b Author: chegar Date: 2011-01-20 15:23 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e64b1f11cd0b 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc Summary: Remove from ProblemList, failure resolved by 7009231 Reviewed-by: alanb ! test/ProblemList.txt Changeset: cc195c981ae2 Author: mchung Date: 2011-01-20 22:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cc195c981ae2 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/ProblemList.txt Changeset: 2a8d1a0a2418 Author: chegar Date: 2011-01-21 17:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2a8d1a0a2418 7012768: InetAddress lookupTable leaks/deadlocks when using unsupported name service spi Reviewed-by: alanb, michaelm ! src/share/classes/java/net/InetAddress.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/chaining/Providers.java + test/sun/net/InetAddress/nameservice/chaining/Simple1NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/Simple2NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/SimpleNameService.java + test/sun/net/InetAddress/nameservice/deadlock/Hang.java + test/sun/net/InetAddress/nameservice/deadlock/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameService.java + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/simple/CacheTest.java + test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java + test/sun/net/InetAddress/nameservice/simple/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/simple/SimpleNameService.java + test/sun/net/InetAddress/nameservice/simple/SimpleNameServiceDescriptor.java Changeset: 6a7b8406a1b9 Author: chegar Date: 2011-01-21 17:04 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6a7b8406a1b9 Merge Changeset: f26d1a7fe4d2 Author: mchung Date: 2011-01-21 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f26d1a7fe4d2 6912013: Remove the temporary launcher fix to add modules in the bootclasspath Reviewed-by: ksrini ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 9c18818e7a5f Author: mchung Date: 2011-01-21 09:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9c18818e7a5f Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 2381e810330b Author: zgu Date: 2011-01-20 10:45 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2381e810330b 6983248: net/net001 and net/net003 fail on WinXP with JDK7-B108 Summary: Using closesocket to close socket handler to avoid invalid C runtime parameter exception. Reviewed-by: alanb, phh, dcubed, dsamersoff, coleenp, acorn ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d03e47de3a89 Author: zgu Date: 2011-01-21 11:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d03e47de3a89 Merge Changeset: c73c178159d8 Author: phh Date: 2011-01-20 19:34 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c73c178159d8 6173675: M&M: approximate memory allocation rate/amount per thread Summary: Subclass com.sun.management.ThreadMXBean from java.lang.management.ThreadMXBean, add getAllocatedBytes() and friends to c.s.m.ThreadMXBean and have sun.management.ThreadImpl implement c.s.m.ThreadMXBean rather than j.l.m.ThreadMXBean. Reviewed-by: mchung, alanb, dholmes, emcmanus ! make/java/management/mapfile-vers + src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java + test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 64ef2f52d781 Author: phh Date: 2011-01-21 07:29 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/64ef2f52d781 7013682: two test checking cpuTime filed java/lang/management/ThreadMXBean Summary: Typo in 6173675 fix dropped getThreadCpuTime(long) result on the floor. Reviewed-by: mchung, dholmes ! src/share/classes/sun/management/ThreadImpl.java Changeset: cd13b2114f2e Author: phh Date: 2011-01-22 08:42 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cd13b2114f2e Merge ! src/share/classes/sun/management/ThreadImpl.java Changeset: d1365fdfb3ea Author: phh Date: 2011-01-22 08:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d1365fdfb3ea Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4cc447291326 Author: sherman Date: 2011-01-24 11:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4cc447291326 7006576: (zipfs) Path.exists() always returns false on dirs when zip/JAR file built without dirs 7009092: (zipfs) ZipPath.isSameFile() should always return true if this Path and the given Path are equal. 7009085: (zipfs) ZipPath.normalize("/./.") returns null. 7009102: (zipfs) ZipPath.toRealPath() should always return absolute path. Summary: zip filesystem provider update Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 1f977c82b733 Author: lana Date: 2011-01-24 13:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1f977c82b733 Merge ! make/common/Defs-windows.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 47cfd89c3227 Author: lana Date: 2011-01-28 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/47cfd89c3227 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 006c683ead1a Author: ohair Date: 2011-01-05 14:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/006c683ead1a 6975326: Problem in install/make/rebase/Makefile, grep on empty pattern 6413588: Add 'ldd -r' and 'dump -Lv' checks to all .so files delivered in the JDK 7000995: Add check in makefiles to verify that msvcp100.dll is NOT used Reviewed-by: mduigou ! make/com/sun/java/pack/Makefile ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile Changeset: 9576644931b2 Author: ohair Date: 2011-01-07 21:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9576644931b2 6980024: Rebranding jre7/jdk7 License, Copyright, Readme 6912291: Third party license agreement should be present in all bundles Reviewed-by: katleman ! make/common/Modules.gmk ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: 8c3c6ac6fcdb Author: ohair Date: 2011-01-10 09:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8c3c6ac6fcdb Merge Changeset: 658559ca4526 Author: ohair Date: 2011-01-10 17:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/658559ca4526 7011382: Fix use of VS100COMNTOOLS when installed in non-default or non-space path Reviewed-by: prr ! make/common/shared/Defs-windows.gmk Changeset: fd6319676bd3 Author: ohair Date: 2011-01-10 17:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fd6319676bd3 Merge Changeset: 713d20f796c0 Author: ohair Date: 2011-01-10 18:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/713d20f796c0 6989472: Provide simple jdk identification information in the install image Reviewed-by: alanb ! make/common/Release.gmk ! make/common/shared/Defs-versions.gmk Changeset: 523386cfb731 Author: ohair Date: 2011-01-10 22:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/523386cfb731 Merge Changeset: 83cef4633684 Author: ohair Date: 2011-01-13 17:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/83cef4633684 Merge Changeset: 4241588a12c3 Author: ohair Date: 2011-01-13 13:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4241588a12c3 7008047: remove sanity check of msival tool from JDK tree Reviewed-by: billyh ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: 81e66ce6f501 Author: ohair Date: 2011-01-13 23:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/81e66ce6f501 Merge Changeset: 0c29bbd10e19 Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0c29bbd10e19 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! make/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/jdk_generic_profile.sh ! src/share/demo/jvmti/index.html Changeset: 329f49ab5c4c Author: ohair Date: 2011-01-16 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/329f49ab5c4c Merge Changeset: 688f415db098 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/688f415db098 Merge Changeset: aecb8f0eb83b Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/aecb8f0eb83b Merge Changeset: f08682e23279 Author: ohair Date: 2011-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f08682e23279 Merge ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/Release.gmk Changeset: 07c68a15ec79 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/07c68a15ec79 Added tag jdk7-b128 for changeset f08682e23279 ! .hgtags From john.coomes at oracle.com Thu Feb 3 20:59:28 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:59:28 +0000 Subject: hg: jdk7/hotspot-rt: 11 new changesets Message-ID: <20110204045928.70129473E4@hg.openjdk.java.net> Changeset: f722c246ce71 Author: mchung Date: 2011-01-20 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/f722c246ce71 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/Makefile Changeset: 65e6601596e2 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/65e6601596e2 Merge Changeset: 61f181d43d9a Author: lana Date: 2011-01-28 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/61f181d43d9a Merge Changeset: 6db0e6f221bd Author: ohair Date: 2011-01-05 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/6db0e6f221bd 7009969: Remove SKIP_OPENJDK_BUILD from top Makefile Reviewed-by: robilad ! Makefile ! make/Defs-internal.gmk Changeset: 49c463695059 Author: ohair Date: 2011-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/49c463695059 Merge Changeset: 6d9bbcc0a8cb Author: ohair Date: 2011-01-13 17:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/6d9bbcc0a8cb Merge Changeset: 24900a58ab9f Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/24900a58ab9f 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! Makefile ! README-builds.html Changeset: 3a9f19cbf7f1 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/3a9f19cbf7f1 Merge Changeset: a7a4f6db294d Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/a7a4f6db294d Merge Changeset: 57d702105b23 Author: ohair Date: 2011-02-02 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/57d702105b23 Merge Changeset: 904d7c7c44d9 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/904d7c7c44d9 Added tag jdk7-b128 for changeset 57d702105b23 ! .hgtags From coleen.phillimore at oracle.com Thu Feb 3 22:29:39 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 04 Feb 2011 06:29:39 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110204062944.BAA12473F0@hg.openjdk.java.net> Changeset: d28def44457d Author: coleenp Date: 2011-02-03 21:30 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d28def44457d 7017009: Secondary out of c-heap memory error reporting out of memory Summary: Use os::malloc() to allocate buffer to read elf symbols and check for null Reviewed-by: zgu, phh, dsamersoff, dholmes, dcubed ! src/share/vm/utilities/elfSymbolTable.cpp Changeset: 5e139f767ddb Author: coleenp Date: 2011-02-03 20:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5e139f767ddb Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java From coleen.phillimore at oracle.com Fri Feb 4 05:08:30 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 04 Feb 2011 08:08:30 -0500 Subject: Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought] In-Reply-To: <4D4B891E.5070406@oracle.com> References: <4D4B891E.5070406@oracle.com> Message-ID: <4D4BFA4E.30901@oracle.com> Thank you for the suggestion for wording. I'll change it to that. Coleen On 2/4/2011 12:05 AM, David Holmes wrote: > Hi Coleen, > > Coleen Phillimore said the following on 02/04/11 14:28: >> Posted wrong webrev: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6472925_3/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925_3 > > Exactly what will appear on the error stream depends on where the > secondary exception occurs and on what the UncaughtExceptionHandler > actually does - it may not print at all. So the output here needs to be > standalone and not make any assumptions about what may or may not have > preceded it, so instead of: > > jio_fprintf(defaultStream::error_stream(), > " - %s thrown from the UncaughtExceptionHandler\n", > Klass::cast(pending_exception()->klass())->external_name()); > > I would suggest: > > jio_fprintf(defaultStream::error_stream(), > "\nException: %s thrown from the UncaughtExceptionHandler in > thread %s\n", > Klass::cast(pending_exception()->klass())->external_name(), > get_thread_name()); > > The name of the thread is important for debugging. > > Thanks, > David > >> >> On 2/3/2011 11:17 PM, Coleen Phillimore wrote: >>> >>> Okay, how about this: >>> >>> Exception in thread "main" - java.lang.OutOfMemoryError thrown from >>> the UncaughtExceptionHandler >>> >>> And nothing new from jni_ExceptionDescribe. See webrev: >>> >>> local webrev at http://jruntime.east.sun.com/~coleenp/webrev/6472925_3 >>> local bug link http://monaco.sfbay.sun.com/detail.jsf?cr=6472925 >>> >>> thanks, >>> Coleen >>> >>> On 2/3/2011 8:15 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> I think there are two different cases here that need to be handled >>>> differently, or at least the message printed needs to be different. >>>> >>>> jni_ExceptionDescribe is a JNI method that can be called by a >>>> thread to do a stack dump of any currently pending exception. It is >>>> the native equivalent of doing: >>>> >>>> catch (Throwable t) { >>>> t.printStackTrace(); >>>> } >>>> >>>> However, the method says nothing about the possibility of a >>>> secondary exception occurring during this process - afterall this >>>> does not have to be implemented using Java code, so exceptions (or >>>> not) are an implementation artifact. Hence dropping the exception >>>> is not unreasonable. But this is not uncaught-exception handling so >>>> I'm not sure we should be reporting this secondary exception. If we >>>> do report it then the message should provide some context: >>>> >>>> "jni_ExceptionDescribe encountered an internal exception: ..." >>>> >>>> Then for the actual uncaught-exception handler case: >>>> >>>> "Secondary exception thrown from the UncaughtExceptionHandler: ..." >>>> >>>> I think it would be confusing to report the same info in both cases >>>> as they are very, very different. >>>> >>>> I also suspect that we may get complaints about "noise" here >>>> because we may find that in some circumstances (such as when >>>> applets get destroyed etc) that exceptions during uncaughtException >>>> handling are common. >>>> >>>> David >>>> >>>> Coleen Phillimore said the following on 02/04/11 02:16: >>>>> Summary: Print an additional message for OOM during stack trace >>>>> printing >>>>> >>>>> ie: >>>>> >>>>> Exception in thread "main" . Uncaught exception of type >>>>> java.lang.OutOfMemoryError. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6472925/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925 >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>> >> > From mandy.chung at oracle.com Mon Feb 7 12:17:29 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Feb 2011 12:17:29 -0800 Subject: Request for review: 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook Message-ID: <4D505359.5020303@oracle.com> This change will remove the setting of the sun.jkernel.DownloadManager as a boot classloader hook fixed in 6888880 as jkernel will not be supported in JDK7: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b966d9946a3 Webrev at: http://cr.openjdk.java.net/~mchung/7017673/webrev.00/ Thanks Mandy From daniel.daugherty at oracle.com Mon Feb 7 12:49:37 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 07 Feb 2011 13:49:37 -0700 Subject: Request for review: 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook In-Reply-To: <4D505359.5020303@oracle.com> References: <4D505359.5020303@oracle.com> Message-ID: <4D505AE1.1040406@oracle.com> Thumbs up! Looks like a perfect anti-delta of 6888880. Dan On 2/7/2011 1:17 PM, Mandy Chung wrote: > This change will remove the setting of the > sun.jkernel.DownloadManager as a boot classloader hook fixed in > 6888880 as jkernel will not be supported in JDK7: > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b966d9946a3 > > Webrev at: > http://cr.openjdk.java.net/~mchung/7017673/webrev.00/ > > Thanks > Mandy From coleen.phillimore at oracle.com Mon Feb 7 12:50:07 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 07 Feb 2011 15:50:07 -0500 Subject: Request for review: 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook In-Reply-To: <4D505359.5020303@oracle.com> References: <4D505359.5020303@oracle.com> Message-ID: <4D505AFF.3020601@oracle.com> On 2/7/2011 3:17 PM, Mandy Chung wrote: > This change will remove the setting of the > sun.jkernel.DownloadManager as a boot classloader hook fixed in > 6888880 as jkernel will not be supported in JDK7: > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b966d9946a3 > > Webrev at: > http://cr.openjdk.java.net/~mchung/7017673/webrev.00/ > > Thanks > Mandy I was hoping this change would take out the entire DownloadManager definition and call in systemDictionary.cpp. Coleen From mandy.chung at oracle.com Mon Feb 7 12:58:31 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Feb 2011 12:58:31 -0800 Subject: Request for review: 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook In-Reply-To: <4D505AFF.3020601@oracle.com> References: <4D505359.5020303@oracle.com> <4D505AFF.3020601@oracle.com> Message-ID: <4D505CF7.9050006@oracle.com> On 02/07/11 12:50, Coleen Phillimore wrote: > On 2/7/2011 3:17 PM, Mandy Chung wrote: >> This change will remove the setting of the >> sun.jkernel.DownloadManager as a boot classloader hook fixed in >> 6888880 as jkernel will not be supported in JDK7: >> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b966d9946a3 >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/7017673/webrev.00/ >> >> Thanks >> Mandy > > I was hoping this change would take out the entire DownloadManager > definition and call in systemDictionary.cpp. > I don't think we can do so since hotspot VM has to continue supporting jkernel for jdk 6 update, right? Mandy > Coleen From coleen.phillimore at oracle.com Mon Feb 7 13:46:24 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 07 Feb 2011 16:46:24 -0500 Subject: Request for review: 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook In-Reply-To: <4D505CF7.9050006@oracle.com> References: <4D505359.5020303@oracle.com> <4D505AFF.3020601@oracle.com> <4D505CF7.9050006@oracle.com> Message-ID: <4D506830.8040906@oracle.com> On 2/7/2011 3:58 PM, Mandy Chung wrote: > On 02/07/11 12:50, Coleen Phillimore wrote: >> On 2/7/2011 3:17 PM, Mandy Chung wrote: >>> This change will remove the setting of the >>> sun.jkernel.DownloadManager as a boot classloader hook fixed in >>> 6888880 as jkernel will not be supported in JDK7: >>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b966d9946a3 >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/7017673/webrev.00/ >>> >>> Thanks >>> Mandy >> >> I was hoping this change would take out the entire DownloadManager >> definition and call in systemDictionary.cpp. >> > > I don't think we can do so since hotspot VM has to continue supporting > jkernel for jdk 6 update, right? I don't know. I'm pretty sure the 6 updates aren't supporting jkernel so it would be okay to remove it (cc'ed Bill who is removing it from deployment). Coleen > > Mandy > >> Coleen > From Alan.Bateman at oracle.com Tue Feb 8 06:36:32 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Feb 2011 14:36:32 +0000 Subject: Request for review: 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook In-Reply-To: <4D505359.5020303@oracle.com> References: <4D505359.5020303@oracle.com> Message-ID: <4D5154F0.5020401@oracle.com> Mandy Chung wrote: > This change will remove the setting of the > sun.jkernel.DownloadManager as a boot classloader hook fixed in > 6888880 as jkernel will not be supported in JDK7: > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b966d9946a3 > > Webrev at: > http://cr.openjdk.java.net/~mchung/7017673/webrev.00/ > > Thanks > Mandy This looks fine to me (I'm assuming the support for the download manager can't be removed because of 6). -Alan From keith.mcguigan at oracle.com Tue Feb 8 16:48:19 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 09 Feb 2011 00:48:19 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7003401: Implement VM error-reporting functionality on erroneous termination Message-ID: <20110209004821.C20924751E@hg.openjdk.java.net> Changeset: d8a72fbc4be7 Author: kamg Date: 2011-02-08 17:20 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d8a72fbc4be7 7003401: Implement VM error-reporting functionality on erroneous termination Summary: Add support for distribution-specific error reporting Reviewed-by: coleenp, phh, jcoomes, ohair ! make/Makefile + make/altsrc.make - make/closed.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp + src/share/vm/utilities/errorReporter.cpp + src/share/vm/utilities/errorReporter.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp From coleen.phillimore at oracle.com Tue Feb 8 18:59:55 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 09 Feb 2011 02:59:55 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110209025958.BA91C47525@hg.openjdk.java.net> Changeset: fb539912d338 Author: coleenp Date: 2011-02-07 14:36 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fb539912d338 6472925: OutOfMemoryError fails to generate stack trace as it now ought Summary: Print an additional message for OOM during stack trace printing Reviewed-by: dholmes, phh, acorn, kamg, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 5fb3ee258e76 Author: coleenp Date: 2011-02-08 19:50 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5fb3ee258e76 Merge - make/closed.make From mandy.chung at oracle.com Wed Feb 9 00:48:39 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Feb 2011 08:48:39 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110209084845.E3EFE47535@hg.openjdk.java.net> Changeset: f36c9fe788b8 Author: mchung Date: 2011-02-08 09:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f36c9fe788b8 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook Reviewed-by: alanb, dcubed, coleenp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5197f3d713a1 Author: mchung Date: 2011-02-08 22:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5197f3d713a1 Merge - make/closed.make ! src/share/vm/runtime/thread.cpp From christian.tornqvist at oracle.com Wed Feb 9 04:21:26 2011 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 09 Feb 2011 12:21:26 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7014918: Improve core/minidump handling in Hotspot Message-ID: <20110209122128.A41324753F@hg.openjdk.java.net> Changeset: 63d374c54045 Author: ctornqvi Date: 2011-02-09 11:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/63d374c54045 7014918: Improve core/minidump handling in Hotspot Summary: Added Minidump support on Windows, enabled large page core dumps when coredump_filter is present and writing out path/rlimit for core dumps. Reviewed-by: poonam, dsamersoff, sla, coleenp ! src/os/linux/vm/os_linux.cpp + src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp From william.harnois at oracle.com Mon Feb 7 15:07:17 2011 From: william.harnois at oracle.com (William Harnois) Date: Mon, 07 Feb 2011 18:07:17 -0500 Subject: Request for review: 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook In-Reply-To: <4D506830.8040906@oracle.com> References: <4D505359.5020303@oracle.com> <4D505AFF.3020601@oracle.com> <4D505CF7.9050006@oracle.com> <4D506830.8040906@oracle.com> Message-ID: <4D507B25.6060000@oracle.com> On 2/7/11 4:46 PM, Coleen Phillimore wrote: > On 2/7/2011 3:58 PM, Mandy Chung wrote: >> On 02/07/11 12:50, Coleen Phillimore wrote: >>> On 2/7/2011 3:17 PM, Mandy Chung wrote: >>>> This change will remove the setting of the >>>> sun.jkernel.DownloadManager as a boot classloader hook fixed in >>>> 6888880 as jkernel will not be supported in JDK7: >>>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b966d9946a3 >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/7017673/webrev.00/ >>>> >>>> Thanks >>>> Mandy >>> >>> I was hoping this change would take out the entire DownloadManager >>> definition and call in systemDictionary.cpp. >>> >> >> I don't think we can do so since hotspot VM has to continue >> supporting jkernel for jdk 6 update, right? > > I don't know. I'm pretty sure the 6 updates aren't supporting jkernel > so it would be okay to remove it (cc'ed Bill who is removing it from > deployment). We didn't have any plans of dropping kernel from JDK6. We were only going to drop from JDK7 and later. -Bill > > Coleen >> >> Mandy >> >>> Coleen >> > From christian.tornqvist at oracle.com Thu Feb 10 06:23:18 2011 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Thu, 10 Feb 2011 14:23:18 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003 Message-ID: <20110210142320.3D304475A9@hg.openjdk.java.net> Changeset: b83527d0482d Author: ctornqvi Date: 2011-02-10 12:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b83527d0482d 7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003 Summary: Looking at API_VERSION_NUMBER define to see what version of dbghelp.h/imagehlp.h is included to determine what MINIDUMP_TYPEs are defined in the header file Reviewed-by: acorn, brutisso, sla ! src/os/windows/vm/os_windows.cpp From john.coomes at oracle.com Thu Feb 10 21:10:06 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 05:10:06 +0000 Subject: hg: jdk7/hotspot-rt: 4 new changesets Message-ID: <20110211051006.3EE7847646@hg.openjdk.java.net> Changeset: ce02c0d73d6a Author: ohair Date: 2011-02-03 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/ce02c0d73d6a 7014634: By default, only build the product bits with a closed jdk build (like openjdk does) Reviewed-by: katleman, cl, igor, trims ! make/Defs-internal.gmk Changeset: e2a214ec8ebc Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/e2a214ec8ebc Merge Changeset: a6b015b59fbc Author: ohair Date: 2011-02-08 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/a6b015b59fbc 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! README-builds.html Changeset: cc58c11af154 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/cc58c11af154 Added tag jdk7-b129 for changeset a6b015b59fbc ! .hgtags From john.coomes at oracle.com Thu Feb 10 21:10:16 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 05:10:16 +0000 Subject: hg: jdk7/hotspot-rt/corba: 3 new changesets Message-ID: <20110211051020.4BABB47647@hg.openjdk.java.net> Changeset: 6a3903e5b6cc Author: ohair Date: 2011-02-03 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/6a3903e5b6cc 6944304: Potential rebranding issues in the openjdk7/corba sources Reviewed-by: alanb, mchung, darcy ! src/share/classes/com/sun/corba/se/spi/logging/data/Activation.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/IOR.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Interceptors.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Naming.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/OMG.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/POA.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Util.mc Changeset: 66fa0fcc7792 Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/66fa0fcc7792 Merge Changeset: 4cdf9b86f550 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/4cdf9b86f550 Added tag jdk7-b129 for changeset 66fa0fcc7792 ! .hgtags From john.coomes at oracle.com Thu Feb 10 21:10:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 05:10:27 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b129 for changeset f5b60c5a310f Message-ID: <20110211051027.5BEE747648@hg.openjdk.java.net> Changeset: ab107c1bc4b9 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/ab107c1bc4b9 Added tag jdk7-b129 for changeset f5b60c5a310f ! .hgtags From john.coomes at oracle.com Thu Feb 10 21:10:34 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 05:10:34 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b129 for changeset 0f7b39ad9024 Message-ID: <20110211051034.16B3647649@hg.openjdk.java.net> Changeset: ba1fac1c2083 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/ba1fac1c2083 Added tag jdk7-b129 for changeset 0f7b39ad9024 ! .hgtags From john.coomes at oracle.com Thu Feb 10 21:10:45 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 05:10:45 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 5 new changesets Message-ID: <20110211051216.9E6554764A@hg.openjdk.java.net> Changeset: 001dcfd0be4b Author: ohair Date: 2011-02-08 16:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/001dcfd0be4b 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 1f056ddda771 Author: ohair Date: 2011-01-28 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1f056ddda771 7014301: Change make 3.81 sanity check to a fatal, 3.81 is needed now Reviewed-by: alanb ! make/common/shared/Sanity.gmk Changeset: 3f77dae85c85 Author: ohair Date: 2011-02-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3f77dae85c85 Merge Changeset: 14cd5d54a8d0 Author: ohair Date: 2011-02-08 20:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/14cd5d54a8d0 Merge ! make/common/shared/Sanity.gmk Changeset: 326aac19a89f Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/326aac19a89f Added tag jdk7-b129 for changeset 14cd5d54a8d0 ! .hgtags From john.coomes at oracle.com Thu Feb 10 21:12:33 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 05:12:33 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 22 new changesets Message-ID: <20110211051318.CFC0A4764B@hg.openjdk.java.net> Changeset: d17f37522154 Author: jjg Date: 2011-01-10 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d17f37522154 6992999: fully remove JSR 308 from langtools Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c537f4298fb Author: jjg Date: 2011-01-10 15:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7c537f4298fb 6396503: javac should not require assertions enabled Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/Assert.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/javax/tools/ToolProvider.java Changeset: 17b271281525 Author: jjg Date: 2011-01-11 08:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/17b271281525 6993305: starting position of a method without modifiers and with type parameters is incorrect Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/T6993305.java Changeset: d33d8c381aa1 Author: jjg Date: 2011-01-13 11:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d33d8c381aa1 6430241: Hard to disable symbol file feature through API Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java + test/tools/javac/api/T6430241.java Changeset: a466f00c5cd2 Author: bpatel Date: 2011-01-13 21:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a466f00c5cd2 7010528: javadoc performance regression Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java Changeset: 2d5aff89aaa3 Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2d5aff89aaa3 6992698: JSR 292: remove support for transient syntax in polymorphic signature calls Summary: special syntax to denote indy return type through type parameters should be removed (and cast shall be used instead) Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java Changeset: c8d312dd17bc Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/c8d312dd17bc 7007432: Test generic types well-formedness Summary: add a new kind of check (well-formedness of generic type w.r.t. declared bounds) in the type-harness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/types/GenericTypeWellFormednessTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 712be35e40b5 Author: mcimadamore Date: 2011-01-14 09:46 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/712be35e40b5 6949040: java.dyn package must be compiled with -target 7 or better Summary: issue error (rather than warning) when @PolymorphicSignature is found and target < 7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c7c1787fbbe Author: jjg Date: 2011-01-14 11:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7c7c1787fbbe 6419926: JSR 199: FileObject.toUri() generates URI without schema (Solaris) Reviewed-by: mcimadamore + test/tools/javac/api/T6419926.java Changeset: 0a509c765657 Author: jjg Date: 2011-01-14 11:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/0a509c765657 6571165: Minor doc bugs in JavaCompiler.java Reviewed-by: mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 19f9b6548c70 Author: ksrini Date: 2011-01-14 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/19f9b6548c70 7011272: langtools build.xml should provide a patch target Reviewed-by: jonathan, jjh ! make/build.xml Changeset: 5cf6c432ef2f Author: ksrini Date: 2011-01-18 08:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5cf6c432ef2f 6982999: tools must support -target 7 bytecodes Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/classfile/Attribute.java + src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java Changeset: b6f95173e769 Author: lana Date: 2011-01-19 19:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/b6f95173e769 Merge Changeset: 19c900c703c6 Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/19c900c703c6 6943278: spurious error message for inference and type-variable with erroneous bound Summary: type-inference should ignore erroneous bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6943278/T6943278.java + test/tools/javac/generics/inference/6943278/T6943278.out Changeset: ce6175cfe11e Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ce6175cfe11e 6968793: issues with diagnostics Summary: several diagnostic improvements Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6330920/T6330920.out ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/6863465/T6863465c.out ! test/tools/javac/6863465/T6863465d.out ! test/tools/javac/T6247324.out ! test/tools/javac/TryWithResources/ResourceOutsideTry.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantResolve.java ! test/tools/javac/diags/examples/CantResolveArgsParams.java ! test/tools/javac/diags/examples/CantResolveLocation.java ! test/tools/javac/diags/examples/CantResolveLocationArgs.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParams.java - test/tools/javac/diags/examples/EnumConstRequired.java ! test/tools/javac/diags/examples/ForeachNotApplicable.java ! test/tools/javac/diags/examples/KindnameClass.java ! test/tools/javac/diags/examples/KindnameMethod.java ! test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/Location.java + test/tools/javac/diags/examples/Location1.java ! test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/OperatorCantBeApplied1.java ! test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java ! test/tools/javac/failover/FailOver01.out ! test/tools/javac/failover/FailOver02.out ! test/tools/javac/failover/FailOver04.out ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg11.out ! test/tools/javac/generics/inference/6943278/T6943278.out ! test/tools/javac/generics/typevars/5060485/Compatibility.out ! test/tools/javac/generics/typevars/5060485/Compatibility02.out + test/tools/javac/generics/typevars/6968793/T6968793.java + test/tools/javac/generics/typevars/6968793/T6968793.out ! test/tools/javac/policy/test1/byfile.ABD.out ! test/tools/javac/policy/test1/bytodo.ABD.out ! test/tools/javac/policy/test1/simple.ABD.out Changeset: 02e6e7dd1a64 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/02e6e7dd1a64 6510286: Wording of javac error for inner classes Summary: 'inner classes cannot have static declarations' message needs to be reworked Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/InnerNamedConstant_2.out Changeset: 812c6251ea78 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/812c6251ea78 6569633: Varargs: parser error when varargs element type is an array Summary: explicit error message when old-style array syntax is mixed with varargs Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/VarargsAndOldArraySyntax.java + test/tools/javac/varargs/6569633/T6569633.java + test/tools/javac/varargs/6569633/T6569633.out Changeset: 57e3b9bc7fb8 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/57e3b9bc7fb8 7013865: varargs: javac crashes during overload resolution with generic varargs Summary: fixed regression with varargs overload resolution that leads javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/varargs/T7013865.java Changeset: 2314f2b07ae7 Author: lana Date: 2011-01-24 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2314f2b07ae7 Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: d7225b476a5d Author: lana Date: 2011-01-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d7225b476a5d Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: 1383d1ee8b5d Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/1383d1ee8b5d Added tag jdk7-b128 for changeset d7225b476a5d ! .hgtags Changeset: 03e7fc380090 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/03e7fc380090 Added tag jdk7-b129 for changeset 1383d1ee8b5d ! .hgtags From daniel.daugherty at oracle.com Fri Feb 11 18:31:17 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Feb 2011 19:31:17 -0700 Subject: code review for jps fix (6637230) Message-ID: <4D55F0F5.5000804@oracle.com> Greetings, I have a fix for the following jps bug: 6637230: 2/3 jps doesn't work for application waiting for direct attach Summary: Properly handle exceptions thrown when querying a monitored VM. Reviewed-by: Here is the URL for the webrev: http://cr.openjdk.java.net/~dcubed/6637230-webrev/0/ Thanks, in advance, for any reviews. Dan From staffan.larsen at oracle.com Fri Feb 11 22:17:22 2011 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Sat, 12 Feb 2011 06:17:22 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7017824: Add support for creating 64-bit Visual Studio projects Message-ID: <20110212061727.F08EE476AB@hg.openjdk.java.net> Changeset: 15d6977f04b0 Author: sla Date: 2011-02-10 13:03 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/15d6977f04b0 7017824: Add support for creating 64-bit Visual Studio projects Summary: Updated create.bat and ProjectCreator Reviewed-by: brutisso, stefank, ohair ! make/windows/create.bat ! make/windows/makefiles/compile.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 ! make/windows/projectfiles/common/Makefile ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/DirectoryTree.java ! src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC6.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/vm/adlc/adlc.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp From Dmitry.Samersoff at oracle.com Sat Feb 12 01:38:53 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 12 Feb 2011 12:38:53 +0300 Subject: code review for jps fix (6637230) In-Reply-To: <4D55F0F5.5000804@oracle.com> References: <4D55F0F5.5000804@oracle.com> Message-ID: <4D56552D.3080404@oracle.com> Dan, Looks OK for me. + + // leading blank not needed here because of the + // next append() call + errorString = "-- main class information unavailable"; + output.append(" "); + output.append(MonitoredVmUtil.mainClass(vm, + arguments.showLongPaths())); May be it could be done as (below) to keep errorString uniform: errorString = " -- main class information String s = MonitoredVmUtil.mainClass(vm, arguments.showLongPaths()); output.append(" ").append(s); -Dmitry On 2011-02-12 05:31, Daniel D. Daugherty wrote: > Greetings, > > I have a fix for the following jps bug: > > 6637230: 2/3 jps doesn't work for application waiting for direct attach > Summary: Properly handle exceptions thrown when querying a monitored VM. > Reviewed-by: > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/6637230-webrev/0/ > > Thanks, in advance, for any reviews. > > Dan > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From coleen.phillimore at oracle.com Sat Feb 12 09:59:10 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 12 Feb 2011 17:59:10 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7019157: errorHandler doesn't compile with super old gcc without precompiled headers Message-ID: <20110212175912.EEC60476C7@hg.openjdk.java.net> Changeset: 7aa1f99ca301 Author: coleenp Date: 2011-02-12 10:28 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7aa1f99ca301 7019157: errorHandler doesn't compile with super old gcc without precompiled headers Summary: old gccs don't support precompiled headers so have to supply includes Reviewed-by: phh, kamg ! src/share/vm/utilities/errorReporter.hpp From daniel.daugherty at oracle.com Sat Feb 12 10:07:41 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 12 Feb 2011 11:07:41 -0700 Subject: code review for jps fix (6637230) In-Reply-To: <4D56552D.3080404@oracle.com> References: <4D55F0F5.5000804@oracle.com> <4D56552D.3080404@oracle.com> Message-ID: <4D56CC6D.8070406@oracle.com> Dmitry, Thanks for the quick review! On 2/12/2011 2:38 AM, Dmitry Samersoff wrote: > Dan, > > Looks OK for me. Thanks! > + > + // leading blank not needed here because of the > + // next append() call > + errorString = "-- main class information > unavailable"; > + output.append(" "); > + output.append(MonitoredVmUtil.mainClass(vm, > + arguments.showLongPaths())); > > May be it could be done as (below) > to keep errorString uniform: > > errorString = " -- main class information > String s = MonitoredVmUtil.mainClass(vm, > arguments.showLongPaths()); > output.append(" ").append(s); So the trade is the comment and one less blank for a new temporary variable that's only used here. Hmmm... I think I'll stick with what's in the current webrev, but I'll keep that technique more in mind for the next time I'm whacking diagnostic output... Dan > > -Dmitry > > > On 2011-02-12 05:31, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix for the following jps bug: >> >> 6637230: 2/3 jps doesn't work for application waiting for direct attach >> Summary: Properly handle exceptions thrown when querying a monitored VM. >> Reviewed-by: >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/6637230-webrev/0/ >> >> Thanks, in advance, for any reviews. >> >> Dan >> > > From robert.ottenhag at oracle.com Mon Feb 14 07:46:27 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Mon, 14 Feb 2011 15:46:27 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 17 new changesets Message-ID: <20110214154657.B8F3947724@hg.openjdk.java.net> Changeset: b7a938236e43 Author: tonyp Date: 2011-01-31 16:28 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b7a938236e43 7014679: G1: deadlock during concurrent cleanup Summary: There's a potential deadlock between the concurrent cleanup thread and the GC workers that are trying to allocate and waiting for more free regions to be made available. Reviewed-by: iveresov, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: e49cfa28f585 Author: ysr Date: 2011-02-01 10:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e49cfa28f585 6999988: CMS: Increased fragmentation leading to promotion failure after CR#6631166 got implemented Summary: Fix calculation of _desired, in free list statistics, which was missing an intended set of parentheses. Reviewed-by: poonam, jmasa ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 986b2844f7a2 Author: brutisso Date: 2011-02-01 14:05 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/986b2844f7a2 6789220: CMS: intermittent timeout running nsk/regression/b4796926 Summary: The reference handler java thread and the GC could dead lock Reviewed-by: never, johnc, jcoomes ! src/share/vm/compiler/compileBroker.cpp Changeset: c33825b68624 Author: johnc Date: 2011-02-02 10:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c33825b68624 6923430: G1: assert(res != 0,"This should have worked.") 7007446: G1: expand the heap with a single step, not one region at a time Summary: Changed G1CollectedHeap::expand() to expand the committed space by calling VirtualSpace::expand_by() once rather than for every region in the expansion amount. This allows the success or failure of the expansion to be determined before creating any heap regions. Introduced a develop flag G1ExitOnExpansionFailure (false by default) that, when true, will exit the VM if the expansion of the committed space fails. Finally G1CollectedHeap::expand() returns a status back to it's caller so that the caller knows whether to attempt the allocation. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 176d0be30214 Author: phh Date: 2011-02-03 16:06 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/176d0be30214 7016998: gcutil class LinearLeastSquareFit doesn't initialize some of its fields Summary: Initialize _sum_x_squared, _intercept and _slope in constructor. Reviewed-by: bobv, coleenp ! src/share/vm/gc_implementation/shared/gcUtil.cpp Changeset: 907c1aed0f8c Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/907c1aed0f8c Added tag jdk7-b127 for changeset 102466e70deb ! .hgtags Changeset: 9a5762f44859 Author: trims Date: 2011-02-01 18:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9a5762f44859 Merge ! .hgtags - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 6ecdca5709df Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6ecdca5709df Added tag jdk7-b128 for changeset 9a5762f44859 ! .hgtags Changeset: ae4b185f2ed1 Author: trims Date: 2011-02-03 23:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ae4b185f2ed1 Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp Changeset: c6bf3ca2bb31 Author: trims Date: 2011-02-04 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c6bf3ca2bb31 Merge Changeset: e9f24eebafd4 Author: rottenha Date: 2011-02-07 08:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e9f24eebafd4 Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: e1523f7fd848 Author: rottenha Date: 2011-02-11 05:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e1523f7fd848 Merge - make/closed.make Changeset: 55b9f498dbce Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/55b9f498dbce Added tag jdk7-b129 for changeset ae4b185f2ed1 ! .hgtags Changeset: 14c2f31280dd Author: trims Date: 2011-02-11 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/14c2f31280dd Added tag hs21-b01 for changeset ae4b185f2ed1 ! .hgtags Changeset: 2a9f9f2200fa Author: trims Date: 2011-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2a9f9f2200fa Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: 762bc029de50 Author: trims Date: 2011-02-11 15:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/762bc029de50 7019104: Bump the HS21 build number to 02 Summary: Update the HS21 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 54df4702df97 Author: rottenha Date: 2011-02-14 03:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/54df4702df97 Merge - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java From daniel.daugherty at oracle.com Mon Feb 14 08:34:46 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 14 Feb 2011 09:34:46 -0700 Subject: code review for jps fix (6637230) In-Reply-To: <4D55F0F5.5000804@oracle.com> References: <4D55F0F5.5000804@oracle.com> Message-ID: <4D5959A6.3000507@oracle.com> Greetings, Minor tweaks after discussions with Dmitry: http://cr.openjdk.java.net/~dcubed/6637230-webrev/1/ Dan On 2/11/2011 7:31 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a fix for the following jps bug: > > 6637230: 2/3 jps doesn't work for application waiting for direct attach > Summary: Properly handle exceptions thrown when querying a monitored VM. > Reviewed-by: > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/6637230-webrev/0/ > > Thanks, in advance, for any reviews. > > Dan > > From Dmitry.Samersoff at oracle.com Mon Feb 14 09:20:23 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 14 Feb 2011 20:20:23 +0300 Subject: code review for jps fix (6637230) In-Reply-To: <4D5959A6.3000507@oracle.com> References: <4D55F0F5.5000804@oracle.com> <4D5959A6.3000507@oracle.com> Message-ID: <4D596457.5080703@oracle.com> Dan, Fine for me. Thank you! -Dmitry On 2011-02-14 19:34, Daniel D. Daugherty wrote: > Greetings, > > Minor tweaks after discussions with Dmitry: > > http://cr.openjdk.java.net/~dcubed/6637230-webrev/1/ > > Dan > > On 2/11/2011 7:31 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix for the following jps bug: >> >> 6637230: 2/3 jps doesn't work for application waiting for direct attach >> Summary: Properly handle exceptions thrown when querying a monitored VM. >> Reviewed-by: >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/6637230-webrev/0/ >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Mon Feb 14 09:24:38 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 14 Feb 2011 10:24:38 -0700 Subject: code review for jps fix (6637230) In-Reply-To: <4D596457.5080703@oracle.com> References: <4D55F0F5.5000804@oracle.com> <4D5959A6.3000507@oracle.com> <4D596457.5080703@oracle.com> Message-ID: <4D596556.80803@oracle.com> Thanks Dmitry! Dan On 2/14/2011 10:20 AM, Dmitry Samersoff wrote: > Dan, > > Fine for me. > > Thank you! > -Dmitry > > > On 2011-02-14 19:34, Daniel D. Daugherty wrote: >> Greetings, >> >> Minor tweaks after discussions with Dmitry: >> >> http://cr.openjdk.java.net/~dcubed/6637230-webrev/1/ >> >> Dan >> >> On 2/11/2011 7:31 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a fix for the following jps bug: >>> >>> 6637230: 2/3 jps doesn't work for application waiting for direct attach >>> Summary: Properly handle exceptions thrown when querying a monitored >>> VM. >>> Reviewed-by: >>> >>> Here is the URL for the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/6637230-webrev/0/ >>> >>> Thanks, in advance, for any reviews. >>> >>> Dan >>> >>> > > From daniel.daugherty at oracle.com Mon Feb 14 15:02:14 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 14 Feb 2011 16:02:14 -0700 Subject: code review for jvmstat/jps fix (6954420) Message-ID: <4D59B476.9070103@oracle.com> Greetings, I have a fix for the following jvmstat/jps bug: 6954420: 2/4 jps shows "process information unavailable" sometimes Summary: Make sure the backing store file is flushed in create_sharedmem_resources() and get_user_name_slow() no longer checks the size of the backing store file. Reviewed-by: Here is the URL for the webrev: http://cr.openjdk.java.net/~dcubed/6954420-webrev/0/ Thanks, in advance, for any reviews. Dan From coleen.phillimore at oracle.com Tue Feb 15 11:19:50 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Feb 2011 14:19:50 -0500 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used Message-ID: <4D5AD1D6.5090607@oracle.com> Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag and turn off biased locking if !UseFastLocking option is requested. open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 Tested against specjbb2005. Thanks, Coleen From coleen.phillimore at oracle.com Tue Feb 15 12:50:12 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Feb 2011 15:50:12 -0500 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5AD1D6.5090607@oracle.com> References: <4D5AD1D6.5090607@oracle.com> Message-ID: <4D5AE704.3070604@oracle.com> Summary: Turn off biased locking if !UseFastLocking or UseHeavyMonitors options are requested. Please hit reload. I tried to add a cleanup to the bug fix but it didn't work for server. Thanks, Coleen On 2/15/2011 2:19 PM, Coleen Phillimore wrote: > Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag > and turn off biased locking if !UseFastLocking option is requested. > > open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 > > Tested against specjbb2005. > > Thanks, > Coleen > From daniel.daugherty at oracle.com Tue Feb 15 13:01:17 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Feb 2011 14:01:17 -0700 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5AE704.3070604@oracle.com> References: <4D5AD1D6.5090607@oracle.com> <4D5AE704.3070604@oracle.com> Message-ID: <4D5AE99D.9040909@oracle.com> Thumbs up. Dan On 2/15/2011 1:50 PM, Coleen Phillimore wrote: > Summary: Turn off biased locking if !UseFastLocking or > UseHeavyMonitors options > are requested. > > Please hit reload. I tried to add a cleanup to the bug fix but it > didn't work for server. > > Thanks, > Coleen > > On 2/15/2011 2:19 PM, Coleen Phillimore wrote: >> Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag >> and turn off biased locking if !UseFastLocking option is requested. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 >> >> Tested against specjbb2005. >> >> Thanks, >> Coleen >> > From coleen.phillimore at oracle.com Tue Feb 15 12:56:59 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Feb 2011 15:56:59 -0500 Subject: Request for review: 7019689: Non-dependent name is found in dependent base class although it should,be rejected Message-ID: <4D5AE89B.4080305@oracle.com> Summary: fix hashtable.hpp to qualify non-dependant name with "this" Contributed-by: volker.simonis at gmail.com open webrev at http://cr.openjdk.java.net/~coleenp/7019689/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7019689 Tested additionally with windows and solaris builds. Thanks, Coleen From tom.rodriguez at oracle.com Tue Feb 15 15:09:00 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Feb 2011 15:09:00 -0800 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5AE704.3070604@oracle.com> References: <4D5AD1D6.5090607@oracle.com> <4D5AE704.3070604@oracle.com> Message-ID: Looks good. tom On Feb 15, 2011, at 12:50 PM, Coleen Phillimore wrote: > Summary: Turn off biased locking if !UseFastLocking or UseHeavyMonitors options > are requested. > > Please hit reload. I tried to add a cleanup to the bug fix but it didn't work for server. > > Thanks, > Coleen > > On 2/15/2011 2:19 PM, Coleen Phillimore wrote: >> Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag and turn off biased locking if !UseFastLocking option is requested. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 >> >> Tested against specjbb2005. >> >> Thanks, >> Coleen >> > From tom.rodriguez at oracle.com Tue Feb 15 15:25:13 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Feb 2011 15:25:13 -0800 Subject: Request for review: 7019689: Non-dependent name is found in dependent base class although it should, be rejected In-Reply-To: <4D5AE89B.4080305@oracle.com> References: <4D5AE89B.4080305@oracle.com> Message-ID: Looks good. tom On Feb 15, 2011, at 12:56 PM, Coleen Phillimore wrote: > Summary: fix hashtable.hpp to qualify non-dependant name with "this" > Contributed-by: volker.simonis at gmail.com > > open webrev at http://cr.openjdk.java.net/~coleenp/7019689/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7019689 > > Tested additionally with windows and solaris builds. > > Thanks, > Coleen > From daniel.daugherty at oracle.com Tue Feb 15 16:49:13 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Feb 2011 17:49:13 -0700 Subject: SECOND CALL: code review for jvmstat/jps fix (6954420) In-Reply-To: <4D59B476.9070103@oracle.com> References: <4D59B476.9070103@oracle.com> Message-ID: <4D5B1F09.1080307@oracle.com> I need a Runtime team reviewer! Dan On 2/14/2011 4:02 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a fix for the following jvmstat/jps bug: > > 6954420: 2/4 jps shows "process information unavailable" sometimes > Summary: Make sure the backing store file is flushed in > create_sharedmem_resources() and get_user_name_slow() no longer checks > the size of the backing store file. > Reviewed-by: > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/6954420-webrev/0/ > > Thanks, in advance, for any reviews. > > Dan > > > From karen.kinnear at oracle.com Tue Feb 15 18:12:14 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 15 Feb 2011 21:12:14 -0500 Subject: SECOND CALL: code review for jvmstat/jps fix (6954420) In-Reply-To: <4D5B1F09.1080307@oracle.com> References: <4D59B476.9070103@oracle.com> <4D5B1F09.1080307@oracle.com> Message-ID: Dan, Approved. Looks very tricky to track down. Only minor suggestion - line 1361 warning: if ret_code == OS_ERR, it might be nice to print %s and strerror(errno) rather than %d and ret_code. Not a big deal. thanks, Karen On Feb 15, 2011, at 7:49 PM, Daniel D. Daugherty wrote: > I need a Runtime team reviewer! > > Dan > > On 2/14/2011 4:02 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix for the following jvmstat/jps bug: >> >> 6954420: 2/4 jps shows "process information unavailable" sometimes >> Summary: Make sure the backing store file is flushed in >> create_sharedmem_resources() and get_user_name_slow() no longer >> checks the size of the backing store file. >> Reviewed-by: >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/6954420-webrev/0/ >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> >> From poonam.bajaj at oracle.com Tue Feb 15 18:26:17 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Wed, 16 Feb 2011 07:56:17 +0530 Subject: SECOND CALL: code review for jvmstat/jps fix (6954420) In-Reply-To: <4D5B1F09.1080307@oracle.com> References: <4D59B476.9070103@oracle.com> <4D5B1F09.1080307@oracle.com> Message-ID: <4D5B35C9.7060000@oracle.com> Looks good. One minor suggestion - you may consider changing the following warning message to something like "Could not get status information on file ". 1357 struct stat statbuf; 1358 int ret_code = ::stat(filename, &statbuf); 1359 if (ret_code == OS_ERR) { 1360 if (PrintMiscellaneous && Verbose) { 1361 warning("could not stat file %s: %d\n", filename, ret_code); 1362 } Thanks, Poonam On 2/16/2011 6:19 AM, Daniel D. Daugherty wrote: > I need a Runtime team reviewer! > > Dan > > On 2/14/2011 4:02 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix for the following jvmstat/jps bug: >> >> 6954420: 2/4 jps shows "process information unavailable" sometimes >> Summary: Make sure the backing store file is flushed in >> create_sharedmem_resources() and get_user_name_slow() no longer >> checks the size of the backing store file. >> Reviewed-by: >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/6954420-webrev/0/ >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> >> From poonam.bajaj at oracle.com Tue Feb 15 18:44:39 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Wed, 16 Feb 2011 08:14:39 +0530 Subject: Request for review: 7019689: Non-dependent name is found in dependent base class although it should,be rejected In-Reply-To: <4D5AE89B.4080305@oracle.com> References: <4D5AE89B.4080305@oracle.com> Message-ID: <4D5B3A17.2050707@oracle.com> Hi Coleen, Fix looks good. Just noticed that the bug is not visible publically in bugs.sun.com, so maybe you can send a brief discription of the problem to the alias. Thanks, Poonam On 2/16/2011 2:26 AM, Coleen Phillimore wrote: > Summary: fix hashtable.hpp to qualify non-dependant name with "this" > Contributed-by: volker.simonis at gmail.com > > open webrev at http://cr.openjdk.java.net/~coleenp/7019689/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7019689 > > Tested additionally with windows and solaris builds. > > Thanks, > Coleen > From daniel.daugherty at oracle.com Tue Feb 15 18:54:25 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Feb 2011 19:54:25 -0700 Subject: SECOND CALL: code review for jvmstat/jps fix (6954420) In-Reply-To: References: <4D59B476.9070103@oracle.com> <4D5B1F09.1080307@oracle.com> Message-ID: <4D5B3C61.3060207@oracle.com> Karen and Poonam, Two reviewers commenting on the same line a few minutes apart... the universe speaks... and I listen... I changed to: 1361c1361,1362 < warning("could not stat file %s: %d\n", filename, ret_code); --- > warning("Could not get status information from file %s: %s\n", > filename, strerror(errno)); Thanks for the reviews! Dan On 2/15/2011 7:12 PM, Karen Kinnear wrote: > Dan, > > Approved. > > Looks very tricky to track down. > > Only minor suggestion - line 1361 warning: if ret_code == OS_ERR, it > might be nice to > print %s and strerror(errno) rather than %d and ret_code. Not a big deal. > > thanks, > Karen > On 2/15/2011 7:26 PM, Poonam Bajaj wrote: >> Looks good. One minor suggestion - you may consider changing the >> following warning message to something like "Could not get status >> information on file ". >> >> 1357 struct stat statbuf; >> 1358 int ret_code = ::stat(filename, &statbuf); >> 1359 if (ret_code == OS_ERR) { >> 1360 if (PrintMiscellaneous && Verbose) { >> 1361 warning("could not stat file %s: %d\n", filename, >> ret_code); >> 1362 } >> >> >> Thanks, >> Poonam From coleen.phillimore at oracle.com Tue Feb 15 20:29:25 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Feb 2011 23:29:25 -0500 Subject: Request for review: 7019689: Non-dependent name is found in dependent base class although it should,be rejected In-Reply-To: <4D5B3A17.2050707@oracle.com> References: <4D5AE89B.4080305@oracle.com> <4D5B3A17.2050707@oracle.com> Message-ID: <4D5B52A5.7090002@oracle.com> On 2/15/2011 9:44 PM, Poonam Bajaj wrote: > Hi Coleen, > > Fix looks good. > > Just noticed that the bug is not visible publically in bugs.sun.com, > so maybe > you can send a brief discription of the problem to the alias. Thanks Poonam, The bug comes from an email that Volker Simonis sent and I cut/pasted this into the synopsis: "Notice that this patch contains one additional change compared to the patch in the blog. While I did the tests for the blog with an slightlyoutdated HS20b03 I synced a brand new version today to prepare the patch. With this new version I found a true C++ bug in"src/share/vm/utilities/hashtable.hpp" which was introduced recently by the "6990754: Use native memory and reference counting to implementSymbolTable" change and which has to do with name lookup of nondependent names in dependent base classes (seehttp://www.parashift.com/c++-faq-lite/templates.html#faq-35.19 for a nice explanation). Wouldn't have happened with Clang:)" The bugs.sun.com bug should appear soon (maybe in a day or two). Thanks, Coleen > > Thanks, > Poonam > > On 2/16/2011 2:26 AM, Coleen Phillimore wrote: >> Summary: fix hashtable.hpp to qualify non-dependant name with "this" >> Contributed-by: volker.simonis at gmail.com >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7019689/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7019689 >> >> Tested additionally with windows and solaris builds. >> >> Thanks, >> Coleen >> From daniel.daugherty at oracle.com Tue Feb 15 21:21:40 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 16 Feb 2011 05:21:40 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6954420: 2/4 jps shows "process information unavailable" sometimes Message-ID: <20110216052142.109E54779F@hg.openjdk.java.net> Changeset: de14f1eee390 Author: dcubed Date: 2011-02-15 19:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/de14f1eee390 6954420: 2/4 jps shows "process information unavailable" sometimes Summary: Make sure the backing store file is flushed in create_sharedmem_resources() and get_user_name_slow() no longer checks the size of the backing store file. Reviewed-by: briand, swamyv, acorn, poonam ! src/os/windows/vm/perfMemory_windows.cpp From David.Holmes at oracle.com Tue Feb 15 22:33:20 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 16 Feb 2011 16:33:20 +1000 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5AD1D6.5090607@oracle.com> References: <4D5AD1D6.5090607@oracle.com> Message-ID: <4D5B6FB0.3040208@oracle.com> Hi Coleen, I don't see a UseHeavyWeightMonitors flag in the current source. And the change in arguments.cpp refers to both UseHeavyMonitors and UseFastLocking, so I'm confused about this "renaming". And I'm not sure this warning logic is quite right: + // Turn off biased locking for locking debug mode flags + if (!UseFastLocking || UseHeavyMonitors) { + if (!FLAG_IS_DEFAULT(UseBiasedLocking)) { + warning("Biased Locking is not supported with locking debug flags"); + } + UseBiasedLocking = false; + } These FLAG macros always confuse me but surely the issue is whether UseBiasedLocking is true, not whether it has its "default value" ??? On some architectures the default value of UseBiasedLocking is false. David Coleen Phillimore said the following on 02/16/11 05:19: > Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag and > turn off biased locking if !UseFastLocking option is requested. > > open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 > > Tested against specjbb2005. > > Thanks, > Coleen > From david.holmes at oracle.com Wed Feb 16 03:02:42 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 16 Feb 2011 11:02:42 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110216110251.8863A477B5@hg.openjdk.java.net> Changeset: b76d12f4ab2d Author: dholmes Date: 2011-02-14 19:27 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b76d12f4ab2d 7018429: JPRT: Update Makefile to use ALT_JDK_TARGET_IMPORT_PATH for copying JDK Summary: Set JDK_IMPORT_PATH to ALT_JDK_TARGET_IMPORT_PATH if it is defined Reviewed-by: phh, ohair ! make/Makefile ! make/defs.make Changeset: 5415131bc5ab Author: dholmes Date: 2011-02-16 01:42 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5415131bc5ab Merge From daniel.daugherty at oracle.com Wed Feb 16 06:19:30 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Feb 2011 07:19:30 -0700 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5B6FB0.3040208@oracle.com> References: <4D5AD1D6.5090607@oracle.com> <4D5B6FB0.3040208@oracle.com> Message-ID: <4D5BDCF2.9050401@oracle.com> There was a typo in the original review request: UseHeavyWeightMonitors -> UseHeavyMonitors which Coleen fixed in a subsequent post. Also the scope of the fix was revised in the second review request because the semantics of the two flags are not the same. Coleen's revised fix is focused on fixing the biased locking crash when UseHeavyMonitors is enabled. This logic: + if (!FLAG_IS_DEFAULT(UseBiasedLocking)) { means "if UseBiasedLocking has been specified on the command line". This handles the case where UseBiasedLocking is both specified on the command line and the system default for UseBiasedLocking is true. In that case, a warning is issued because you don't get what you asked for... Dan On 2/15/2011 11:33 PM, David Holmes wrote: > Hi Coleen, > > I don't see a UseHeavyWeightMonitors flag in the current source. And > the change in arguments.cpp refers to both UseHeavyMonitors and > UseFastLocking, so I'm confused about this "renaming". > > And I'm not sure this warning logic is quite right: > > + // Turn off biased locking for locking debug mode flags > + if (!UseFastLocking || UseHeavyMonitors) { > + if (!FLAG_IS_DEFAULT(UseBiasedLocking)) { > + warning("Biased Locking is not supported with locking debug > flags"); > + } > + UseBiasedLocking = false; > + } > > These FLAG macros always confuse me but surely the issue is whether > UseBiasedLocking is true, not whether it has its "default value" ??? > > On some architectures the default value of UseBiasedLocking is false. > > David > > > Coleen Phillimore said the following on 02/16/11 05:19: >> Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag >> and turn off biased locking if !UseFastLocking option is requested. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 >> >> Tested against specjbb2005. >> >> Thanks, >> Coleen >> From coleen.phillimore at oracle.com Wed Feb 16 07:47:18 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Feb 2011 10:47:18 -0500 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5B6FB0.3040208@oracle.com> References: <4D5AD1D6.5090607@oracle.com> <4D5B6FB0.3040208@oracle.com> Message-ID: <4D5BF186.3020504@oracle.com> On 2/16/2011 1:33 AM, David Holmes wrote: > Hi Coleen, > > I don't see a UseHeavyWeightMonitors flag in the current source. And > the change in arguments.cpp refers to both UseHeavyMonitors and > UseFastLocking, so I'm confused about this "renaming". > > And I'm not sure this warning logic is quite right: > > + // Turn off biased locking for locking debug mode flags > + if (!UseFastLocking || UseHeavyMonitors) { > + if (!FLAG_IS_DEFAULT(UseBiasedLocking)) { > + warning("Biased Locking is not supported with locking debug > flags"); > + } > + UseBiasedLocking = false; > + } > > These FLAG macros always confuse me but surely the issue is whether > UseBiasedLocking is true, not whether it has its "default value" ??? > > On some architectures the default value of UseBiasedLocking is false. You are right. The FLAG_IS_DEFAULT is if someone specified it on the command line, but I should also check if they specified it to be true. The earlier description was replaced with: Summary: Turn off biased locking if !UseFastLocking or UseHeavyMonitors options are requested. Thanks, Coleen > > David > > > Coleen Phillimore said the following on 02/16/11 05:19: >> Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag >> and turn off biased locking if !UseFastLocking option is requested. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 >> >> Tested against specjbb2005. >> >> Thanks, >> Coleen >> From daniel.daugherty at oracle.com Wed Feb 16 07:56:15 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Feb 2011 08:56:15 -0700 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5BF186.3020504@oracle.com> References: <4D5AD1D6.5090607@oracle.com> <4D5B6FB0.3040208@oracle.com> <4D5BF186.3020504@oracle.com> Message-ID: <4D5BF39F.9000404@oracle.com> On 2/16/2011 8:47 AM, Coleen Phillimore wrote: > On 2/16/2011 1:33 AM, David Holmes wrote: >> Hi Coleen, >> >> I don't see a UseHeavyWeightMonitors flag in the current source. And >> the change in arguments.cpp refers to both UseHeavyMonitors and >> UseFastLocking, so I'm confused about this "renaming". >> >> And I'm not sure this warning logic is quite right: >> >> + // Turn off biased locking for locking debug mode flags >> + if (!UseFastLocking || UseHeavyMonitors) { >> + if (!FLAG_IS_DEFAULT(UseBiasedLocking)) { >> + warning("Biased Locking is not supported with locking debug >> flags"); >> + } >> + UseBiasedLocking = false; >> + } >> >> These FLAG macros always confuse me but surely the issue is whether >> UseBiasedLocking is true, not whether it has its "default value" ??? >> >> On some architectures the default value of UseBiasedLocking is false. > > You are right. The FLAG_IS_DEFAULT is if someone specified it on the > command line, but I should also check if they specified it to be true. That's right! I only had it half correct. :-( !FLAG_IS_DEFAULT(foo) && foo means they set it on the command line to true and we should warn them... Sigh... I've had more coffee now... Dan > > The earlier description was replaced with: > Summary: Turn off biased locking if !UseFastLocking or > UseHeavyMonitors options are requested. > > > Thanks, > Coleen > >> >> David >> >> >> Coleen Phillimore said the following on 02/16/11 05:19: >>> Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag >>> and turn off biased locking if !UseFastLocking option is requested. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 >>> >>> Tested against specjbb2005. >>> >>> Thanks, >>> Coleen >>> > From John.Coomes at oracle.com Wed Feb 16 10:06:11 2011 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 16 Feb 2011 10:06:11 -0800 Subject: review request (S): 6962930 make the string table size configurable Message-ID: <19804.4627.94089.715688@oracle.com> I'd appreciate reviews of a small change to allow the string table size to be set on the command line: http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ -John From keith.mcguigan at oracle.com Wed Feb 16 10:15:57 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 16 Feb 2011 13:15:57 -0500 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: <19804.4627.94089.715688@oracle.com> References: <19804.4627.94089.715688@oracle.com> Message-ID: <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> Looks good. Nothing in the SA agent was calling getStringTableSize()? On Feb 16, 2011, at 1:06 PM, John Coomes wrote: > I'd appreciate reviews of a small change to allow the string table > size to be set on the command line: > > http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ > > -John > From paul.hohensee at oracle.com Wed Feb 16 10:29:51 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 16 Feb 2011 13:29:51 -0500 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> References: <19804.4627.94089.715688@oracle.com> <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> Message-ID: <4D5C179F.2080300@oracle.com> It does. See agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java. stringTableSize = db.lookupIntConstant("StringTable::string_table_size").intValue(); Paul On 2/16/11 1:15 PM, Keith McGuigan wrote: > > Looks good. Nothing in the SA agent was calling getStringTableSize()? > > On Feb 16, 2011, at 1:06 PM, John Coomes wrote: > >> I'd appreciate reviews of a small change to allow the string table >> size to be set on the command line: >> >> http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ >> >> -John >> > From tom.rodriguez at oracle.com Wed Feb 16 10:33:01 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Feb 2011 10:33:01 -0800 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> References: <19804.4627.94089.715688@oracle.com> <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> Message-ID: <1D428418-464F-4F49-A6FC-846D61493EA7@oracle.com> On Feb 16, 2011, at 10:15 AM, Keith McGuigan wrote: > > Looks good. Nothing in the SA agent was calling getStringTableSize()? No. Remember that's the default string table size. If you really want to ask the StringTable what size it is, you'd call BasicHashtable.tableSize() on the instance. tom > > On Feb 16, 2011, at 1:06 PM, John Coomes wrote: > >> I'd appreciate reviews of a small change to allow the string table >> size to be set on the command line: >> >> http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ >> >> -John >> > From tom.rodriguez at oracle.com Wed Feb 16 10:38:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Feb 2011 10:38:32 -0800 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: <4D5C179F.2080300@oracle.com> References: <19804.4627.94089.715688@oracle.com> <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> <4D5C179F.2080300@oracle.com> Message-ID: Oops. That line should be deleted too, along with the declaration of stringTableSize in StringTable.java. tom On Feb 16, 2011, at 10:29 AM, Paul Hohensee wrote: > It does. See agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java. > > stringTableSize = db.lookupIntConstant("StringTable::string_table_size").intValue(); > > Paul > > On 2/16/11 1:15 PM, Keith McGuigan wrote: >> >> Looks good. Nothing in the SA agent was calling getStringTableSize()? >> >> On Feb 16, 2011, at 1:06 PM, John Coomes wrote: >> >>> I'd appreciate reviews of a small change to allow the string table >>> size to be set on the command line: >>> >>> http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ >>> >>> -John >>> >> From coleen.phillimore at oracle.com Wed Feb 16 16:23:03 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Feb 2011 00:23:03 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6840152: JVM crashes when heavyweight monitors are used Message-ID: <20110217002305.70141477F5@hg.openjdk.java.net> Changeset: c08677f98289 Author: coleenp Date: 2011-02-16 11:34 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c08677f98289 6840152: JVM crashes when heavyweight monitors are used Summary: Turn off biased locking if !UseFastLocking or UseHeavyMonitors options are requested. Reviewed-by: phh, never, dcubed, dholmes ! src/share/vm/runtime/arguments.cpp From David.Holmes at oracle.com Wed Feb 16 17:02:33 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 17 Feb 2011 11:02:33 +1000 Subject: Request for review 6840152: JVM crashes when heavyweight monitors are used In-Reply-To: <4D5BF186.3020504@oracle.com> References: <4D5AD1D6.5090607@oracle.com> <4D5B6FB0.3040208@oracle.com> <4D5BF186.3020504@oracle.com> Message-ID: <4D5C73A9.5050808@oracle.com> Coleen Phillimore said the following on 02/17/11 01:47: > On 2/16/2011 1:33 AM, David Holmes wrote: >> >> I don't see a UseHeavyWeightMonitors flag in the current source. And >> the change in arguments.cpp refers to both UseHeavyMonitors and >> UseFastLocking, so I'm confused about this "renaming". >> >> And I'm not sure this warning logic is quite right: >> >> + // Turn off biased locking for locking debug mode flags >> + if (!UseFastLocking || UseHeavyMonitors) { >> + if (!FLAG_IS_DEFAULT(UseBiasedLocking)) { >> + warning("Biased Locking is not supported with locking debug >> flags"); >> + } >> + UseBiasedLocking = false; >> + } >> >> These FLAG macros always confuse me but surely the issue is whether >> UseBiasedLocking is true, not whether it has its "default value" ??? >> >> On some architectures the default value of UseBiasedLocking is false. > > You are right. The FLAG_IS_DEFAULT is if someone specified it on the > command line, but I should also check if they specified it to be true. That's the bit that always confuses me, it doesn't mean "flag currently has the same value as its default", but rather "flag has not been set explicitly". Anyway all clear now and putback is good. Thanks, David > The earlier description was replaced with: > Summary: Turn off biased locking if !UseFastLocking or UseHeavyMonitors > options are requested. > > > Thanks, > Coleen > >> >> David >> >> >> Coleen Phillimore said the following on 02/16/11 05:19: >>> Summary: Renamed UseHeavyWeightMonitors flag to !UseFastLocking flag >>> and turn off biased locking if !UseFastLocking option is requested. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6840152/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6840152 >>> >>> Tested against specjbb2005. >>> >>> Thanks, >>> Coleen >>> > From David.Holmes at oracle.com Wed Feb 16 17:07:29 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 17 Feb 2011 11:07:29 +1000 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: <19804.4627.94089.715688@oracle.com> References: <19804.4627.94089.715688@oracle.com> Message-ID: <4D5C74D1.1040902@oracle.com> Can clarify in globals.hpp whether the size is in bytes, KB, MB. Thanks, David John Coomes said the following on 02/17/11 04:06: > I'd appreciate reviews of a small change to allow the string table > size to be set on the command line: > > http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ > > -John > From coleen.phillimore at oracle.com Wed Feb 16 18:55:54 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Feb 2011 02:55:54 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110217025606.A639147806@hg.openjdk.java.net> Changeset: 3adec115d40d Author: coleenp Date: 2011-02-16 17:12 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3adec115d40d 7019689: Non-dependent name is found in dependent base class although it should be rejected Summary: fix hashtable.hpp to qualify non-dependant name with "this" Reviewed-by: phh, never, poonam Contributed-by: volker.simonis at gmail.com ! src/share/vm/utilities/hashtable.hpp Changeset: a959935a5732 Author: coleenp Date: 2011-02-16 16:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a959935a5732 Merge From coleen.phillimore at oracle.com Fri Feb 18 14:33:19 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Feb 2011 17:33:19 -0500 Subject: Request for review 7019557: SharedMiscDataSize too small for 64-bit fastdebug JVM Message-ID: <4D5EF3AF.2050601@oracle.com> Summary: Increase default SharedMiscDataSize open webrev at http://cr.openjdk.java.net/~coleenp/7019557/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7019557 Thanks, Coleen From daniel.daugherty at oracle.com Fri Feb 18 14:53:16 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 18 Feb 2011 15:53:16 -0700 Subject: Request for review 7019557: SharedMiscDataSize too small for 64-bit fastdebug JVM In-Reply-To: <4D5EF3AF.2050601@oracle.com> References: <4D5EF3AF.2050601@oracle.com> Message-ID: <4D5EF85C.9000107@oracle.com> src/share/vm/runtime/globals.hpp Thumbs up. Dan On 2/18/2011 3:33 PM, Coleen Phillimore wrote: > Summary: Increase default SharedMiscDataSize > > open webrev at http://cr.openjdk.java.net/~coleenp/7019557/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7019557 > > Thanks, > Coleen > From keith.mcguigan at oracle.com Fri Feb 18 15:06:56 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 18 Feb 2011 18:06:56 -0500 Subject: Request for review 7019557: SharedMiscDataSize too small for 64-bit fastdebug JVM In-Reply-To: <4D5EF3AF.2050601@oracle.com> References: <4D5EF3AF.2050601@oracle.com> Message-ID: good On Feb 18, 2011, at 5:33 PM, Coleen Phillimore wrote: > Summary: Increase default SharedMiscDataSize > > open webrev at http://cr.openjdk.java.net/~coleenp/7019557/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7019557 > > Thanks, > Coleen > From coleen.phillimore at oracle.com Fri Feb 18 22:21:01 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 19 Feb 2011 06:21:01 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7019557: SharedMiscDataSize too small for 64-bit fastdebug JVM Message-ID: <20110219062103.C192E478A3@hg.openjdk.java.net> Changeset: 6e70f1bb7f6f Author: coleenp Date: 2011-02-18 18:26 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6e70f1bb7f6f 7019557: SharedMiscDataSize too small for 64-bit fastdebug JVM Summary: Increase default SharedMiscDataSize Reviewed-by: dcubed, kamg ! src/share/vm/runtime/globals.hpp From Dmitry.Samersoff at oracle.com Mon Feb 21 04:20:59 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 21 Feb 2011 15:20:59 +0300 Subject: Request for review (S) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages Message-ID: <4D6258AB.3090802@oracle.com> Hi Everyone, http://cr.openjdk.java.net/~dsamersoff/7017193 I'm uncomfortable with one malloc/free cycle per line so decided to get rid of getline() call completely. -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From robert.ottenhag at oracle.com Mon Feb 21 08:52:14 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Mon, 21 Feb 2011 16:52:14 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 10 new changesets Message-ID: <20110221165234.C63F54791C@hg.openjdk.java.net> Changeset: c798c277ddd1 Author: brutisso Date: 2011-02-03 20:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c798c277ddd1 7015169: GC Cause not always set Summary: Sometimes the gc cause was not always set. This caused JStat to print the wrong information. Reviewed-by: tonyp, ysr Contributed-by: suenaga.yasumasa at oss.ntt.co.jp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/services/heapDumper.cpp Changeset: c5a923563727 Author: ysr Date: 2011-02-07 22:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c5a923563727 6912621: iCMS: Error: assert(_markBitMap.isMarked(addr + 1),"Missing Printezis bit?") Summary: Fix block_size_if_printezis_bits() so it does not expect the bits, only uses them when available. Fix block_size_no_stall() so it does not stall when the bits are missing such cases, letting the caller deal with zero size returns. Constant pool cache oops do not need to be unparsable or conc_unsafe after their klass pointer is installed. Some cosmetic clean-ups and some assertion checking for conc-usafety which, in the presence of class file redefinition, has no a-priori time boundedness, so all GCs must be able to safely deal with putatively conc-unsafe objects in a stop-world pause. Reviewed-by: jmasa, johnc ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: e5383553fd4e Author: stefank Date: 2011-02-08 12:33 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e5383553fd4e 7014851: Remove unused parallel compaction code Summary: Removed. Reviewed-by: jcoomes, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.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/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! 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/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! 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.pcgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: 59e20a452a2a Author: johnc Date: 2011-02-09 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/59e20a452a2a 7017008: G1: Turn on compressed oops by default. Summary: Normally compressed oops is enabled when the maximum heap size is under a certain limit, except when G1 is also enabled. Remove this limitation. Also re-enable GCBasher testing with G1 on 64 bit windows in jprt. Reviewed-by: jcoomes, brutisso, tonyp ! make/jprt.properties ! src/share/vm/runtime/arguments.cpp Changeset: 183658a2d0b3 Author: ysr Date: 2011-02-10 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/183658a2d0b3 7018302: newly added assert related to size of constantPoolOop causes secondary assertions or crashes Summary: 6912621 used a raw oop in the newly added assert following an allocation attempt that could result in a GC. Reviewed-by: jmasa ! src/share/vm/oops/constantPoolKlass.cpp Changeset: 55cc33cf55bc Author: stefank Date: 2011-02-11 14:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/55cc33cf55bc 7018257: jmm_DumpThreads allocates into permgen Summary: Don't allocate in permgen Reviewed-by: ysr, sla ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/services/management.cpp Changeset: f7702f8c0e25 Author: tonyp Date: 2011-02-14 22:21 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f7702f8c0e25 Merge ! make/jprt.properties ! src/share/vm/services/management.cpp Changeset: e9aa2ca89ad6 Author: kamg Date: 2011-02-16 16:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e9aa2ca89ad6 7019718: make error reporting flags product instead of diagnostic Summary: see synopsis Reviewed-by: acorn, coleenp ! src/share/vm/runtime/globals.hpp Changeset: 02368ad6c63f Author: trims Date: 2011-02-16 17:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/02368ad6c63f Merge Changeset: f77b3ec064b0 Author: rottenha Date: 2011-02-21 04:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f77b3ec064b0 Merge - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From keith.mcguigan at oracle.com Mon Feb 21 13:03:34 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 21 Feb 2011 16:03:34 -0500 Subject: Request for review (S): 7020118 Message-ID: <190F6550-F00D-4752-8594-B44B9B2BC2C4@oracle.com> Fix for 7020118: Alter frame assignability to allow for exception handler coverage of invokespecial . Webrev: http://cr.openjdk.java.net/~kamg/7020118/webrev.00/ This fix to the verifier makes it possible to create an exception handler that covers the entirety of an method, by specifying "Top" types in the stackmap in place of "UninitializedThis". NetBeans profiler would like to generate such handlers, but the current implementation doesn't allow it. Thanks for any review. -- - Keith From David.Holmes at oracle.com Mon Feb 21 15:47:19 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 22 Feb 2011 09:47:19 +1000 Subject: Request for review (S) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D6258AB.3090802@oracle.com> References: <4D6258AB.3090802@oracle.com> Message-ID: <4D62F987.5050109@oracle.com> Dmitry, Dmitry Samersoff said the following on 02/21/11 22:20: > Hi Everyone, > > http://cr.openjdk.java.net/~dsamersoff/7017193 > > I'm uncomfortable with one malloc/free cycle per line so decided to get > rid of getline() call completely. As I stated in the CR you do not have to do one malloc/free per line with getline. The buffer can be reused and will be realloc'd if needed by getline, and then can be freed at the end. I can't evaluate your change without understanding both the detailed logic of the original code and your new code. David From Dmitry.Samersoff at oracle.com Mon Feb 21 22:45:26 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 22 Feb 2011 09:45:26 +0300 Subject: Request for review (S) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D62F987.5050109@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D62F987.5050109@oracle.com> Message-ID: <4D635B86.4080700@oracle.com> David, As discussed off-line with Coleen - I'll prepare more readable fix. -Dmitry On 2011-02-22 02:47, David Holmes wrote: > Dmitry, > > Dmitry Samersoff said the following on 02/21/11 22:20: >> Hi Everyone, >> >> http://cr.openjdk.java.net/~dsamersoff/7017193 >> >> I'm uncomfortable with one malloc/free cycle per line so decided to >> get rid of getline() call completely. > > As I stated in the CR you do not have to do one malloc/free per line > with getline. The buffer can be reused and will be realloc'd if needed > by getline, and then can be freed at the end. > > I can't evaluate your change without understanding both the detailed > logic of the original code and your new code. > > David -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From poonam.bajaj at oracle.com Mon Feb 21 23:15:37 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 22 Feb 2011 12:45:37 +0530 Subject: Request for review (S) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D6258AB.3090802@oracle.com> References: <4D6258AB.3090802@oracle.com> Message-ID: <4D636299.9010603@oracle.com> Hi Dmitry, Few comments: - These changes read the file character by character instead of one line at a time. Did you check if there is any performance impact due to that ? - I think the comments should be outside the corresponding if blocks. And indentation of comment at line 2675 needs to be corrected. 2673 if ( bup == buf+sizeof(buf)-1 ){ 2674 /* Address part of /proc/maps couldn't be more than 128 bytes, 2675 * flush the buffer 2676 */ 2677 assert(checkme != true, "Should never happen"); 2678 bup = buf; 2679 continue; 2680 } 2681 2682 if (*bup == '\n'){ 2683 /* We already seen '[' so it's safe to step back. 2684 * if we don't have ack] keyword in this line just flush the buffer 2685 * buffer. 2686 */ 2687 if (checkme == false || *((int*)(bup-4)) != *((int*) "ack]") ){ 2688 bup = buf; 2689 checkme = false; 2690 continue; 2691 } - bup variable may be renamed to 'buf_pointer' or something like that. Thanks, Poonam On 2/21/2011 5:50 PM, Dmitry Samersoff wrote: > Hi Everyone, > > http://cr.openjdk.java.net/~dsamersoff/7017193 > > I'm uncomfortable with one malloc/free cycle per line so decided to > get rid of getline() call completely. > > -Dmitry > > From tom.rodriguez at oracle.com Tue Feb 22 13:32:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Feb 2011 13:32:57 -0800 Subject: Request for review (S): 7020118 In-Reply-To: <190F6550-F00D-4752-8594-B44B9B2BC2C4@oracle.com> References: <190F6550-F00D-4752-8594-B44B9B2BC2C4@oracle.com> Message-ID: On Feb 21, 2011, at 1:03 PM, Keith McGuigan wrote: > > Fix for 7020118: Alter frame assignability to allow for exception handler coverage of invokespecial . > > Webrev: http://cr.openjdk.java.net/~kamg/7020118/webrev.00/ > > This fix to the verifier makes it possible to create an exception handler that covers the entirety of an method, by specifying "Top" types in the stackmap in place of "UninitializedThis". NetBeans profiler would like to generate such handlers, but the current implementation doesn't allow it. > > Thanks for any review. minor typo: "This a rare situation" Do you need to guard the stack bounds more carefully? They don't have to be of a similar length. In the exception case, target will always be 1 and the current stack should always be more than one because of the invokespecial. I don't see anything that keeps this from being called in other contexts though. Maybe it's impossible for this path to be used in other contexts because of the flag_this_uninit check? There appear to be no range checks even in debug mode, so are the out of bounds values guaranteed to be top? Other than that it seems to implement what's described in the spec bug report so I guess it's good. tom > > -- > - Keith > > From keith.mcguigan at oracle.com Tue Feb 22 14:08:22 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 22 Feb 2011 17:08:22 -0500 Subject: Request for review (S): 7020118 In-Reply-To: References: <190F6550-F00D-4752-8594-B44B9B2BC2C4@oracle.com> Message-ID: <120E56C2-AD8A-4DFC-91DA-7FC1AFD7CDBF@oracle.com> On Feb 22, 2011, at 4:32 PM, Tom Rodriguez wrote: > > On Feb 21, 2011, at 1:03 PM, Keith McGuigan wrote: > >> >> Fix for 7020118: Alter frame assignability to allow for exception >> handler coverage of invokespecial . >> >> Webrev: http://cr.openjdk.java.net/~kamg/7020118/webrev.00/ >> >> This fix to the verifier makes it possible to create an exception >> handler that covers the entirety of an method, by specifying >> "Top" types in the stackmap in place of "UninitializedThis". >> NetBeans profiler would like to generate such handlers, but the >> current implementation doesn't allow it. >> >> Thanks for any review. > > minor typo: "This a rare situation" Fixed, thanks. > Do you need to guard the stack bounds more carefully? They don't > have to be of a similar length. In the exception case, target will > always be 1 and the current stack should always be more than one > because of the invokespecial. I don't see anything that keeps this > from being called in other contexts though. Maybe it's impossible > for this path to be used in other contexts because of the > flag_this_uninit check? There appear to be no range checks even in > debug mode, so are the out of bounds values guaranteed to be top? That function bails out immediately if the stack sizes are not the same (see the first 'if' statement in the function). > Other than that it seems to implement what's described in the spec > bug report so I guess it's good. Thanks for the review! -- - Keith From staffan.larsen at oracle.com Thu Feb 24 05:49:42 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Feb 2011 05:49:42 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows Message-ID: <068814b2-17aa-425c-ad71-e3732238ffbc@default> http://cr.openjdk.java.net/~sla/7022037/webrev.00/ When running in Visual Studio the console window is closed as soon as the debugged process ends (whether it is a normal end or an assert). This makes it impossible to see the output from the process after it has ended. Suggested fix: At the end of normal execution we can check if a debugger is present and wait for a keypress before exiting. At the end of an assert we also check if a debugger is attached and use the same method as -XX:+ShowMessageBoxOnError to catch the error in the debugger. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110224/de4982c9/attachment.html From Dmitry.Samersoff at oracle.com Thu Feb 24 06:16:02 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 24 Feb 2011 17:16:02 +0300 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <068814b2-17aa-425c-ad71-e3732238ffbc@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> Message-ID: <4D666822.5030706@oracle.com> Staffan, 1. Is it possible to put this functionality under command line flag? We have PauseAtStartup and I think it's better to have similar PauseAtShutdown than autodetect debugger. 2. It's better to create separate function for it. -Dmitry On 2011-02-24 16:49, Staffan Larsen wrote: > http://cr.openjdk.java.net/~sla/7022037/webrev.00/ > > When running in Visual Studio the console window is closed as soon as > the debugged process ends (whether it is a normal end or an assert). > This makes it impossible to see the output from the process after it has > ended. > > Suggested fix: At the end of normal execution we can check if a debugger > is present and wait for a keypress before exiting. At the end of an > assert we also check if a debugger is attached and use the same method > as -XX:+ShowMessageBoxOnError to catch the error in the debugger. > > Thanks, > > /Staffan > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From henrik.osterdahl at oracle.com Thu Feb 24 06:16:49 2011 From: henrik.osterdahl at oracle.com (=?ISO-8859-1?Q?Henrik_=D6sterdahl?=) Date: Thu, 24 Feb 2011 15:16:49 +0100 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <068814b2-17aa-425c-ad71-e3732238ffbc@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> Message-ID: <4D666851.8090706@oracle.com> On 2011-02-24 14:49, Staffan Larsen wrote: > http://cr.openjdk.java.net/~sla/7022037/webrev.00/ > > When running in Visual Studio the console window is closed as soon as > the debugged process ends (whether it is a normal end or an assert). > This makes it impossible to see the output from the process after it has > ended. > > Suggested fix: At the end of normal execution we can check if a debugger > is present and wait for a keypress before exiting. At the end of an > assert we also check if a debugger is attached and use the same method > as -XX:+ShowMessageBoxOnError to catch the error in the debugger. Looks good. This functionality already exists in JRockit and is very useful. /H From staffan.larsen at oracle.com Thu Feb 24 06:27:17 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Feb 2011 06:27:17 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <4D666822.5030706@oracle.com> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default 4D666822.5030706@oracle.com> Message-ID: <9123f709-93f6-472b-a472-bf8a45665b45@default> > -----Original Message----- > From: Dmitry Samersoff > Sent: den 24 februari 2011 3:16 > To: Staffan Larsen > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: Request for review (S): 7022037: Pause when exiting if a > debugger is attached on windows > > Staffan, > > 1. Is it possible to put this functionality under command line flag? > > We have PauseAtStartup and I think it's better to have similar > PauseAtShutdown than autodetect debugger. I would prefer not to since the beauty is to have the auto-detection do "the right thing". This is functionality you want to use every time you run from Visual Studio. Requiring a separate command line flag kind of defeats the purpose. We could add a flag to turn it off, though. > 2. It's better to create separate function for it. Good point. Should I have a separate function in src/share/vm/runtime/java.cpp, or should I have separate functions in the os classes (to remove the current #ifdef). /Staffan From Dmitry.Samersoff at oracle.com Thu Feb 24 06:40:49 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 24 Feb 2011 17:40:49 +0300 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <9123f709-93f6-472b-a472-bf8a45665b45@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default 4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default> Message-ID: <4D666DF1.1060209@oracle.com> Staffan, Does the method IsDebuggerPresent() distinguish between Visual Studio, windbg, cdbg, adplus and so one? Can we automatically turn this future off when debugging remote JVM or windows service? Can we detect JVM launched by custom launcher (not a java.exe) and turn this future off in this case (custom launcher could have no console)? -Dmitry On 2011-02-24 17:27, Staffan Larsen wrote: >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 24 februari 2011 3:16 >> To: Staffan Larsen >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: Request for review (S): 7022037: Pause when exiting if a >> debugger is attached on windows >> >> Staffan, >> >> 1. Is it possible to put this functionality under command line flag? >> >> We have PauseAtStartup and I think it's better to have similar >> PauseAtShutdown than autodetect debugger. > > I would prefer not to since the beauty is to have the auto-detection do "the right thing". This is functionality you want to use every time you run from Visual Studio. Requiring a separate command line flag kind of defeats the purpose. We could add a flag to turn it off, though. > >> 2. It's better to create separate function for it. > > Good point. Should I have a separate function in src/share/vm/runtime/java.cpp, or should I have separate functions in the os classes (to remove the current #ifdef). > > /Staffan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From staffan.larsen at oracle.com Thu Feb 24 06:49:07 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Feb 2011 06:49:07 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <4D666DF1.1060209@oracle.com> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> Message-ID: <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default> > Does the method IsDebuggerPresent() distinguish between Visual > Studio, > windbg, cdbg, adplus and so one? No, I think it works for all of them. See: http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx > Can we automatically turn this future off when debugging remote JVM > or windows service? I'm not sure how to do that, but I added an option to turn it off manually: -XX:-PauseAtExit > Can we detect JVM launched by custom launcher (not a java.exe) and > turn this future off in this case (custom launcher could have no console)? Don't know how to do that automatically. I'm actually mostly interested in having it turned on for the hotspot.exe launcher. /Staffan From Dmitry.Samersoff at oracle.com Thu Feb 24 06:57:48 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 24 Feb 2011 17:57:48 +0300 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default> Message-ID: <4D6671EC.9060207@oracle.com> Staffan, As far as this future brakes all debug automation scripts over the world and may have unpredictable side effects I would like to have it turned off by default. -Dmitry On 2011-02-24 17:49, Staffan Larsen wrote: >> Does the method IsDebuggerPresent() distinguish between Visual >> Studio, >> windbg, cdbg, adplus and so one? > > No, I think it works for all of them. See: http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx > >> Can we automatically turn this future off when debugging remote JVM >> or windows service? > > I'm not sure how to do that, but I added an option to turn it off manually: -XX:-PauseAtExit > >> Can we detect JVM launched by custom launcher (not a java.exe) and >> turn this future off in this case (custom launcher could have no console)? > > Don't know how to do that automatically. I'm actually mostly interested in having it turned on for the hotspot.exe launcher. > > /Staffan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From staffan.larsen at oracle.com Thu Feb 24 07:25:32 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Feb 2011 07:25:32 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <4D667514.7090901@oracle.com> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> Message-ID: <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default> [resend] ? Right - I see the problem. We've used the same code in JRockit forever, but of course we had the luxury of introducing the flag early and all of our tests were written to be aware of it... ? How about, as others suggested, we enable it only when the hotspot.exe launcher is used? This is the use-case I am interested in, and I don't think any tests would be using it. ? Thanks, /Staffan ? ? From: Daniel D. Daugherty Sent: den 24 februari 2011 4:11 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows ? Trying again since I got a bounce from the Oracle mailer... On 2/24/2011 7:49 AM, Staffan Larsen wrote: Does the method IsDebuggerPresent() distinguish between Visual Studio, windbg, cdbg, adplus and so one? ??? ? No, I think it works for all of them. See: http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx ? ? Can we automatically turn this future off when debugging remote JVM or windows service? ??? ? I'm not sure how to do that, but I added an option to turn it off manually: -XX:-PauseAtExit ? So for tests where we are intentionally causing a crash in order to attach to the crash dump, we will need to add this new option. I'm thinking about SA tests here. More likely we will need: ??? -XX:+IgnoreUnrecognizedVMOptions -XX:-PauseAtExit in order for the tests to work with VMs that don't have the option. Dan ? ? Can we detect JVM launched by custom launcher (not a java.exe) and turn this future off in this case (custom launcher could have no console)? ??? ? Don't know how to do that automatically. I'm actually mostly interested in having it turned on for the hotspot.exe launcher. ? /Staffan ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110224/d253ea84/attachment-0001.html From daniel.daugherty at oracle.com Thu Feb 24 07:27:19 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Feb 2011 08:27:19 -0700 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <79d985b3-e1f4-4907-9330-df664bddd8e7@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <79d985b3-e1f4-4907-9330-df664bddd8e7@default> Message-ID: <4D6678D7.7010308@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110224/2675de60/attachment.html From Dmitry.Samersoff at oracle.com Thu Feb 24 07:40:41 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 24 Feb 2011 18:40:41 +0300 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default> Message-ID: <4D667BF9.1070104@oracle.com> Staffan, On 2011-02-24 18:25, Staffan Larsen wrote: > How about, as others suggested, we enable it only when the hotspot.exe > launcher! is used? This is the use-case I am interested in, and I don't > think any tests would be using it. Sounds OK for me. -Dmitry > > Thanks, > > /Staffan > > *From:*Daniel D. Daugherty > *Sent:* den 24 februari 2011 4:11 > *To:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: Request for review (S): 7022037: Pause when exiting if a > debugger is attached on windows > > Trying again since I got a bounce from the Oracle mailer... > > On 2/24/2011 7:49 AM, Staffan Larsen wrote: > > Does the method IsDebuggerPresent() distinguish between Visual > > Studio, > > windbg, cdbg, adplus and so one? > > > > > > No, I think it works for all of them. See:http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx > > > > > > Can we automatically turn this future off when debugging remote JVM > > or windows service? > > > > > > I'm not sure how to do that, but I added an option to turn it off manually: -XX:-PauseAtExit > > > > > So for tests where we are intentionally causing a crash in order > to attach to the crash dump, we will need to add this new option. > I'm thinking about SA tests here. > > More likely we will need: > > -XX:+IgnoreUnrecognizedVMOptions -XX:-PauseAtExit > > in order for the tests to work with VMs that don't have the option. > > Dan > > > > > > > > Can we detect JVM launched by custom launcher (not a java.exe) and > > turn this future off in this case (custom launcher could have no console)? > > > > > > Don't know how to do that automatically. I'm actually mostly interested in having it turned on for the hotspot.exe launcher. > > > > /Staffan > > > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Thu Feb 24 13:24:22 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Feb 2011 00:24:22 +0300 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D636299.9010603@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> Message-ID: <4D66CC86.70705@oracle.com> [got mailer error for openjdk alias, so resending] Hi Everyone, Here is updated fix: http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ I introduce a new convenience function primary designed to read variety of /proc files. It reads first N characters of line and then skip until eol. Than get_stack_bounds() is changed to use it instead of stdio getline(); -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From David.Holmes at oracle.com Thu Feb 24 14:07:52 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 25 Feb 2011 08:07:52 +1000 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D66CC86.70705@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> Message-ID: <4D66D6B8.6090407@oracle.com> Dmitry, 2662 // Address part of /proc/maps couldn't be more than 128 bytes 2663 while ( os::get_line_chars(fd, buf, 128) > 0) { 2664 if (::strstr(buf, "[stack]") != 0) { 2665 // Extract addresses 2666 *bottom = ::strtoul(buf, &np, 16); 2667 assert(*np == '-', "Should be a dash"); 2668 *top = ::strtoul(np + 1, 0, 16); Don't you need to verify that you actually read data into the parts of the buf you're attempting to convert. The line might be malformed for some reason, or truncated. And why not just keep the sscanf code? David Dmitry Samersoff said the following on 02/25/11 07:24: > [got mailer error for openjdk alias, so resending] > > Hi Everyone, > > Here is updated fix: > > http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ > > I introduce a new convenience function primary designed to read variety > of /proc files. It reads first N characters of line and then skip until > eol. > > Than get_stack_bounds() is changed to use it instead of stdio getline(); > > -Dmitry > From daniel.daugherty at oracle.com Thu Feb 24 14:43:11 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Feb 2011 15:43:11 -0700 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D66CC86.70705@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> Message-ID: <4D66DEFF.3000307@oracle.com> On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: > [got mailer error for openjdk alias, so resending] > > Hi Everyone, > > Here is updated fix: > > http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ src/os/linux/vm/os_linux.cpp line 2662: should be /proc/self/maps line 2663: literal '128' should be 'sizeof(buf)' line 2664: original logic looks for line ending with "[stack]" and your new logic matches a line with "[stack]" anywhere. line 2666: You assume that you got a number here. The original code would have returned false. line 2667: You assert if '-' is not after the first unsigned number translated. The orignal code would have returned false in case of such a mis-format. line 2668: You assume that 'np' is valid here (in product). The original code would have returned false. The second param to the second strtoul() call should be NULL or (char*) NULL. src/share/vm/runtime/os.cpp lines 1296-7 - space after '//' "const" on bsize parameter? line 1300: please consider adding this comment: // read until EOF, EOL or buf is full line 1305: please consider the following comment between lines 1306 and 1307 instead: // EOL reached so ignore EOL character and return lines 1313-4: please consider the following comment between lines 1315 and 1316 instead: // EOF reached. If we read chars before EOF, return them and // return EOF on next call. Otherwise, return EOF. line 1321: please move trailing ";" to next line, e.g.: while( read(fd, &ch, 1) == 1 && ch != '\n' ) /* do nothing */ ; line 1323: please consider this comment instead: // Return initial part of line that fits in buf. // If we reached EOF, it will be returned on next call. src/share/vm/runtime/os.hpp "const" on bsize parameter? Why add blank lines on 725-6? > > I introduce a new convenience function primary designed to read > variety of /proc files. It reads first N characters of line and then > skip until eol. > > Than get_stack_bounds() is changed to use it instead of stdio getline(); > > -Dmitry > From Dmitry.Samersoff at oracle.com Thu Feb 24 23:35:13 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Feb 2011 10:35:13 +0300 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D66DEFF.3000307@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> Message-ID: <4D675BB1.1050006@oracle.com> Dan, Thank you for detailed review. Will change it. -Dmitry On 2011-02-25 01:43, Daniel D. Daugherty wrote: > On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >> [got mailer error for openjdk alias, so resending] >> >> Hi Everyone, >> >> Here is updated fix: >> >> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ > > src/os/linux/vm/os_linux.cpp > line 2662: should be /proc/self/maps > > line 2663: literal '128' should be 'sizeof(buf)' > > line 2664: original logic looks for line ending with "[stack]" > and your new logic matches a line with "[stack]" anywhere. > > line 2666: You assume that you got a number here. The original > code would have returned false. > > line 2667: You assert if '-' is not after the first unsigned > number translated. The orignal code would have returned > false in case of such a mis-format. > > line 2668: You assume that 'np' is valid here (in product). > The original code would have returned false. > The second param to the second strtoul() call should be > NULL or (char*) NULL. > > > src/share/vm/runtime/os.cpp > lines 1296-7 - space after '//' > > "const" on bsize parameter? > > line 1300: please consider adding this comment: > // read until EOF, EOL or buf is full > > line 1305: please consider the following comment between lines > 1306 and 1307 instead: > // EOL reached so ignore EOL character and return > > lines 1313-4: please consider the following comment between lines > 1315 and 1316 instead: > // EOF reached. If we read chars before EOF, return them and > // return EOF on next call. Otherwise, return EOF. > > line 1321: please move trailing ";" to next line, e.g.: > > while( read(fd, &ch, 1) == 1 && ch != '\n' ) > /* do nothing */ ; > > line 1323: please consider this comment instead: > > // Return initial part of line that fits in buf. > // If we reached EOF, it will be returned on next call. > > > src/share/vm/runtime/os.hpp > "const" on bsize parameter? > > Why add blank lines on 725-6? > > >> >> I introduce a new convenience function primary designed to read >> variety of /proc files. It reads first N characters of line and then >> skip until eol. >> >> Than get_stack_bounds() is changed to use it instead of stdio getline(); >> >> -Dmitry >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Thu Feb 24 23:48:27 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Feb 2011 10:48:27 +0300 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D66D6B8.6090407@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66D6B8.6090407@oracle.com> Message-ID: <4D675ECB.6040001@oracle.com> David, I'm strictly against reading /proc entry using stdio functions, as (a) /proc file could be changed while we are reading it (b) it's not fancy as we are buffering kmem. /proc/self/maps has a fixed format and if we have a bad line in a /proc file it would mean that something fatal happens with system, but I'll change assert to "return false" so the code will silently bail out in case of malformed line. -Dmitry On 2011-02-25 01:07, David Holmes wrote: > 2662 // Address part of /proc/maps couldn't be more than 128 bytes > 2663 while ( os::get_line_chars(fd, buf, 128) > 0) { > 2664 if (::strstr(buf, "[stack]") != 0) { > 2665 // Extract addresses > 2666 *bottom = ::strtoul(buf, &np, 16); > 2667 assert(*np == '-', "Should be a dash"); > 2668 *top = ::strtoul(np + 1, 0, 16); > > Don't you need to verify that you actually read data into the parts of > the buf you're attempting to convert. The line might be malformed for > some reason, or truncated. And why not just keep the sscanf code? > > David > > Dmitry Samersoff said the following on 02/25/11 07:24: >> [got mailer error for openjdk alias, so resending] >> >> Hi Everyone, >> >> Here is updated fix: >> >> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >> >> I introduce a new convenience function primary designed to read >> variety of /proc files. It reads first N characters of line and then >> skip until eol. >> >> Than get_stack_bounds() is changed to use it instead of stdio getline(); >> >> -Dmitry >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From staffan.larsen at oracle.com Fri Feb 25 01:12:40 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Feb 2011 01:12:40 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <4D667BF9.1070104@oracle.com> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> Message-ID: <647ce1b4-5bfd-45fb-abb3-b31959354c41@default> Updated webrev: http://cr.openjdk.java.net/~sla/7022037/webrev.03/ Thanks, /Staffan > -----Original Message----- > From: Dmitry Samersoff > Sent: den 24 februari 2011 16:41 > To: Staffan Larsen > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: Request for review (S): 7022037: Pause when exiting if a > debugger is attached on windows > > Staffan, > > On 2011-02-24 18:25, Staffan Larsen wrote: > > How about, as others suggested, we enable it only when the > hotspot.exe > > launcher! is used? This is the use-case I am interested in, and I > don't > > think any tests would be using it. > > Sounds OK for me. > > -Dmitry > > > > > > > > Thanks, > > > > /Staffan > > > > *From:*Daniel D. Daugherty > > *Sent:* den 24 februari 2011 4:11 > > *To:* hotspot-runtime-dev at openjdk.java.net > > *Subject:* Re: Request for review (S): 7022037: Pause when exiting > if a > > debugger is attached on windows > > > > Trying again since I got a bounce from the Oracle mailer... > > > > On 2/24/2011 7:49 AM, Staffan Larsen wrote: > > > > Does the method IsDebuggerPresent() distinguish between Visual > > > > Studio, > > > > windbg, cdbg, adplus and so one? > > > > > > > > > > > > No, I think it works for all of them. > See:http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx > > > > > > > > > > > > Can we automatically turn this future off when debugging remote > JVM > > > > or windows service? > > > > > > > > > > > > I'm not sure how to do that, but I added an option to turn it off > manually: -XX:-PauseAtExit > > > > > > > > > > So for tests where we are intentionally causing a crash in order > > to attach to the crash dump, we will need to add this new option. > > I'm thinking about SA tests here. > > > > More likely we will need: > > > > -XX:+IgnoreUnrecognizedVMOptions -XX:-PauseAtExit > > > > in order for the tests to work with VMs that don't have the option. > > > > Dan > > > > > > > > > > > > > > > > Can we detect JVM launched by custom launcher (not a java.exe) > and > > > > turn this future off in this case (custom launcher could have > no console)? > > > > > > > > > > > > Don't know how to do that automatically. I'm actually mostly > interested in having it turned on for the hotspot.exe launcher. > > > > > > > > /Staffan > > > > > > > > > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From david.holmes at oracle.com Fri Feb 25 02:04:33 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 25 Feb 2011 10:04:33 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7021953: Remove flags from globals.hpp inadvertently dragged in by 7016023 Message-ID: <20110225100434.DFBE647A4B@hg.openjdk.java.net> Changeset: 162b62460264 Author: dholmes Date: 2011-02-24 21:38 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/162b62460264 7021953: Remove flags from globals.hpp inadvertently dragged in by 7016023 Summary: removed erroneous flags Reviewed-by: kvn, dcubed ! src/share/vm/runtime/globals.hpp From David.Holmes at oracle.com Fri Feb 25 03:50:48 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 25 Feb 2011 21:50:48 +1000 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D675ECB.6040001@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66D6B8.6090407@oracle.com> <4D675ECB.6040001@oracle.com> Message-ID: <4D679798.6070102@oracle.com> Dmitry Samersoff said the following on 02/25/11 17:48: > I'm strictly against reading /proc entry using stdio functions, > as (a) /proc file could be changed while we are reading it (b) it's not > fancy as we are buffering kmem. ??? I'm not sure what you are referring to. The sscanf doesn't read the /proc file it parses the buffer you've already read. > /proc/self/maps has a fixed format and if we have a bad line in a /proc > file it would mean that something fatal happens with system, but I'll > change assert to "return false" so the code will silently bail out in > case of malformed line. Ok. But also think about this from the perspective of a tool, like Parfait, analysing this code. David > > -Dmitry > > > On 2011-02-25 01:07, David Holmes wrote: >> 2662 // Address part of /proc/maps couldn't be more than 128 bytes >> 2663 while ( os::get_line_chars(fd, buf, 128) > 0) { >> 2664 if (::strstr(buf, "[stack]") != 0) { >> 2665 // Extract addresses >> 2666 *bottom = ::strtoul(buf, &np, 16); >> 2667 assert(*np == '-', "Should be a dash"); >> 2668 *top = ::strtoul(np + 1, 0, 16); >> >> Don't you need to verify that you actually read data into the parts of >> the buf you're attempting to convert. The line might be malformed for >> some reason, or truncated. And why not just keep the sscanf code? > > > >> >> David >> >> Dmitry Samersoff said the following on 02/25/11 07:24: >>> [got mailer error for openjdk alias, so resending] >>> >>> Hi Everyone, >>> >>> Here is updated fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>> >>> I introduce a new convenience function primary designed to read >>> variety of /proc files. It reads first N characters of line and then >>> skip until eol. >>> >>> Than get_stack_bounds() is changed to use it instead of stdio getline(); >>> >>> -Dmitry >>> > > From Dmitry.Samersoff at oracle.com Fri Feb 25 04:30:02 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Feb 2011 15:30:02 +0300 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D679798.6070102@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66D6B8.6090407@oracle.com> <4D675ECB.6040001@oracle.com> <4D679798.6070102@oracle.com> Message-ID: <4D67A0CA.1070505@oracle.com> On 2011-02-25 14:50, David Holmes wrote: > Dmitry Samersoff said the following on 02/25/11 17:48: >> I'm strictly against reading /proc entry using stdio functions, >> as (a) /proc file could be changed while we are reading it (b) it's >> not fancy as we are buffering kmem. > > ??? I'm not sure what you are referring to. The sscanf doesn't read the > /proc file it parses the buffer you've already read. Opps, sorry, posted to a wrong thread. Yes, we can use sscanf to do the same - it's just a matter of preference. So if you believe sscanf is better than strtoul - I'll change it. >> /proc/self/maps has a fixed format and if we have a bad line in a >> /proc file it would mean that something fatal happens with system, but >> I'll change assert to "return false" so the code will silently bail >> out in case of malformed line. > > Ok. But also think about this from the perspective of a tool, like > Parfait, analysing this code. I have no experience with such tools besides an old lint. I'll check it. -Dmitry > > David > >> >> -Dmitry >> >> >> On 2011-02-25 01:07, David Holmes wrote: >>> 2662 // Address part of /proc/maps couldn't be more than 128 bytes >>> 2663 while ( os::get_line_chars(fd, buf, 128) > 0) { >>> 2664 if (::strstr(buf, "[stack]") != 0) { >>> 2665 // Extract addresses >>> 2666 *bottom = ::strtoul(buf, &np, 16); >>> 2667 assert(*np == '-', "Should be a dash"); >>> 2668 *top = ::strtoul(np + 1, 0, 16); >>> >>> Don't you need to verify that you actually read data into the parts of >>> the buf you're attempting to convert. The line might be malformed for >>> some reason, or truncated. And why not just keep the sscanf code? >> >> >> >>> >>> David >>> >>> Dmitry Samersoff said the following on 02/25/11 07:24: >>>> [got mailer error for openjdk alias, so resending] >>>> >>>> Hi Everyone, >>>> >>>> Here is updated fix: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>>> >>>> I introduce a new convenience function primary designed to read >>>> variety of /proc files. It reads first N characters of line and then >>>> skip until eol. >>>> >>>> Than get_stack_bounds() is changed to use it instead of stdio >>>> getline(); >>>> >>>> -Dmitry >>>> >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Fri Feb 25 04:47:18 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Feb 2011 15:47:18 +0300 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <647ce1b4-5bfd-45fb-abb3-b31959354c41@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default> Message-ID: <4D67A4D6.4020807@oracle.com> Staffan, 1. I think it's better to create the diagnostic flag PauseAtExit with default false and then change this value to true if we run gamma rather than check for gamma launcher every time. 2. I think wait_for_key_press() should be inserted into the all places where vm exists (i.e. where notify_vm_shutdown called) rather than to notify_vm_shutdown. This function (notify_vm_shutdown) has it's own concrete semantic and I would prefer to keep it. 3. May be it's better to use ReadConsoleInput and WaitForSingleObject to address the case where stdin is overloaded/intercepted by ide. Also console function could determine whether console attached or not (i.e. don't try to read from within service) -Dmitry On 2011-02-25 12:12, Staffan Larsen wrote: > Updated webrev: http://cr.openjdk.java.net/~sla/7022037/webrev.03/ > > Thanks, > /Staffan > > > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 24 februari 2011 16:41 >> To: Staffan Larsen >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: Request for review (S): 7022037: Pause when exiting if a >> debugger is attached on windows >> >> Staffan, >> >> On 2011-02-24 18:25, Staffan Larsen wrote: >>> How about, as others suggested, we enable it only when the >> hotspot.exe >>> launcher! is used? This is the use-case I am interested in, and I >> don't >>> think any tests would be using it. >> >> Sounds OK for me. >> >> -Dmitry >> >> >> >> >>> >>> Thanks, >>> >>> /Staffan >>> >>> *From:*Daniel D. Daugherty >>> *Sent:* den 24 februari 2011 4:11 >>> *To:* hotspot-runtime-dev at openjdk.java.net >>> *Subject:* Re: Request for review (S): 7022037: Pause when exiting >> if a >>> debugger is attached on windows >>> >>> Trying again since I got a bounce from the Oracle mailer... >>> >>> On 2/24/2011 7:49 AM, Staffan Larsen wrote: >>> >>> Does the method IsDebuggerPresent() distinguish between Visual >>> >>> Studio, >>> >>> windbg, cdbg, adplus and so one? >>> >>> >>> >>> >>> >>> No, I think it works for all of them. >> See:http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx >>> >>> >>> >>> >>> >>> Can we automatically turn this future off when debugging remote >> JVM >>> >>> or windows service? >>> >>> >>> >>> >>> >>> I'm not sure how to do that, but I added an option to turn it off >> manually: -XX:-PauseAtExit >>> >>> >>> >>> >>> So for tests where we are intentionally causing a crash in order >>> to attach to the crash dump, we will need to add this new option. >>> I'm thinking about SA tests here. >>> >>> More likely we will need: >>> >>> -XX:+IgnoreUnrecognizedVMOptions -XX:-PauseAtExit >>> >>> in order for the tests to work with VMs that don't have the option. >>> >>> Dan >>> >>> >>> >>> >>> >>> >>> >>> Can we detect JVM launched by custom launcher (not a java.exe) >> and >>> >>> turn this future off in this case (custom launcher could have >> no console)? >>> >>> >>> >>> >>> >>> Don't know how to do that automatically. I'm actually mostly >> interested in having it turned on for the hotspot.exe launcher. >>> >>> >>> >>> /Staffan >>> >>> >>> >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From keith.mcguigan at oracle.com Fri Feb 25 05:03:29 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 25 Feb 2011 08:03:29 -0500 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <647ce1b4-5bfd-45fb-abb3-b31959354c41@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default> Message-ID: Hi Staffan -- Can you refactor the code in java.cpp so that we don't have the #ifdef WINDOWS there? Maybe add a method for wait_for_key_press() in the os.hpp interface and implement it separately for windows and posix. Actually if you add a more generic method into os, like 'check_for_debugger_and_wait()', then you can just call this unconditionally (which will simplify the common code) and perform your launcher/flag/debugger check in the body of that method (and just for windows - posix would simply return). Might not even need 'is_debugger_attached' anymore since you could put all the code into os_windows.cpp. -- - Keith On Feb 25, 2011, at 4:12 AM, Staffan Larsen wrote: > Updated webrev: http://cr.openjdk.java.net/~sla/7022037/webrev.03/ > > Thanks, > /Staffan > > > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 24 februari 2011 16:41 >> To: Staffan Larsen >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: Request for review (S): 7022037: Pause when exiting if a >> debugger is attached on windows >> >> Staffan, >> >> On 2011-02-24 18:25, Staffan Larsen wrote: >>> How about, as others suggested, we enable it only when the >> hotspot.exe >>> launcher! is used? This is the use-case I am interested in, and I >> don't >>> think any tests would be using it. >> >> Sounds OK for me. >> >> -Dmitry >> >> >> >> >>> >>> Thanks, >>> >>> /Staffan >>> >>> *From:*Daniel D. Daugherty >>> *Sent:* den 24 februari 2011 4:11 >>> *To:* hotspot-runtime-dev at openjdk.java.net >>> *Subject:* Re: Request for review (S): 7022037: Pause when exiting >> if a >>> debugger is attached on windows >>> >>> Trying again since I got a bounce from the Oracle mailer... >>> >>> On 2/24/2011 7:49 AM, Staffan Larsen wrote: >>> >>> Does the method IsDebuggerPresent() distinguish between Visual >>> >>> Studio, >>> >>> windbg, cdbg, adplus and so one? >>> >>> >>> >>> >>> >>> No, I think it works for all of them. >> See:http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx >>> >>> >>> >>> >>> >>> Can we automatically turn this future off when debugging remote >> JVM >>> >>> or windows service? >>> >>> >>> >>> >>> >>> I'm not sure how to do that, but I added an option to turn it off >> manually: -XX:-PauseAtExit >>> >>> >>> >>> >>> So for tests where we are intentionally causing a crash in order >>> to attach to the crash dump, we will need to add this new option. >>> I'm thinking about SA tests here. >>> >>> More likely we will need: >>> >>> -XX:+IgnoreUnrecognizedVMOptions -XX:-PauseAtExit >>> >>> in order for the tests to work with VMs that don't have the option. >>> >>> Dan >>> >>> >>> >>> >>> >>> >>> >>> Can we detect JVM launched by custom launcher (not a java.exe) >> and >>> >>> turn this future off in this case (custom launcher could have >> no console)? >>> >>> >>> >>> >>> >>> Don't know how to do that automatically. I'm actually mostly >> interested in having it turned on for the hotspot.exe launcher. >>> >>> >>> >>> /Staffan >>> >>> >>> >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... From staffan.larsen at oracle.com Fri Feb 25 05:46:59 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Feb 2011 05:46:59 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <4D67A4D6.4020807@oracle.com> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default 4D67A4D6.4020807@oracle.com> Message-ID: <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default> See below. > -----Original Message----- > From: Dmitry Samersoff > Sent: den 25 februari 2011 13:47 > To: Staffan Larsen > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: Request for review (S): 7022037: Pause when exiting if a > debugger is attached on windows > > Staffan, > > 1. I think it's better to create the diagnostic flag PauseAtExit with > default false and then change this value to true if we run gamma > rather > than check for gamma launcher every time. I can do that. Where would be a good place to do this check? Inside Arguments::process_sun_java_launcher_properties()? > 2. I think wait_for_key_press() should be inserted into the all > places > where vm exists (i.e. where notify_vm_shutdown called) rather than to > notify_vm_shutdown. This function (notify_vm_shutdown) has it's own > concrete semantic and I would prefer to keep it. I can fix that. > 3. May be it's better to use ReadConsoleInput and WaitForSingleObject > to > address the case where stdin is overloaded/intercepted by ide. Also > console function could determine whether console attached or not > (i.e. > don't try to read from within service) How do you determine if a console is attached? AttachConsole and check that error isn't ERROR_INVALID_HANDLE? I haven't used the Windows console API before. /Staffan From Dmitry.Samersoff at oracle.com Fri Feb 25 06:27:57 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Feb 2011 17:27:57 +0300 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default 4D67A4D6.4020807@oracle.com> <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default> Message-ID: <4D67BC6D.6020501@oracle.com> Staffan, On 2011-02-25 16:46, Staffan Larsen wrote: >> 1. I think it's better to create the diagnostic flag PauseAtExit with >> default false and then change this value to true if we run gamma >> rather >> than check for gamma launcher every time. > > I can do that. Where would be a good place to do this check? Inside Arguments::process_sun_java_launcher_properties()? See comment from Keith, I agree with him. >> 3. May be it's better to use ReadConsoleInput and WaitForSingleObject >> to >> address the case where stdin is overloaded/intercepted by ide. Also >> console function could determine whether console attached or not >> (i.e. >> don't try to read from within service) > > How do you determine if a console is attached? AttachConsole and check that error isn't ERROR_INVALID_HANDLE? I haven't used the Windows console API before. If my memory is not bogus GetConsoleMode returns error if console is not attached but it's better to check it. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From staffan.larsen at oracle.com Fri Feb 25 06:47:11 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Feb 2011 06:47:11 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <4D67BC6D.6020501@oracle.com> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default 4D67A4D6.4020807@oracle.com> <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default 4D67BC6D.6020501@oracle.com> Message-ID: <0949dcb4-cf90-4159-9977-51ac23902dd6@default> > Staffan, > > On 2011-02-25 16:46, Staffan Larsen wrote: > >> 1. I think it's better to create the diagnostic flag PauseAtExit > with > >> default false and then change this value to true if we run gamma > >> rather > >> than check for gamma launcher every time. > > > > I can do that. Where would be a good place to do this check? Inside > Arguments::process_sun_java_launcher_properties()? > > See comment from Keith, I agree with him. I didn't see anything about this in Keith's reply. > >> 3. May be it's better to use ReadConsoleInput and > WaitForSingleObject > >> to > >> address the case where stdin is overloaded/intercepted by ide. > Also > >> console function could determine whether console attached or not > >> (i.e. > >> don't try to read from within service) > > > > How do you determine if a console is attached? AttachConsole and > check that error isn't ERROR_INVALID_HANDLE? I haven't used the > Windows console API before. > > If my memory is not bogus GetConsoleMode returns error if console is > not > attached but it's better to check it. Since I will only wait for key press if the gamma launcher is used, and the gamma launcher is a console application, I don't think further checks are necessary. Do you agree? /Staffan From staffan.larsen at oracle.com Fri Feb 25 06:56:58 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Feb 2011 06:56:58 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <0949dcb4-cf90-4159-9977-51ac23902dd6@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default 4D67A4D6.4020807@oracle.com> <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default 4D67BC6D.6020501@oracle.com 0949dcb4-cf90-4159-9977-51ac23902dd6@default> Message-ID: <3c348e7a-7fbe-4b0d-9b6d-c2d8823fbec5@default> And I should have included the latest webrev link: http://cr.openjdk.java.net/~sla/7022037/webrev.04/ /Staffan > -----Original Message----- > From: Staffan Larsen > Sent: den 25 februari 2011 15:47 > To: Dmitriy Samersoff > Cc: Dmitriy Samersoff; hotspot-runtime-dev at openjdk.java.net > Subject: RE: Request for review (S): 7022037: Pause when exiting if a > debugger is attached on windows > > > Staffan, > > > > On 2011-02-25 16:46, Staffan Larsen wrote: > > >> 1. I think it's better to create the diagnostic flag PauseAtExit > > with > > >> default false and then change this value to true if we run gamma > > >> rather > > >> than check for gamma launcher every time. > > > > > > I can do that. Where would be a good place to do this check? > Inside > > Arguments::process_sun_java_launcher_properties()? > > > > See comment from Keith, I agree with him. > > I didn't see anything about this in Keith's reply. > > > >> 3. May be it's better to use ReadConsoleInput and > > WaitForSingleObject > > >> to > > >> address the case where stdin is overloaded/intercepted by ide. > > Also > > >> console function could determine whether console attached or not > > >> (i.e. > > >> don't try to read from within service) > > > > > > How do you determine if a console is attached? AttachConsole and > > check that error isn't ERROR_INVALID_HANDLE? I haven't used the > > Windows console API before. > > > > If my memory is not bogus GetConsoleMode returns error if console > is > > not > > attached but it's better to check it. > > Since I will only wait for key press if the gamma launcher is used, > and the gamma launcher is a console application, I don't think > further checks are necessary. Do you agree? > > /Staffan From keith.mcguigan at oracle.com Fri Feb 25 07:13:41 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 25 Feb 2011 10:13:41 -0500 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <3c348e7a-7fbe-4b0d-9b6d-c2d8823fbec5@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default 4D67A4D6.4020807@oracle.com> <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default 4D67BC6D.6020501@oracle.com 0949dcb4-cf90-4159-9977-51ac23902dd6@default> <3c348e7a-7fbe-4b0d-9b6d-c2d8823fbec5@default> Message-ID: I think that looks better, thanks for making those changes. Two minor issues: (1) os.hpp:496 - you don't need the "os::" prefix here. (2) (and this isn't a big deal) Why go through the work in the arguments code to determine the launcher and store that result rather than just looking at the _sun_java_launcher value at the time that you need it (in check_and_debugger_and_wait())? -- - Keith On Feb 25, 2011, at 9:56 AM, Staffan Larsen wrote: > And I should have included the latest webrev link: http://cr.openjdk.java.net/~sla/7022037/webrev.04/ > > /Staffan > >> -----Original Message----- >> From: Staffan Larsen >> Sent: den 25 februari 2011 15:47 >> To: Dmitriy Samersoff >> Cc: Dmitriy Samersoff; hotspot-runtime-dev at openjdk.java.net >> Subject: RE: Request for review (S): 7022037: Pause when exiting if a >> debugger is attached on windows >> >>> Staffan, >>> >>> On 2011-02-25 16:46, Staffan Larsen wrote: >>>>> 1. I think it's better to create the diagnostic flag PauseAtExit >>> with >>>>> default false and then change this value to true if we run gamma >>>>> rather >>>>> than check for gamma launcher every time. >>>> >>>> I can do that. Where would be a good place to do this check? >> Inside >>> Arguments::process_sun_java_launcher_properties()? >>> >>> See comment from Keith, I agree with him. >> >> I didn't see anything about this in Keith's reply. >> >>>>> 3. May be it's better to use ReadConsoleInput and >>> WaitForSingleObject >>>>> to >>>>> address the case where stdin is overloaded/intercepted by ide. >>> Also >>>>> console function could determine whether console attached or not >>>>> (i.e. >>>>> don't try to read from within service) >>>> >>>> How do you determine if a console is attached? AttachConsole and >>> check that error isn't ERROR_INVALID_HANDLE? I haven't used the >>> Windows console API before. >>> >>> If my memory is not bogus GetConsoleMode returns error if console >> is >>> not >>> attached but it's better to check it. >> >> Since I will only wait for key press if the gamma launcher is used, >> and the gamma launcher is a console application, I don't think >> further checks are necessary. Do you agree? >> >> /Staffan From kelly.ohair at oracle.com Fri Feb 25 09:09:23 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 25 Feb 2011 09:09:23 -0800 Subject: Request for review (S, UPDATED) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D67A0CA.1070505@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66D6B8.6090407@oracle.com> <4D675ECB.6040001@oracle.com> <4D679798.6070102@oracle.com> <4D67A0CA.1070505@oracle.com> Message-ID: <5B99BA7C-2C0A-4B94-BE2F-8AD990BECDB4@oracle.com> Everyone should favor using the string functions that include a length argument. e.g. snprintf over sprintf, strnstr over strstr, strncat over strcat, etc. Static analysis tools will often call these 'potential errors' and adding more occurrences just adds to the pile of errors these tools will create when run over the code. Just an FYI. -kto On Feb 25, 2011, at 4:30 AM, Dmitry Samersoff wrote: > On 2011-02-25 14:50, David Holmes wrote: >> Dmitry Samersoff said the following on 02/25/11 17:48: >>> I'm strictly against reading /proc entry using stdio functions, >>> as (a) /proc file could be changed while we are reading it (b) it's >>> not fancy as we are buffering kmem. >> >> ??? I'm not sure what you are referring to. The sscanf doesn't read >> the >> /proc file it parses the buffer you've already read. > > Opps, sorry, posted to a wrong thread. Yes, we can use sscanf to do > the same - it's just a matter of preference. > > So if you believe sscanf is better than strtoul - I'll change it. > >>> /proc/self/maps has a fixed format and if we have a bad line in a >>> /proc file it would mean that something fatal happens with system, >>> but >>> I'll change assert to "return false" so the code will silently bail >>> out in case of malformed line. >> >> Ok. But also think about this from the perspective of a tool, like >> Parfait, analysing this code. > > I have no experience with such tools besides an old lint. I'll check > it. > > -Dmitry > > >> >> David >> >>> >>> -Dmitry >>> >>> >>> On 2011-02-25 01:07, David Holmes wrote: >>>> 2662 // Address part of /proc/maps couldn't be more than 128 bytes >>>> 2663 while ( os::get_line_chars(fd, buf, 128) > 0) { >>>> 2664 if (::strstr(buf, "[stack]") != 0) { >>>> 2665 // Extract addresses >>>> 2666 *bottom = ::strtoul(buf, &np, 16); >>>> 2667 assert(*np == '-', "Should be a dash"); >>>> 2668 *top = ::strtoul(np + 1, 0, 16); >>>> >>>> Don't you need to verify that you actually read data into the >>>> parts of >>>> the buf you're attempting to convert. The line might be malformed >>>> for >>>> some reason, or truncated. And why not just keep the sscanf code? >>> >>> >>> >>>> >>>> David >>>> >>>> Dmitry Samersoff said the following on 02/25/11 07:24: >>>>> [got mailer error for openjdk alias, so resending] >>>>> >>>>> Hi Everyone, >>>>> >>>>> Here is updated fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>>>> >>>>> I introduce a new convenience function primary designed to read >>>>> variety of /proc files. It reads first N characters of line and >>>>> then >>>>> skip until eol. >>>>> >>>>> Than get_stack_bounds() is changed to use it instead of stdio >>>>> getline(); >>>>> >>>>> -Dmitry >>>>> >>> >>> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From Dmitry.Samersoff at oracle.com Fri Feb 25 10:57:17 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Feb 2011 21:57:17 +0300 Subject: Request for review (S, UPDATED-2) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D66DEFF.3000307@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> Message-ID: <4D67FB8D.2020508@oracle.com> Hi Everyone, Updated webrev: http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.04/ Returned sscanf and addressed other comments. -Dmitry On 2011-02-25 01:43, Daniel D. Daugherty wrote: > On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >> [got mailer error for openjdk alias, so resending] >> >> Hi Everyone, >> >> Here is updated fix: >> >> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ > > src/os/linux/vm/os_linux.cpp > line 2662: should be /proc/self/maps > > line 2663: literal '128' should be 'sizeof(buf)' > > line 2664: original logic looks for line ending with "[stack]" > and your new logic matches a line with "[stack]" anywhere. > > line 2666: You assume that you got a number here. The original > code would have returned false. > > line 2667: You assert if '-' is not after the first unsigned > number translated. The orignal code would have returned > false in case of such a mis-format. > > line 2668: You assume that 'np' is valid here (in product). > The original code would have returned false. > The second param to the second strtoul() call should be > NULL or (char*) NULL. > > > src/share/vm/runtime/os.cpp > lines 1296-7 - space after '//' > > "const" on bsize parameter? > > line 1300: please consider adding this comment: > // read until EOF, EOL or buf is full > > line 1305: please consider the following comment between lines > 1306 and 1307 instead: > // EOL reached so ignore EOL character and return > > lines 1313-4: please consider the following comment between lines > 1315 and 1316 instead: > // EOF reached. If we read chars before EOF, return them and > // return EOF on next call. Otherwise, return EOF. > > line 1321: please move trailing ";" to next line, e.g.: > > while( read(fd, &ch, 1) == 1 && ch != '\n' ) > /* do nothing */ ; > > line 1323: please consider this comment instead: > > // Return initial part of line that fits in buf. > // If we reached EOF, it will be returned on next call. > > > src/share/vm/runtime/os.hpp > "const" on bsize parameter? > > Why add blank lines on 725-6? > > >> >> I introduce a new convenience function primary designed to read >> variety of /proc files. It reads first N characters of line and then >> skip until eol. >> >> Than get_stack_bounds() is changed to use it instead of stdio getline(); >> >> -Dmitry >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Fri Feb 25 12:57:07 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Feb 2011 13:57:07 -0700 Subject: Request for review (S, UPDATED-2) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D67FB8D.2020508@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> <4D67FB8D.2020508@oracle.com> Message-ID: <4D6817A3.304@oracle.com> On 2/25/2011 11:57 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Updated webrev: > > http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.04/ src/os/linux/vm/os_linux.cpp nit on line 2656: add space after ',' nit on line 2666: HotSpot style is 'while ((' src/share/vm/runtime/os.cpp nit on line 1299: add space after ',' nit on line 1302: HotSpot style is 'while ((' nit on line 1302: add spaces around '=' => ' = ' nit on line 1324: HotSpot style is 'while (' src/share/vm/runtime/os.hpp No comments. > > Returned sscanf and addressed other comments. > > -Dmitry > > > > On 2011-02-25 01:43, Daniel D. Daugherty wrote: >> On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >>> [got mailer error for openjdk alias, so resending] >>> >>> Hi Everyone, >>> >>> Here is updated fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >> >> src/os/linux/vm/os_linux.cpp >> line 2662: should be /proc/self/maps >> >> line 2663: literal '128' should be 'sizeof(buf)' >> >> line 2664: original logic looks for line ending with "[stack]" >> and your new logic matches a line with "[stack]" anywhere. >> >> line 2666: You assume that you got a number here. The original >> code would have returned false. >> >> line 2667: You assert if '-' is not after the first unsigned >> number translated. The orignal code would have returned >> false in case of such a mis-format. >> >> line 2668: You assume that 'np' is valid here (in product). >> The original code would have returned false. >> The second param to the second strtoul() call should be >> NULL or (char*) NULL. >> >> >> src/share/vm/runtime/os.cpp >> lines 1296-7 - space after '//' >> >> "const" on bsize parameter? >> >> line 1300: please consider adding this comment: >> // read until EOF, EOL or buf is full >> >> line 1305: please consider the following comment between lines >> 1306 and 1307 instead: >> // EOL reached so ignore EOL character and return >> >> lines 1313-4: please consider the following comment between lines >> 1315 and 1316 instead: >> // EOF reached. If we read chars before EOF, return them and >> // return EOF on next call. Otherwise, return EOF. >> >> line 1321: please move trailing ";" to next line, e.g.: >> >> while( read(fd, &ch, 1) == 1 && ch != '\n' ) >> /* do nothing */ ; >> >> line 1323: please consider this comment instead: >> >> // Return initial part of line that fits in buf. >> // If we reached EOF, it will be returned on next call. >> >> >> src/share/vm/runtime/os.hpp >> "const" on bsize parameter? >> >> Why add blank lines on 725-6? >> >> >>> >>> I introduce a new convenience function primary designed to read >>> variety of /proc files. It reads first N characters of line and then >>> skip until eol. >>> >>> Than get_stack_bounds() is changed to use it instead of stdio >>> getline(); >>> >>> -Dmitry >>> > > From Dmitry.Samersoff at oracle.com Fri Feb 25 14:09:14 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 26 Feb 2011 01:09:14 +0300 Subject: Request for review (S, UPDATED-3) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D6817A3.304@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> <4D67FB8D.2020508@oracle.com> <4D6817A3.304@oracle.com> Message-ID: <4D68288A.3040201@oracle.com> Dan, Updated webrev (spacing changes): http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.05/ -Dmitry On 2011-02-25 23:57, Daniel D. Daugherty wrote: > On 2/25/2011 11:57 AM, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.04/ > > src/os/linux/vm/os_linux.cpp > nit on line 2656: add space after ',' > nit on line 2666: HotSpot style is 'while ((' > > src/share/vm/runtime/os.cpp > nit on line 1299: add space after ',' > nit on line 1302: HotSpot style is 'while ((' > nit on line 1302: add spaces around '=' => ' = ' > nit on line 1324: HotSpot style is 'while (' > > src/share/vm/runtime/os.hpp > No comments. > > >> >> Returned sscanf and addressed other comments. >> >> -Dmitry >> >> >> >> On 2011-02-25 01:43, Daniel D. Daugherty wrote: >>> On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >>>> [got mailer error for openjdk alias, so resending] >>>> >>>> Hi Everyone, >>>> >>>> Here is updated fix: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>> >>> src/os/linux/vm/os_linux.cpp >>> line 2662: should be /proc/self/maps >>> >>> line 2663: literal '128' should be 'sizeof(buf)' >>> >>> line 2664: original logic looks for line ending with "[stack]" >>> and your new logic matches a line with "[stack]" anywhere. >>> >>> line 2666: You assume that you got a number here. The original >>> code would have returned false. >>> >>> line 2667: You assert if '-' is not after the first unsigned >>> number translated. The orignal code would have returned >>> false in case of such a mis-format. >>> >>> line 2668: You assume that 'np' is valid here (in product). >>> The original code would have returned false. >>> The second param to the second strtoul() call should be >>> NULL or (char*) NULL. >>> >>> >>> src/share/vm/runtime/os.cpp >>> lines 1296-7 - space after '//' >>> >>> "const" on bsize parameter? >>> >>> line 1300: please consider adding this comment: >>> // read until EOF, EOL or buf is full >>> >>> line 1305: please consider the following comment between lines >>> 1306 and 1307 instead: >>> // EOL reached so ignore EOL character and return >>> >>> lines 1313-4: please consider the following comment between lines >>> 1315 and 1316 instead: >>> // EOF reached. If we read chars before EOF, return them and >>> // return EOF on next call. Otherwise, return EOF. >>> >>> line 1321: please move trailing ";" to next line, e.g.: >>> >>> while( read(fd, &ch, 1) == 1 && ch != '\n' ) >>> /* do nothing */ ; >>> >>> line 1323: please consider this comment instead: >>> >>> // Return initial part of line that fits in buf. >>> // If we reached EOF, it will be returned on next call. >>> >>> >>> src/share/vm/runtime/os.hpp >>> "const" on bsize parameter? >>> >>> Why add blank lines on 725-6? >>> >>> >>>> >>>> I introduce a new convenience function primary designed to read >>>> variety of /proc files. It reads first N characters of line and then >>>> skip until eol. >>>> >>>> Than get_stack_bounds() is changed to use it instead of stdio >>>> getline(); >>>> >>>> -Dmitry >>>> >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From staffan.larsen at oracle.com Sat Feb 26 02:13:41 2011 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sat, 26 Feb 2011 02:13:41 -0800 (PST) Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default> <4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default> <4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default> <4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default> <4D67A4D6.4020807@oracle.com> <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default> <4D67BC6D.6020501@oracle.com> <0949dcb4-cf90-4159-9977-51ac23902dd6@default> <3c348e7a-7fbe-4b0d-9b6d-c2d8823fbec5@default D3BFB8DB-0C7C-498C-9FEA-4FD78569DC4D@oracle.com> Message-ID: <9101de4f-8e5f-4d55-b080-995947eb5bff@default> > -----Original Message----- > From: Keith McGuigan > Sent: den 25 februari 2011 16:14 > To: Staffan Larsen > Cc: Dmitriy Samersoff; hotspot-runtime-dev at openjdk.java.net > Subject: Re: Request for review (S): 7022037: Pause when exiting if a > debugger is attached on windows > > > I think that looks better, thanks for making those changes. Two > minor > issues: > > (1) os.hpp:496 - you don't need the "os::" prefix here. Doh. Copy-paste-error. > (2) (and this isn't a big deal) Why go through the work in the > arguments code to determine the launcher and store that result rather > than just looking at the _sun_java_launcher value at the time that > you > need it (in check_and_debugger_and_wait())? I just wanted to have the code in one place. Arguments::created_by_gamma_launcher() is currently called from three different places. /Staffan From John.Coomes at oracle.com Sun Feb 27 01:13:48 2011 From: John.Coomes at oracle.com (John Coomes) Date: Sun, 27 Feb 2011 01:13:48 -0800 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: References: <19804.4627.94089.715688@oracle.com> <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> <4D5C179F.2080300@oracle.com> Message-ID: <19818.5580.989646.393278@oracle.com> Tom Rodriguez (tom.rodriguez at oracle.com) wrote: > Oops. That line should be deleted too, along with the declaration of stringTableSize in StringTable.java. Thanks. I fixed that and some other nits and updated the webrev at the same location: http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ -John > On Feb 16, 2011, at 10:29 AM, Paul Hohensee wrote: > > > It does. See agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java. > > > > stringTableSize = db.lookupIntConstant("StringTable::string_table_size").intValue(); > > > > Paul > > > > On 2/16/11 1:15 PM, Keith McGuigan wrote: > >> > >> Looks good. Nothing in the SA agent was calling getStringTableSize()? > >> > >> On Feb 16, 2011, at 1:06 PM, John Coomes wrote: > >> > >>> I'd appreciate reviews of a small change to allow the string table > >>> size to be set on the command line: > >>> > >>> http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ > >>> > >>> -John > >>> > >> > From John.Coomes at oracle.com Sun Feb 27 01:15:26 2011 From: John.Coomes at oracle.com (John Coomes) Date: Sun, 27 Feb 2011 01:15:26 -0800 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: <4D5C179F.2080300@oracle.com> References: <19804.4627.94089.715688@oracle.com> <477077D3-343C-4B6B-9993-196E3FCB98AD@oracle.com> <4D5C179F.2080300@oracle.com> Message-ID: <19818.5678.27677.298421@oracle.com> Paul Hohensee (paul.hohensee at oracle.com) wrote: > It does. See > agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java. > > stringTableSize = > db.lookupIntConstant("StringTable::string_table_size").intValue(); Thanks Keith and Paul. I updated the webrev at the same location. -John > On 2/16/11 1:15 PM, Keith McGuigan wrote: > > > > Looks good. Nothing in the SA agent was calling getStringTableSize()? > > > > On Feb 16, 2011, at 1:06 PM, John Coomes wrote: > > > >> I'd appreciate reviews of a small change to allow the string table > >> size to be set on the command line: > >> > >> http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ > >> > >> -John > >> > > From John.Coomes at oracle.com Sun Feb 27 01:17:41 2011 From: John.Coomes at oracle.com (John Coomes) Date: Sun, 27 Feb 2011 01:17:41 -0800 Subject: review request (S): 6962930 make the string table size configurable In-Reply-To: <4D5C74D1.1040902@oracle.com> References: <19804.4627.94089.715688@oracle.com> <4D5C74D1.1040902@oracle.com> Message-ID: <19818.5813.759794.703682@oracle.com> David Holmes (David.Holmes at oracle.com) wrote: > Can clarify in globals.hpp whether the size is in bytes, KB, MB. Thanks for taking a look. It's the number of buckets; I included that info in the doc string and updated the webrev (same location). -John > John Coomes said the following on 02/17/11 04:06: > > I'd appreciate reviews of a small change to allow the string table > > size to be set on the command line: > > > > http://cr.openjdk.java.net/~jcoomes/6962930-str-tbl-sz/ > > > > -John > > From keith.mcguigan at oracle.com Sun Feb 27 02:30:21 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Sun, 27 Feb 2011 10:30:21 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7017640: Fix for 6766644 deadlocks on some NSK tests when running with -Xcomp Message-ID: <20110227103043.763D847ACB@hg.openjdk.java.net> Changeset: f91db74a6810 Author: kamg Date: 2011-02-26 13:33 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f91db74a6810 7017640: Fix for 6766644 deadlocks on some NSK tests when running with -Xcomp Summary: Dynamic-code generated events should be deferred and processed by service thread Reviewed-by: dsamersoff, dcubed ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp From David.Holmes at oracle.com Sun Feb 27 15:02:54 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 28 Feb 2011 09:02:54 +1000 Subject: Request for review (S, UPDATED-3) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D68288A.3040201@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> <4D67FB8D.2020508@oracle.com> <4D6817A3.304@oracle.com> <4D68288A.3040201@oracle.com> Message-ID: <4D6AD81E.7080001@oracle.com> Seems okay to me. David Dmitry Samersoff said the following on 02/26/11 08:09: > Dan, > > Updated webrev (spacing changes): > > http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.05/ > > -Dmitry > > > > On 2011-02-25 23:57, Daniel D. Daugherty wrote: >> On 2/25/2011 11:57 AM, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.04/ >> >> src/os/linux/vm/os_linux.cpp >> nit on line 2656: add space after ',' >> nit on line 2666: HotSpot style is 'while ((' >> >> src/share/vm/runtime/os.cpp >> nit on line 1299: add space after ',' >> nit on line 1302: HotSpot style is 'while ((' >> nit on line 1302: add spaces around '=' => ' = ' >> nit on line 1324: HotSpot style is 'while (' >> >> src/share/vm/runtime/os.hpp >> No comments. >> >> >>> >>> Returned sscanf and addressed other comments. >>> >>> -Dmitry >>> >>> >>> >>> On 2011-02-25 01:43, Daniel D. Daugherty wrote: >>>> On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >>>>> [got mailer error for openjdk alias, so resending] >>>>> >>>>> Hi Everyone, >>>>> >>>>> Here is updated fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>>> >>>> src/os/linux/vm/os_linux.cpp >>>> line 2662: should be /proc/self/maps >>>> >>>> line 2663: literal '128' should be 'sizeof(buf)' >>>> >>>> line 2664: original logic looks for line ending with "[stack]" >>>> and your new logic matches a line with "[stack]" anywhere. >>>> >>>> line 2666: You assume that you got a number here. The original >>>> code would have returned false. >>>> >>>> line 2667: You assert if '-' is not after the first unsigned >>>> number translated. The orignal code would have returned >>>> false in case of such a mis-format. >>>> >>>> line 2668: You assume that 'np' is valid here (in product). >>>> The original code would have returned false. >>>> The second param to the second strtoul() call should be >>>> NULL or (char*) NULL. >>>> >>>> >>>> src/share/vm/runtime/os.cpp >>>> lines 1296-7 - space after '//' >>>> >>>> "const" on bsize parameter? >>>> >>>> line 1300: please consider adding this comment: >>>> // read until EOF, EOL or buf is full >>>> >>>> line 1305: please consider the following comment between lines >>>> 1306 and 1307 instead: >>>> // EOL reached so ignore EOL character and return >>>> >>>> lines 1313-4: please consider the following comment between lines >>>> 1315 and 1316 instead: >>>> // EOF reached. If we read chars before EOF, return them and >>>> // return EOF on next call. Otherwise, return EOF. >>>> >>>> line 1321: please move trailing ";" to next line, e.g.: >>>> >>>> while( read(fd, &ch, 1) == 1 && ch != '\n' ) >>>> /* do nothing */ ; >>>> >>>> line 1323: please consider this comment instead: >>>> >>>> // Return initial part of line that fits in buf. >>>> // If we reached EOF, it will be returned on next call. >>>> >>>> >>>> src/share/vm/runtime/os.hpp >>>> "const" on bsize parameter? >>>> >>>> Why add blank lines on 725-6? >>>> >>>> >>>>> >>>>> I introduce a new convenience function primary designed to read >>>>> variety of /proc files. It reads first N characters of line and then >>>>> skip until eol. >>>>> >>>>> Than get_stack_bounds() is changed to use it instead of stdio >>>>> getline(); >>>>> >>>>> -Dmitry >>>>> >>> >>> > > From poonam.bajaj at oracle.com Sun Feb 27 22:38:53 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Mon, 28 Feb 2011 12:08:53 +0530 Subject: Request for review (S, UPDATED-3) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D68288A.3040201@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> <4D67FB8D.2020508@oracle.com> <4D6817A3.304@oracle.com> <4D68288A.3040201@oracle.com> Message-ID: <4D6B42FD.5020303@oracle.com> Looks good to me. One small suggestion, the variable name of '[stack]' string and its length could be made more reader friendly such as its old name 'stack_str'. Thanks, Poonam On 2/26/2011 3:39 AM, Dmitry Samersoff wrote: > Dan, > > Updated webrev (spacing changes): > > http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.05/ > > -Dmitry > > > > On 2011-02-25 23:57, Daniel D. Daugherty wrote: >> On 2/25/2011 11:57 AM, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.04/ >> >> src/os/linux/vm/os_linux.cpp >> nit on line 2656: add space after ',' >> nit on line 2666: HotSpot style is 'while ((' >> >> src/share/vm/runtime/os.cpp >> nit on line 1299: add space after ',' >> nit on line 1302: HotSpot style is 'while ((' >> nit on line 1302: add spaces around '=' => ' = ' >> nit on line 1324: HotSpot style is 'while (' >> >> src/share/vm/runtime/os.hpp >> No comments. >> >> >>> >>> Returned sscanf and addressed other comments. >>> >>> -Dmitry >>> >>> >>> >>> On 2011-02-25 01:43, Daniel D. Daugherty wrote: >>>> On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >>>>> [got mailer error for openjdk alias, so resending] >>>>> >>>>> Hi Everyone, >>>>> >>>>> Here is updated fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>>> >>>> src/os/linux/vm/os_linux.cpp >>>> line 2662: should be /proc/self/maps >>>> >>>> line 2663: literal '128' should be 'sizeof(buf)' >>>> >>>> line 2664: original logic looks for line ending with "[stack]" >>>> and your new logic matches a line with "[stack]" anywhere. >>>> >>>> line 2666: You assume that you got a number here. The original >>>> code would have returned false. >>>> >>>> line 2667: You assert if '-' is not after the first unsigned >>>> number translated. The orignal code would have returned >>>> false in case of such a mis-format. >>>> >>>> line 2668: You assume that 'np' is valid here (in product). >>>> The original code would have returned false. >>>> The second param to the second strtoul() call should be >>>> NULL or (char*) NULL. >>>> >>>> >>>> src/share/vm/runtime/os.cpp >>>> lines 1296-7 - space after '//' >>>> >>>> "const" on bsize parameter? >>>> >>>> line 1300: please consider adding this comment: >>>> // read until EOF, EOL or buf is full >>>> >>>> line 1305: please consider the following comment between lines >>>> 1306 and 1307 instead: >>>> // EOL reached so ignore EOL character and return >>>> >>>> lines 1313-4: please consider the following comment between lines >>>> 1315 and 1316 instead: >>>> // EOF reached. If we read chars before EOF, return them and >>>> // return EOF on next call. Otherwise, return EOF. >>>> >>>> line 1321: please move trailing ";" to next line, e.g.: >>>> >>>> while( read(fd, &ch, 1) == 1 && ch != '\n' ) >>>> /* do nothing */ ; >>>> >>>> line 1323: please consider this comment instead: >>>> >>>> // Return initial part of line that fits in buf. >>>> // If we reached EOF, it will be returned on next call. >>>> >>>> >>>> src/share/vm/runtime/os.hpp >>>> "const" on bsize parameter? >>>> >>>> Why add blank lines on 725-6? >>>> >>>> >>>>> >>>>> I introduce a new convenience function primary designed to read >>>>> variety of /proc files. It reads first N characters of line and then >>>>> skip until eol. >>>>> >>>>> Than get_stack_bounds() is changed to use it instead of stdio >>>>> getline(); >>>>> >>>>> -Dmitry >>>>> >>> >>> > > -- Best regards, Poonam Sun, an Oracle company Sun, an Oracle Company Poonam Bajaj | Staff Engineer Phone: +66937451 | Mobile: +9844511366 JVM Sustaining Engineering | Bangalore Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110228/dd9acc8a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: sun-oracle-logo.gif Type: image/gif Size: 2088 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110228/dd9acc8a/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110228/dd9acc8a/attachment-0001.gif From christian.thalinger at oracle.com Mon Feb 28 04:20:32 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Feb 2011 13:20:32 +0100 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <3c348e7a-7fbe-4b0d-9b6d-c2d8823fbec5@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default> <4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default 4D666DF1.1060209@oracle.com> <1cb49e2b-ccbe-4e88-9407-83e6e463f50a@default 4D667514.7090901@oracle.com> <5cdbfc3f-5a21-4777-a190-831f8ad9e276@default 4D667BF9.1070104@oracle.com> <647ce1b4-5bfd-45fb-abb3-b31959354c41@default 4D67A4D6.4020807@oracle.com> <54e78187-d1bb-4274-a4bc-35aff0a0fb2d@default 4D67BC6D.6020501@oracle.com 0949dcb4-cf90-4159-9977-51ac23902dd6@default> <3c348e7a-7fbe-4b0d-9b6d-c2d8823fbec5@default> Message-ID: <74414631-9113-467A-BCE9-B9774D784A50@oracle.com> On Feb 25, 2011, at 3:56 PM, Staffan Larsen wrote: > And I should have included the latest webrev link: http://cr.openjdk.java.net/~sla/7022037/webrev.04/ src/os/posix/vm/os_posix.cpp: +bool os::is_debugger_present() { I suppose this is a typo and should be: +bool os::is_debugger_attached() { -- Christian From coleen.phillimore at oracle.com Mon Feb 28 08:07:48 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Feb 2011 11:07:48 -0500 Subject: Request for review (S, UPDATED-3) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D68288A.3040201@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> <4D67FB8D.2020508@oracle.com> <4D6817A3.304@oracle.com> <4D68288A.3040201@oracle.com> Message-ID: <4D6BC854.4060404@oracle.com> Dmitry, This looks good to me. Only one question, can the [stack] line be 128 characters and that includes the 128th as the newline and/or null terminating char, or do you need 129 to return a null terminated string? thanks, Coleen On 2/25/2011 5:09 PM, Dmitry Samersoff wrote: > Dan, > > Updated webrev (spacing changes): > > http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.05/ > > -Dmitry > > > > On 2011-02-25 23:57, Daniel D. Daugherty wrote: >> On 2/25/2011 11:57 AM, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.04/ >> >> src/os/linux/vm/os_linux.cpp >> nit on line 2656: add space after ',' >> nit on line 2666: HotSpot style is 'while ((' >> >> src/share/vm/runtime/os.cpp >> nit on line 1299: add space after ',' >> nit on line 1302: HotSpot style is 'while ((' >> nit on line 1302: add spaces around '=' => ' = ' >> nit on line 1324: HotSpot style is 'while (' >> >> src/share/vm/runtime/os.hpp >> No comments. >> >> >>> >>> Returned sscanf and addressed other comments. >>> >>> -Dmitry >>> >>> >>> >>> On 2011-02-25 01:43, Daniel D. Daugherty wrote: >>>> On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >>>>> [got mailer error for openjdk alias, so resending] >>>>> >>>>> Hi Everyone, >>>>> >>>>> Here is updated fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>>> >>>> src/os/linux/vm/os_linux.cpp >>>> line 2662: should be /proc/self/maps >>>> >>>> line 2663: literal '128' should be 'sizeof(buf)' >>>> >>>> line 2664: original logic looks for line ending with "[stack]" >>>> and your new logic matches a line with "[stack]" anywhere. >>>> >>>> line 2666: You assume that you got a number here. The original >>>> code would have returned false. >>>> >>>> line 2667: You assert if '-' is not after the first unsigned >>>> number translated. The orignal code would have returned >>>> false in case of such a mis-format. >>>> >>>> line 2668: You assume that 'np' is valid here (in product). >>>> The original code would have returned false. >>>> The second param to the second strtoul() call should be >>>> NULL or (char*) NULL. >>>> >>>> >>>> src/share/vm/runtime/os.cpp >>>> lines 1296-7 - space after '//' >>>> >>>> "const" on bsize parameter? >>>> >>>> line 1300: please consider adding this comment: >>>> // read until EOF, EOL or buf is full >>>> >>>> line 1305: please consider the following comment between lines >>>> 1306 and 1307 instead: >>>> // EOL reached so ignore EOL character and return >>>> >>>> lines 1313-4: please consider the following comment between lines >>>> 1315 and 1316 instead: >>>> // EOF reached. If we read chars before EOF, return them and >>>> // return EOF on next call. Otherwise, return EOF. >>>> >>>> line 1321: please move trailing ";" to next line, e.g.: >>>> >>>> while( read(fd, &ch, 1) == 1 && ch != '\n' ) >>>> /* do nothing */ ; >>>> >>>> line 1323: please consider this comment instead: >>>> >>>> // Return initial part of line that fits in buf. >>>> // If we reached EOF, it will be returned on next call. >>>> >>>> >>>> src/share/vm/runtime/os.hpp >>>> "const" on bsize parameter? >>>> >>>> Why add blank lines on 725-6? >>>> >>>> >>>>> >>>>> I introduce a new convenience function primary designed to read >>>>> variety of /proc files. It reads first N characters of line and then >>>>> skip until eol. >>>>> >>>>> Than get_stack_bounds() is changed to use it instead of stdio >>>>> getline(); >>>>> >>>>> -Dmitry >>>>> >>> >>> > > From Dmitry.Samersoff at oracle.com Mon Feb 28 08:53:45 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 28 Feb 2011 19:53:45 +0300 Subject: Request for review (S, UPDATED-3) 7017193: Small memory leak in get_stack_bounds // os::create_stack_guard_pages In-Reply-To: <4D6BC854.4060404@oracle.com> References: <4D6258AB.3090802@oracle.com> <4D636299.9010603@oracle.com> <4D66CC86.70705@oracle.com> <4D66DEFF.3000307@oracle.com> <4D67FB8D.2020508@oracle.com> <4D6817A3.304@oracle.com> <4D68288A.3040201@oracle.com> <4D6BC854.4060404@oracle.com> Message-ID: <4D6BD319.5090100@oracle.com> Coleen, Thank you! I'm going to commit changes. Longest possible address line (on x86_64bit) is 103 bytes long (see below), so 128 bytes gives us enough reserve. -Dmitry e.g.: ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] On 2011-02-28 19:07, Coleen Phillimore wrote: > Dmitry, > This looks good to me. Only one question, can the [stack] line be 128 > characters and that includes the 128th as the newline and/or null > terminating char, or do you need 129 to return a null terminated string? > > thanks, > Coleen > > On 2/25/2011 5:09 PM, Dmitry Samersoff wrote: >> Dan, >> >> Updated webrev (spacing changes): >> >> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.05/ >> >> -Dmitry >> >> >> >> On 2011-02-25 23:57, Daniel D. Daugherty wrote: >>> On 2/25/2011 11:57 AM, Dmitry Samersoff wrote: >>>> Hi Everyone, >>>> >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.04/ >>> >>> src/os/linux/vm/os_linux.cpp >>> nit on line 2656: add space after ',' >>> nit on line 2666: HotSpot style is 'while ((' >>> >>> src/share/vm/runtime/os.cpp >>> nit on line 1299: add space after ',' >>> nit on line 1302: HotSpot style is 'while ((' >>> nit on line 1302: add spaces around '=' => ' = ' >>> nit on line 1324: HotSpot style is 'while (' >>> >>> src/share/vm/runtime/os.hpp >>> No comments. >>> >>> >>>> >>>> Returned sscanf and addressed other comments. >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> On 2011-02-25 01:43, Daniel D. Daugherty wrote: >>>>> On 2/24/2011 2:24 PM, Dmitry Samersoff wrote: >>>>>> [got mailer error for openjdk alias, so resending] >>>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> Here is updated fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/7017193/webrev.03/ >>>>> >>>>> src/os/linux/vm/os_linux.cpp >>>>> line 2662: should be /proc/self/maps >>>>> >>>>> line 2663: literal '128' should be 'sizeof(buf)' >>>>> >>>>> line 2664: original logic looks for line ending with "[stack]" >>>>> and your new logic matches a line with "[stack]" anywhere. >>>>> >>>>> line 2666: You assume that you got a number here. The original >>>>> code would have returned false. >>>>> >>>>> line 2667: You assert if '-' is not after the first unsigned >>>>> number translated. The orignal code would have returned >>>>> false in case of such a mis-format. >>>>> >>>>> line 2668: You assume that 'np' is valid here (in product). >>>>> The original code would have returned false. >>>>> The second param to the second strtoul() call should be >>>>> NULL or (char*) NULL. >>>>> >>>>> >>>>> src/share/vm/runtime/os.cpp >>>>> lines 1296-7 - space after '//' >>>>> >>>>> "const" on bsize parameter? >>>>> >>>>> line 1300: please consider adding this comment: >>>>> // read until EOF, EOL or buf is full >>>>> >>>>> line 1305: please consider the following comment between lines >>>>> 1306 and 1307 instead: >>>>> // EOL reached so ignore EOL character and return >>>>> >>>>> lines 1313-4: please consider the following comment between lines >>>>> 1315 and 1316 instead: >>>>> // EOF reached. If we read chars before EOF, return them and >>>>> // return EOF on next call. Otherwise, return EOF. >>>>> >>>>> line 1321: please move trailing ";" to next line, e.g.: >>>>> >>>>> while( read(fd, &ch, 1) == 1 && ch != '\n' ) >>>>> /* do nothing */ ; >>>>> >>>>> line 1323: please consider this comment instead: >>>>> >>>>> // Return initial part of line that fits in buf. >>>>> // If we reached EOF, it will be returned on next call. >>>>> >>>>> >>>>> src/share/vm/runtime/os.hpp >>>>> "const" on bsize parameter? >>>>> >>>>> Why add blank lines on 725-6? >>>>> >>>>> >>>>>> >>>>>> I introduce a new convenience function primary designed to read >>>>>> variety of /proc files. It reads first N characters of line and then >>>>>> skip until eol. >>>>>> >>>>>> Than get_stack_bounds() is changed to use it instead of stdio >>>>>> getline(); >>>>>> >>>>>> -Dmitry >>>>>> >>>> >>>> >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From staffan.larsen at oracle.com Mon Feb 28 10:06:28 2011 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 28 Feb 2011 18:06:28 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7022037: Pause when exiting if debugger is attached on windows Message-ID: <20110228180632.09CC947B1B@hg.openjdk.java.net> Changeset: da091bb67459 Author: sla Date: 2011-02-28 14:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/da091bb67459 7022037: Pause when exiting if debugger is attached on windows Reviewed-by: dsamersoff, kamg, hosterda ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp From coleen.phillimore at oracle.com Mon Feb 28 10:19:35 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Feb 2011 13:19:35 -0500 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <9123f709-93f6-472b-a472-bf8a45665b45@default> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default 4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default> Message-ID: <4D6BE737.3020907@oracle.com> Staffan, In os/posix/vm/os_posix.cpp the function is named is_debugger_present() rather than is_debugger_attached(). You've probably already found this out. Why can't you just enable this by default if someone has ShowMessageBoxOnError rather than adding a new option? The two seem compatible to me. Coleen On 2/24/2011 9:27 AM, Staffan Larsen wrote: >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 24 februari 2011 3:16 >> To: Staffan Larsen >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: Request for review (S): 7022037: Pause when exiting if a >> debugger is attached on windows >> >> Staffan, >> >> 1. Is it possible to put this functionality under command line flag? >> >> We have PauseAtStartup and I think it's better to have similar >> PauseAtShutdown than autodetect debugger. > I would prefer not to since the beauty is to have the auto-detection do "the right thing". This is functionality you want to use every time you run from Visual Studio. Requiring a separate command line flag kind of defeats the purpose. We could add a flag to turn it off, though. > >> 2. It's better to create separate function for it. > Good point. Should I have a separate function in src/share/vm/runtime/java.cpp, or should I have separate functions in the os classes (to remove the current #ifdef). > > /Staffan From coleen.phillimore at oracle.com Mon Feb 28 10:28:24 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Feb 2011 13:28:24 -0500 Subject: Request for review (S): 7022037: Pause when exiting if a debugger is attached on windows In-Reply-To: <4D6BE737.3020907@oracle.com> References: <068814b2-17aa-425c-ad71-e3732238ffbc@default 4D666822.5030706@oracle.com> <9123f709-93f6-472b-a472-bf8a45665b45@default> <4D6BE737.3020907@oracle.com> Message-ID: <4D6BE948.7010205@oracle.com> Never mind. I'm not quite caught up with reading email. Coleen On 2/28/2011 1:19 PM, Coleen Phillimore wrote: > > Staffan, > In os/posix/vm/os_posix.cpp the function is named > is_debugger_present() rather than is_debugger_attached(). You've > probably already found this out. > > Why can't you just enable this by default if someone has > ShowMessageBoxOnError rather than adding a new option? The two seem > compatible to me. > > Coleen > > On 2/24/2011 9:27 AM, Staffan Larsen wrote: >>> -----Original Message----- >>> From: Dmitry Samersoff >>> Sent: den 24 februari 2011 3:16 >>> To: Staffan Larsen >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: Request for review (S): 7022037: Pause when exiting if a >>> debugger is attached on windows >>> >>> Staffan, >>> >>> 1. Is it possible to put this functionality under command line flag? >>> >>> We have PauseAtStartup and I think it's better to have similar >>> PauseAtShutdown than autodetect debugger. >> I would prefer not to since the beauty is to have the auto-detection >> do "the right thing". This is functionality you want to use every >> time you run from Visual Studio. Requiring a separate command line >> flag kind of defeats the purpose. We could add a flag to turn it off, >> though. >> >>> 2. It's better to create separate function for it. >> Good point. Should I have a separate function in >> src/share/vm/runtime/java.cpp, or should I have separate functions in >> the os classes (to remove the current #ifdef). >> >> /Staffan > From keith.mcguigan at oracle.com Mon Feb 28 20:28:48 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Tue, 01 Mar 2011 04:28:48 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7020118: Alter frame assignability to allow for exception handler coverage of invokespecial Message-ID: <20110301042850.3809047B5B@hg.openjdk.java.net> Changeset: c1a6154012c8 Author: kamg Date: 2011-02-28 16:01 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c1a6154012c8 7020118: Alter frame assignability to allow for exception handler coverage of invokespecial Summary: Add special rule to allow assignment of frames with uninit flags set. Reviewed-by: never, coleenp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/verificationType.hpp