From david.holmes at oracle.com Mon Mar 2 08:27:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 18:27:03 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F0E791.8020409@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> Message-ID: <54F41ED7.2070208@oracle.com> On 28/02/2015 7:54 AM, Daniel D. Daugherty wrote: > Coleen and David, > > My final attempt to get more acceptable wording for this comment: > > Here's the current wording: > > + // The WatcherThread is not a JavaThread so we do not honor the > + // safepoint protocol for the PeriodicTask_lock. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > How about: > > + // The WatcherThread does not participate in the safepoint protocol > + // for the PeriodicTask_lock because it is not a JavaThread. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > This change would be made in task.cpp: PeriodicTask::real_time_tick() > and thread.cpp: WatcherThread::sleep(). > > Is this acceptable? Fine by me. Thanks, David > Dan > > > On 2/27/15 1:36 PM, Coleen Phillimore wrote: >> >> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>> Coleen, >>> >>> Thanks for the review. Replies embedded below. >>> >>> David, >>> >>> Thanks for jumping in while I was out of the office yesterday. >>> >>> >>> On 2/26/15 12:13 AM, David Holmes wrote: >>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>> >>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>> couple of questions. >>>>>>> >>>>>>> in >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> This comment is really confusing because I think you do in fact >>>>>>> honor >>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>> >>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>> WatcherThread will sometimes acquire locks that potentially check the >>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>> actually taken. Hence we can call the code that will never consider >>>>>> taking them if the only caller of that code (as in this case) is a >>>>>> non-JavaThread. >>>>> >>>>> So you could theoretically have the watcher thread use the regular >>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>> scenes, the safepoint check is elided. >>>> >>>> Yes, internally there is one path for JavaThreads and a different >>>> path for non-JavaThreads. JavaThreads perform thread-state >>>> transitions which form part of the safepoint protocol. >>> >>> So it looks like "honor the safepoint protocol" is bad choice of >>> words. More below. >>> >>> Earlier in this thread, Marcus talked about switching from >>> MutexLockerEx -> MutexLocker and the problem that he ran into >>> with the wait() function. He's planning to explore this idea >>> further using a different bug ID in order to clean up this >>> wart. >>> >>> >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); >> Your explanation makes sense. To be honest, I'm not sure how to >> reword it so it makes more sense, other than to add that the safepoint >> check isn't made anyway for !JavaThreads. >> >> Coleen >>>> >>>>> So the comment really doesn't explain what's going on, and leads >>>>> one to >>>>> believe that you need to be careful _not_ to take a safepoint check >>>>> with >>>>> the Watcher thread. >>>> >>>> I don't read it that way but would it be better if it said "do not >>>> _need to_ honor" instead? >>> >>> Perhaps "does not participate in the safepoint protocol" is >>> better and more clear? >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>> I'll stop reading comments again. >>> >>> Please don't. I'm trying to make the comments more clear in an >>> area that is a bit messy. If the comments don't make sense to >>> you, then I need to fix that. >>> >>> >>>>> >>>>> Thanks for the explanation though, the latter part I knew about. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>> honor >>>>>>> the >>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>> >>>>>>> >>>>>>> Because WatcherThread::stop() does safepoint check. >>> >>> WatcherThread::stop() does a safepoint check because it is >>> called by a JavaThread instead of the WatcherThread. I added >>> a new comment that was supposed to make this clear. Is the >>> comment in thread.cpp not clear? >>> >>> >>>>>>> It's unclear >>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>> also. >>>>>>> If so, should they have no_safepoint_check. >>> >>> That's true. It is not clear that the WatcherThread does not call >>> enroll() or disenroll() and I didn't add an assert for this one. >>> As David pointed out earlier in this review thread, the API for >>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>> but we agreed that should be done via another bug ID that is >>> focused on just API cleanup. >>> >>> >>>>>> >>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>> never want to check for safepoints. If the only caller is a >>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>> JavaThread then safepoint checking can only be elided under very >>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>> enrol/disenrol then we should check for safepoints (as the conditions >>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>> methods). >>>>>> >>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>> nervous, but >>>>>>> the comment seems misleading. >>>>>> >>>>>> Hope it is clearer now. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> I honestly don't know enough about the rest to review it. >>> >>> Thanks for taking a look at it anyway. >>> >>> Dan >>> >>> >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>> This should be the last webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>> >>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >>>>>>>> to hear from you in this hopefully final round... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, here is the bug's URL: >>>>>>>>> >>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>> >>>>>>>>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>> direct >>>>>>>>> Aurora Adhoc jobs... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> My fix for the following bug: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>> >>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>> >>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>> PeriodicTask_lock >>>>>>>>>> and some of the surrounding code. This is a targeted review in >>>>>>>>>> that >>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>> >>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>> PeriodicTask's >>>>>>>>>> execution interval >>>>>>>>>> >>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>> >>>>>>>>>> 2) The reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> Markus G and Coleen >>>>>>>>>> >>>>>>>>>> 3) Alex and Carsten >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here's the webrev URL: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>> will be done with this fix. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > From markus.gronlund at oracle.com Mon Mar 2 12:34:38 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 2 Mar 2015 04:34:38 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Message-ID: <36a97a89-bd11-44b2-8a5f-93202556d574@default> Greetings, Kindly asking for reviews for the following changeset: Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ Description: The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. Analysis: The _wakeup semaphore only allows for a single outstanding operation: CreateSemaphore(NULL, 0, 1, NULL); When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: ::ReleaseSemaphore(wakeup(), 1, NULL); This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. Tests: Jcmd/dcmd test Attach tests Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Mon Mar 2 13:44:10 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 02 Mar 2015 14:44:10 +0100 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <36a97a89-bd11-44b2-8a5f-93202556d574@default> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> Message-ID: <54F4692A.9060400@oracle.com> Hi Markus, On 2.3.2015 13:34, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for the following changeset: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ Looks reasonable. > > Description: > > The signaling mechanism used to communicate about attaching operations > under Windows currently only allows for a single outstanding item to be > visible. This leads to issues, such as the one described in this bug, > where clients assume their operations are under processing (they have > been enqueued after all), but the AttachListener thread does not see, > and hence do not process, these operations. > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the > AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore > count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread > which (most likely) is in WaitForSingleObject() for the semaphore to > become signaled. When the semaphore is signaled and AttachListener > returns from WaitForSingleObject(), the semaphore's count is > decremented, and the semaphore again becomes non-signaled (goes from > current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they > manage to get the list mutex() - if they do, they will insert their op > into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted > operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent > calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current > count to > maximum count, will have _no_effect - the current count of > the semaphore remains at maximum count level AND > ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently > there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will > move into ConnectPipe()), but the AttachListener will never see more > than 1 enqueued op at any one time (hence it does not know it is > expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until > another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are > enqueued - and since we only allow preallocate_count number of > operations to be enqueued, we can ensure the semaphore manages this > upper limit as its maximum count. So, if the number of enqueue request is higher than the max semaphore count it will just fail with the assert? Thanks, -JB- > > Tests: > > Jcmd/dcmd test > > Attach tests > > Thanks > > Markus > From dmitry.samersoff at oracle.com Mon Mar 2 13:51:35 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 02 Mar 2015 16:51:35 +0300 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <36a97a89-bd11-44b2-8a5f-93202556d574@default> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> Message-ID: <54F46AE7.7040102@oracle.com> Markus, Looks good for me. Excellent finding. Variable 229 BOOL not_exceeding_semaphore_maximum_count = is not used in production and it could lead to a compiler warning. So it might be better to use guarantee instead of assert here. -Dmitry On 2015-03-02 15:34, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From coleen.phillimore at oracle.com Mon Mar 2 15:02:57 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 02 Mar 2015 10:02:57 -0500 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F0E791.8020409@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> Message-ID: <54F47BA1.80502@oracle.com> Yes, this new comment tells me the secret bit of information I didn't know from looking at that bit of code. thanks, Coleen On 2/27/15, 4:54 PM, Daniel D. Daugherty wrote: > Coleen and David, > > My final attempt to get more acceptable wording for this comment: > > Here's the current wording: > > + // The WatcherThread is not a JavaThread so we do not honor the > + // safepoint protocol for the PeriodicTask_lock. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > How about: > > + // The WatcherThread does not participate in the safepoint protocol > + // for the PeriodicTask_lock because it is not a JavaThread. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > This change would be made in task.cpp: PeriodicTask::real_time_tick() > and thread.cpp: WatcherThread::sleep(). > > Is this acceptable? > > Dan > > > On 2/27/15 1:36 PM, Coleen Phillimore wrote: >> >> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>> Coleen, >>> >>> Thanks for the review. Replies embedded below. >>> >>> David, >>> >>> Thanks for jumping in while I was out of the office yesterday. >>> >>> >>> On 2/26/15 12:13 AM, David Holmes wrote: >>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>> >>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>> couple of questions. >>>>>>> >>>>>>> in >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> This comment is really confusing because I think you do in fact >>>>>>> honor >>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>> >>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>> WatcherThread will sometimes acquire locks that potentially check >>>>>> the >>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>> actually taken. Hence we can call the code that will never consider >>>>>> taking them if the only caller of that code (as in this case) is a >>>>>> non-JavaThread. >>>>> >>>>> So you could theoretically have the watcher thread use the regular >>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>> scenes, the safepoint check is elided. >>>> >>>> Yes, internally there is one path for JavaThreads and a different >>>> path for non-JavaThreads. JavaThreads perform thread-state >>>> transitions which form part of the safepoint protocol. >>> >>> So it looks like "honor the safepoint protocol" is bad choice of >>> words. More below. >>> >>> Earlier in this thread, Marcus talked about switching from >>> MutexLockerEx -> MutexLocker and the problem that he ran into >>> with the wait() function. He's planning to explore this idea >>> further using a different bug ID in order to clean up this >>> wart. >>> >>> >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); >> Your explanation makes sense. To be honest, I'm not sure how to >> reword it so it makes more sense, other than to add that the >> safepoint check isn't made anyway for !JavaThreads. >> >> Coleen >>>> >>>>> So the comment really doesn't explain what's going on, and leads >>>>> one to >>>>> believe that you need to be careful _not_ to take a safepoint >>>>> check with >>>>> the Watcher thread. >>>> >>>> I don't read it that way but would it be better if it said "do not >>>> _need to_ honor" instead? >>> >>> Perhaps "does not participate in the safepoint protocol" is >>> better and more clear? >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>> I'll stop reading comments again. >>> >>> Please don't. I'm trying to make the comments more clear in an >>> area that is a bit messy. If the comments don't make sense to >>> you, then I need to fix that. >>> >>> >>>>> >>>>> Thanks for the explanation though, the latter part I knew about. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>> honor >>>>>>> the >>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>> >>>>>>> >>>>>>> Because WatcherThread::stop() does safepoint check. >>> >>> WatcherThread::stop() does a safepoint check because it is >>> called by a JavaThread instead of the WatcherThread. I added >>> a new comment that was supposed to make this clear. Is the >>> comment in thread.cpp not clear? >>> >>> >>>>>>> It's unclear >>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>> also. >>>>>>> If so, should they have no_safepoint_check. >>> >>> That's true. It is not clear that the WatcherThread does not call >>> enroll() or disenroll() and I didn't add an assert for this one. >>> As David pointed out earlier in this review thread, the API for >>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>> but we agreed that should be done via another bug ID that is >>> focused on just API cleanup. >>> >>> >>>>>> >>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>> never want to check for safepoints. If the only caller is a >>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>> JavaThread then safepoint checking can only be elided under very >>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>> enrol/disenrol then we should check for safepoints (as the >>>>>> conditions >>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>> methods). >>>>>> >>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>> nervous, but >>>>>>> the comment seems misleading. >>>>>> >>>>>> Hope it is clearer now. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> I honestly don't know enough about the rest to review it. >>> >>> Thanks for taking a look at it anyway. >>> >>> Dan >>> >>> >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>> This should be the last webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>> >>>>>>>> >>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd >>>>>>>> like >>>>>>>> to hear from you in this hopefully final round... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, here is the bug's URL: >>>>>>>>> >>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>> >>>>>>>>> Update for testing: I'm taking the new Remote Build and Test >>>>>>>>> (RBT) >>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>> direct >>>>>>>>> Aurora Adhoc jobs... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> My fix for the following bug: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>> >>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>> >>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>> PeriodicTask_lock >>>>>>>>>> and some of the surrounding code. This is a targeted review >>>>>>>>>> in that >>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>> >>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>> PeriodicTask's >>>>>>>>>> execution interval >>>>>>>>>> >>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>> >>>>>>>>>> 2) The reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> Markus G and Coleen >>>>>>>>>> >>>>>>>>>> 3) Alex and Carsten >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here's the webrev URL: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>> will be done with this fix. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Mon Mar 2 15:41:09 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 2 Mar 2015 07:41:09 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <54F46AE7.7040102@oracle.com> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F46AE7.7040102@oracle.com> Message-ID: <41e88e89-ab52-4868-991c-dc217789c4fb@default> Hi Dmitry, Thanks for taking a look. Also thanks for the hint about using a guarantee instead of an assert - you are right, I will change it accordingly. Cheers Markus -----Original Message----- From: Dmitry Samersoff Sent: den 2 mars 2015 14:52 To: Markus Gronlund; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Markus, Looks good for me. Excellent finding. Variable 229 BOOL not_exceeding_semaphore_maximum_count = is not used in production and it could lead to a compiler warning. So it might be better to use guarantee instead of assert here. -Dmitry On 2015-03-02 15:34, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From markus.gronlund at oracle.com Mon Mar 2 15:49:10 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 2 Mar 2015 07:49:10 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <54F4692A.9060400@oracle.com> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F4692A.9060400@oracle.com> Message-ID: <293871bf-358a-45ac-ba8e-9d92b4ea67bd@default> Hi Jaroslav, Thanks for taking a look. "So, if the number of enqueue request is higher than the max semaphore count it will just fail with the assert?" I am letting the max semaphore count reflect the number of available (also pre-allocated) operations - a client should not be able to reach this code if there are max semaphore count outstanding ops (it should not be able to get a valid op from available()). Thanks again Markus -----Original Message----- From: Jaroslav Bachorik Sent: den 2 mars 2015 14:44 To: serviceability-dev at openjdk.java.net Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Hi Markus, On 2.3.2015 13:34, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for the following changeset: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ Looks reasonable. > > Description: > > The signaling mechanism used to communicate about attaching operations > under Windows currently only allows for a single outstanding item to > be visible. This leads to issues, such as the one described in this > bug, where clients assume their operations are under processing (they > have been enqueued after all), but the AttachListener thread does not > see, and hence do not process, these operations. > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the > AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore > count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread > which (most likely) is in WaitForSingleObject() for the semaphore to > become signaled. When the semaphore is signaled and AttachListener > returns from WaitForSingleObject(), the semaphore's count is > decremented, and the semaphore again becomes non-signaled (goes from > current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they > manage to get the list mutex() - if they do, they will insert their op > into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted > operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent > calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the > current count to > maximum count, will have _no_effect - the current > count of the semaphore remains at maximum count level AND > ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently > there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will > move into ConnectPipe()), but the AttachListener will never see more > than 1 enqueued op at any one time (hence it does not know it is > expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until > another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are > enqueued - and since we only allow preallocate_count number of > operations to be enqueued, we can ensure the semaphore manages this > upper limit as its maximum count. So, if the number of enqueue request is higher than the max semaphore count it will just fail with the assert? Thanks, -JB- > > Tests: > > Jcmd/dcmd test > > Attach tests > > Thanks > > Markus > From daniel.daugherty at oracle.com Mon Mar 2 15:49:15 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 02 Mar 2015 08:49:15 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F41ED7.2070208@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> <54F41ED7.2070208@oracle.com> Message-ID: <54F4867B.1090704@oracle.com> On 3/2/15 1:27 AM, David Holmes wrote: > On 28/02/2015 7:54 AM, Daniel D. Daugherty wrote: >> Coleen and David, >> >> My final attempt to get more acceptable wording for this comment: >> >> Here's the current wording: >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> How about: >> >> + // The WatcherThread does not participate in the safepoint protocol >> + // for the PeriodicTask_lock because it is not a JavaThread. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> This change would be made in task.cpp: PeriodicTask::real_time_tick() >> and thread.cpp: WatcherThread::sleep(). >> >> Is this acceptable? > > Fine by me. Thanks! Dan > > Thanks, > David > >> Dan >> >> >> On 2/27/15 1:36 PM, Coleen Phillimore wrote: >>> >>> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>>> Coleen, >>>> >>>> Thanks for the review. Replies embedded below. >>>> >>>> David, >>>> >>>> Thanks for jumping in while I was out of the office yesterday. >>>> >>>> >>>> On 2/26/15 12:13 AM, David Holmes wrote: >>>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>>> >>>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>>> couple of questions. >>>>>>>> >>>>>>>> in >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This comment is really confusing because I think you do in fact >>>>>>>> honor >>>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>>> >>>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>>> WatcherThread will sometimes acquire locks that potentially >>>>>>> check the >>>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>>> actually taken. Hence we can call the code that will never consider >>>>>>> taking them if the only caller of that code (as in this case) is a >>>>>>> non-JavaThread. >>>>>> >>>>>> So you could theoretically have the watcher thread use the regular >>>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>>> scenes, the safepoint check is elided. >>>>> >>>>> Yes, internally there is one path for JavaThreads and a different >>>>> path for non-JavaThreads. JavaThreads perform thread-state >>>>> transitions which form part of the safepoint protocol. >>>> >>>> So it looks like "honor the safepoint protocol" is bad choice of >>>> words. More below. >>>> >>>> Earlier in this thread, Marcus talked about switching from >>>> MutexLockerEx -> MutexLocker and the problem that he ran into >>>> with the wait() function. He's planning to explore this idea >>>> further using a different bug ID in order to clean up this >>>> wart. >>>> >>>> >>> >>> + // The WatcherThread is not a JavaThread so we do not honor the >>> + // safepoint protocol for the PeriodicTask_lock. >>> MutexLockerEx ml(PeriodicTask_lock, >>> Mutex::_no_safepoint_check_flag); >>> Your explanation makes sense. To be honest, I'm not sure how to >>> reword it so it makes more sense, other than to add that the safepoint >>> check isn't made anyway for !JavaThreads. >>> >>> Coleen >>>>> >>>>>> So the comment really doesn't explain what's going on, and leads >>>>>> one to >>>>>> believe that you need to be careful _not_ to take a safepoint check >>>>>> with >>>>>> the Watcher thread. >>>>> >>>>> I don't read it that way but would it be better if it said "do not >>>>> _need to_ honor" instead? >>>> >>>> Perhaps "does not participate in the safepoint protocol" is >>>> better and more clear? >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> I'll stop reading comments again. >>>> >>>> Please don't. I'm trying to make the comments more clear in an >>>> area that is a bit messy. If the comments don't make sense to >>>> you, then I need to fix that. >>>> >>>> >>>>>> >>>>>> Thanks for the explanation though, the latter part I knew about. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>>> honor >>>>>>>> the >>>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>>> >>>>>>>> >>>>>>>> Because WatcherThread::stop() does safepoint check. >>>> >>>> WatcherThread::stop() does a safepoint check because it is >>>> called by a JavaThread instead of the WatcherThread. I added >>>> a new comment that was supposed to make this clear. Is the >>>> comment in thread.cpp not clear? >>>> >>>> >>>>>>>> It's unclear >>>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>>> also. >>>>>>>> If so, should they have no_safepoint_check. >>>> >>>> That's true. It is not clear that the WatcherThread does not call >>>> enroll() or disenroll() and I didn't add an assert for this one. >>>> As David pointed out earlier in this review thread, the API for >>>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>>> but we agreed that should be done via another bug ID that is >>>> focused on just API cleanup. >>>> >>>> >>>>>>> >>>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>>> never want to check for safepoints. If the only caller is a >>>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>>> JavaThread then safepoint checking can only be elided under very >>>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>>> enrol/disenrol then we should check for safepoints (as the >>>>>>> conditions >>>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>>> methods). >>>>>>> >>>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>>> nervous, but >>>>>>>> the comment seems misleading. >>>>>>> >>>>>>> Hope it is clearer now. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> I honestly don't know enough about the rest to review it. >>>> >>>> Thanks for taking a look at it anyway. >>>> >>>> Dan >>>> >>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>>> This should be the last webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd >>>>>>>>> like >>>>>>>>> to hear from you in this hopefully final round... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, here is the bug's URL: >>>>>>>>>> >>>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>>> >>>>>>>>>> Update for testing: I'm taking the new Remote Build and Test >>>>>>>>>> (RBT) >>>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>>> direct >>>>>>>>>> Aurora Adhoc jobs... >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>>> Greetings, >>>>>>>>>>> >>>>>>>>>>> My fix for the following bug: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>>> >>>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>>> >>>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>>> PeriodicTask_lock >>>>>>>>>>> and some of the surrounding code. This is a targeted review in >>>>>>>>>>> that >>>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>>> >>>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>>> PeriodicTask's >>>>>>>>>>> execution interval >>>>>>>>>>> >>>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>>> >>>>>>>>>>> 2) The reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> Markus G and Coleen >>>>>>>>>>> >>>>>>>>>>> 3) Alex and Carsten >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here's the webrev URL: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>>> will be done with this fix. >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > > From daniel.daugherty at oracle.com Mon Mar 2 15:49:40 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 02 Mar 2015 08:49:40 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F47BA1.80502@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> <54F47BA1.80502@oracle.com> Message-ID: <54F48694.9070105@oracle.com> Thanks! Dan On 3/2/15 8:02 AM, Coleen Phillimore wrote: > > Yes, this new comment tells me the secret bit of information I didn't > know from looking at that bit of code. > > thanks, > Coleen > > On 2/27/15, 4:54 PM, Daniel D. Daugherty wrote: >> Coleen and David, >> >> My final attempt to get more acceptable wording for this comment: >> >> Here's the current wording: >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> How about: >> >> + // The WatcherThread does not participate in the safepoint protocol >> + // for the PeriodicTask_lock because it is not a JavaThread. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> This change would be made in task.cpp: PeriodicTask::real_time_tick() >> and thread.cpp: WatcherThread::sleep(). >> >> Is this acceptable? >> >> Dan >> >> >> On 2/27/15 1:36 PM, Coleen Phillimore wrote: >>> >>> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>>> Coleen, >>>> >>>> Thanks for the review. Replies embedded below. >>>> >>>> David, >>>> >>>> Thanks for jumping in while I was out of the office yesterday. >>>> >>>> >>>> On 2/26/15 12:13 AM, David Holmes wrote: >>>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>>> >>>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>>> couple of questions. >>>>>>>> >>>>>>>> in >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This comment is really confusing because I think you do in fact >>>>>>>> honor >>>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>>> >>>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>>> WatcherThread will sometimes acquire locks that potentially >>>>>>> check the >>>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>>> actually taken. Hence we can call the code that will never consider >>>>>>> taking them if the only caller of that code (as in this case) is a >>>>>>> non-JavaThread. >>>>>> >>>>>> So you could theoretically have the watcher thread use the regular >>>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>>> scenes, the safepoint check is elided. >>>>> >>>>> Yes, internally there is one path for JavaThreads and a different >>>>> path for non-JavaThreads. JavaThreads perform thread-state >>>>> transitions which form part of the safepoint protocol. >>>> >>>> So it looks like "honor the safepoint protocol" is bad choice of >>>> words. More below. >>>> >>>> Earlier in this thread, Marcus talked about switching from >>>> MutexLockerEx -> MutexLocker and the problem that he ran into >>>> with the wait() function. He's planning to explore this idea >>>> further using a different bug ID in order to clean up this >>>> wart. >>>> >>>> >>> >>> + // The WatcherThread is not a JavaThread so we do not honor the >>> + // safepoint protocol for the PeriodicTask_lock. >>> MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); >>> Your explanation makes sense. To be honest, I'm not sure how to >>> reword it so it makes more sense, other than to add that the >>> safepoint check isn't made anyway for !JavaThreads. >>> >>> Coleen >>>>> >>>>>> So the comment really doesn't explain what's going on, and leads >>>>>> one to >>>>>> believe that you need to be careful _not_ to take a safepoint >>>>>> check with >>>>>> the Watcher thread. >>>>> >>>>> I don't read it that way but would it be better if it said "do not >>>>> _need to_ honor" instead? >>>> >>>> Perhaps "does not participate in the safepoint protocol" is >>>> better and more clear? >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> I'll stop reading comments again. >>>> >>>> Please don't. I'm trying to make the comments more clear in an >>>> area that is a bit messy. If the comments don't make sense to >>>> you, then I need to fix that. >>>> >>>> >>>>>> >>>>>> Thanks for the explanation though, the latter part I knew about. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>>> honor >>>>>>>> the >>>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>>> >>>>>>>> >>>>>>>> Because WatcherThread::stop() does safepoint check. >>>> >>>> WatcherThread::stop() does a safepoint check because it is >>>> called by a JavaThread instead of the WatcherThread. I added >>>> a new comment that was supposed to make this clear. Is the >>>> comment in thread.cpp not clear? >>>> >>>> >>>>>>>> It's unclear >>>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>>> also. >>>>>>>> If so, should they have no_safepoint_check. >>>> >>>> That's true. It is not clear that the WatcherThread does not call >>>> enroll() or disenroll() and I didn't add an assert for this one. >>>> As David pointed out earlier in this review thread, the API for >>>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>>> but we agreed that should be done via another bug ID that is >>>> focused on just API cleanup. >>>> >>>> >>>>>>> >>>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>>> never want to check for safepoints. If the only caller is a >>>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>>> JavaThread then safepoint checking can only be elided under very >>>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>>> enrol/disenrol then we should check for safepoints (as the >>>>>>> conditions >>>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>>> methods). >>>>>>> >>>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>>> nervous, but >>>>>>>> the comment seems misleading. >>>>>>> >>>>>>> Hope it is clearer now. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> I honestly don't know enough about the rest to review it. >>>> >>>> Thanks for taking a look at it anyway. >>>> >>>> Dan >>>> >>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>>> This should be the last webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd >>>>>>>>> like >>>>>>>>> to hear from you in this hopefully final round... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, here is the bug's URL: >>>>>>>>>> >>>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>>> >>>>>>>>>> Update for testing: I'm taking the new Remote Build and Test >>>>>>>>>> (RBT) >>>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>>> direct >>>>>>>>>> Aurora Adhoc jobs... >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>>> Greetings, >>>>>>>>>>> >>>>>>>>>>> My fix for the following bug: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>>> >>>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>>> >>>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>>> PeriodicTask_lock >>>>>>>>>>> and some of the surrounding code. This is a targeted review >>>>>>>>>>> in that >>>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>>> >>>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>>> PeriodicTask's >>>>>>>>>>> execution interval >>>>>>>>>>> >>>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>>> >>>>>>>>>>> 2) The reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> Markus G and Coleen >>>>>>>>>>> >>>>>>>>>>> 3) Alex and Carsten >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here's the webrev URL: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>>> will be done with this fix. >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmundak at google.com Tue Mar 3 00:59:21 2015 From: asmundak at google.com (Alexander Smundak) Date: Mon, 2 Mar 2015 16:59:21 -0800 Subject: gdb and OpenJDK In-Reply-To: <54E75153.40400@redhat.com> References: <54E75153.40400@redhat.com> Message-ID: I have posted a very preliminary version of the Python module that provides the ability to walk JVM frames in GDB and show them as Java frames (i.e., Java method names and arguments): http://cr.openjdk.java.net/~asmundak/gdbunwind/hotspot/webrev.00/agent/src/os/linux/gdb/libjvm.so-gdb.py.html If you want to play with it, you will need to apply my proposed GDB patch (see the attachment to https://sourceware.org/ml/gdb-patches/2015-02/msg00735.html), and then follow the instructions in the source file. I'll keep posting the new versions of this code in http://cr.openjdk.java.net/~asmundak/gdbunwind/hotspot/webrev.01/ as they become available. On Fri, Feb 20, 2015 at 7:22 AM, Phil Muldoon wrote: >>> On Mon, Feb 16, 2015 at 2:52 AM, Andrew Haley wrote: >>> It would be, long term. I've been discussing this with Red Hat's GDB >>> group and I'm hoping to come up with a proposal and hopefully some >>> working code. >> I have the enabling patch to GDB being reviewed at a glacial pace (see >> https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html). Perhaps >> Red Hat's GDB group can respond there? > > Please accept my apologies for first posting out-of-thread. I did not > have the original email context with headers to post in-thread. So, > heads-up, I broke email threading in this reply. > > Second, again, apologies for the speed of the review. Christmas, and > we've all been busy. I see Doug is looking at it now, and I have also > asked some questions of the patch. > > I find the functionality very useful. Hopefully it will progress soon > and be committed. > > Cheers > > Phil > From dean.long at oracle.com Tue Mar 3 01:32:17 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Mar 2015 17:32:17 -0800 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <36a97a89-bd11-44b2-8a5f-93202556d574@default> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> Message-ID: <54F50F21.5040104@oracle.com> Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. dl On 3/2/2015 4:34 AM, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus From markus.gronlund at oracle.com Tue Mar 3 09:15:21 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Mar 2015 01:15:21 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <54F50F21.5040104@oracle.com> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F50F21.5040104@oracle.com> Message-ID: <4abbf698-202a-43cc-8b9b-59926a629e07@default> Hi Dean, Thanks for your input. I think a monitor would be less ideal here: A monitor would introduce blocking in enqueuing operations. The "posters" are (in this case) remotely injected threads (by another process), and the processes injecting those threads are in WaitForSingleObject() on those thread handles. If a monitor is used, it needs to be held by the AttachListener over executing (arbitrary) operations. Granted, each operation today is being executed in serial fashion (but it does not need to be), but I believe we would not like to have each client also block on the monitor as part of enqueuing their operation, just in order to issue the notify. With a Windows Semaphore, clients can act asynchronously in regard to enqueuing. As long as the semaphore's current count is > 0, there is no blocking on the part of the AttachListener thread, WaitForSingleObject() return immediately decrementing the current count. Thanks Markus -----Original Message----- From: Dean Long Sent: den 3 mars 2015 02:32 To: Markus Gronlund; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. dl On 3/2/2015 4:34 AM, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore > count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus From kevin.walls at oracle.com Tue Mar 3 13:15:29 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 03 Mar 2015 13:15:29 +0000 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. Message-ID: <54F5B3F1.5070404@oracle.com> Hi, This is a review request for a way to make the SA tools protect themselves from infinite loops during initialisation. Attaching jmap (for example) to a JVM can fail, infinitely writing an error - and filling a disk if being logged to a file. This reproduces on a Solaris package based install, but not with other distribution bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> client/libjvm.so. If a server/libjvm.so is loaded and running, we see libverify.so pull in client/libjvm.so, as it finds the symlink in its $ORIGIN, in preference to finding the already loaded libjvm.so. Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. There are various things wrong with that. Protection against zero strides through the type arrays and a maximum count for duplicated types will protect us from a few possible problems. I'll also work a bug for the "install" repo where we create that symlink, but the tools need to protect themselves from this kind of problem. Testing was manual. bug https://bugs.openjdk.java.net/browse/JDK-8073688 webrev http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ Thanks Kevin From mikael.gerdin at oracle.com Tue Mar 3 13:51:14 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 03 Mar 2015 14:51:14 +0100 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F5B3F1.5070404@oracle.com> References: <54F5B3F1.5070404@oracle.com> Message-ID: <54F5BC52.7080908@oracle.com> Kevin, On 2015-03-03 14:15, Kevin Walls wrote: > Hi, > > This is a review request for a way to make the SA tools protect > themselves from infinite loops during initialisation. > > Attaching jmap (for example) to a JVM can fail, infinitely writing an > error - and filling a disk if being logged to a file. This reproduces > on a Solaris package based install, but not with other distribution > bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> > client/libjvm.so. If a server/libjvm.so is loaded and running, we see > libverify.so pull in client/libjvm.so, as it finds the symlink in its > $ORIGIN, in preference to finding the already loaded libjvm.so. There is only server/libjvm.so on Solaris since JDK 8, so I assume that this RFR is for JDK 7u only. The late stage of the JDK 7u updates project should perhaps be considered when looking at this change. /Mikael > > Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. > There are various things wrong with that. Protection against zero > strides through the type arrays and a maximum count for duplicated types > will protect us from a few possible problems. > > I'll also work a bug for the "install" repo where we create that > symlink, but the tools need to protect themselves from this kind of > problem. > > Testing was manual. > > bug > https://bugs.openjdk.java.net/browse/JDK-8073688 > > webrev > http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ > > Thanks > Kevin From kevin.walls at oracle.com Tue Mar 3 13:57:40 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 03 Mar 2015 13:57:40 +0000 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F5BC52.7080908@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F5BC52.7080908@oracle.com> Message-ID: <54F5BDD4.5050009@oracle.com> Hi, Yes that's true - the original problem is in 7u. We'll have it around for a while yet so I would like to get this change there to protect us. While we can't reproduce the same thing on 9 today, there's still a while loop that will never terminate if we read a zero for the stride size, for example. I think it's worth protecting ourselves from that kind of problem. Thanks Kevin On 03/03/2015 13:51, Mikael Gerdin wrote: > Kevin, > > On 2015-03-03 14:15, Kevin Walls wrote: >> Hi, >> >> This is a review request for a way to make the SA tools protect >> themselves from infinite loops during initialisation. >> >> Attaching jmap (for example) to a JVM can fail, infinitely writing an >> error - and filling a disk if being logged to a file. This reproduces >> on a Solaris package based install, but not with other distribution >> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >> libverify.so pull in client/libjvm.so, as it finds the symlink in its >> $ORIGIN, in preference to finding the already loaded libjvm.so. > > There is only server/libjvm.so on Solaris since JDK 8, so I assume > that this RFR is for JDK 7u only. The late stage of the JDK 7u updates > project should perhaps be considered when looking at this change. > > /Mikael > >> >> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >> There are various things wrong with that. Protection against zero >> strides through the type arrays and a maximum count for duplicated types >> will protect us from a few possible problems. >> >> I'll also work a bug for the "install" repo where we create that >> symlink, but the tools need to protect themselves from this kind of >> problem. >> >> Testing was manual. >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8073688 >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >> >> Thanks >> Kevin From mikael.gerdin at oracle.com Tue Mar 3 14:02:45 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 03 Mar 2015 15:02:45 +0100 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F5BDD4.5050009@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F5BC52.7080908@oracle.com> <54F5BDD4.5050009@oracle.com> Message-ID: <54F5BF05.9090108@oracle.com> On 2015-03-03 14:57, Kevin Walls wrote: > > Hi, > > Yes that's true - the original problem is in 7u. We'll have it around > for a while yet so I would like to get this change there to protect us. > > While we can't reproduce the same thing on 9 today, there's still a > while loop that will never terminate if we read a zero for the stride > size, for example. I think it's worth protecting ourselves from that > kind of problem. That's probably a good idea to fix then. I'll leave the rest for people who are qualified to review the code :) /Mikael > > Thanks > Kevin > > On 03/03/2015 13:51, Mikael Gerdin wrote: >> Kevin, >> >> On 2015-03-03 14:15, Kevin Walls wrote: >>> Hi, >>> >>> This is a review request for a way to make the SA tools protect >>> themselves from infinite loops during initialisation. >>> >>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>> error - and filling a disk if being logged to a file. This reproduces >>> on a Solaris package based install, but not with other distribution >>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>> $ORIGIN, in preference to finding the already loaded libjvm.so. >> >> There is only server/libjvm.so on Solaris since JDK 8, so I assume >> that this RFR is for JDK 7u only. The late stage of the JDK 7u updates >> project should perhaps be considered when looking at this change. >> >> /Mikael >> >>> >>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>> There are various things wrong with that. Protection against zero >>> strides through the type arrays and a maximum count for duplicated types >>> will protect us from a few possible problems. >>> >>> I'll also work a bug for the "install" repo where we create that >>> symlink, but the tools need to protect themselves from this kind of >>> problem. >>> >>> Testing was manual. >>> >>> bug >>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>> >>> webrev >>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>> >>> Thanks >>> Kevin > From jaroslav.bachorik at oracle.com Tue Mar 3 16:27:52 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Mar 2015 17:27:52 +0100 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources Message-ID: <54F5E108.3010902@oracle.com> Hi all, Please review this draft JEP for JMX Specific Annotations for Registration of Managed Resources: https://bugs.openjdk.java.net/browse/JDK-8044507 Background: Current mechanism of defining an MBean requires to provide an MBean interface and its implementation. The interface and the implementation must conform to the strict naming and visibility rules in order for the introspection to be able to bind them. At least the same level of verbosity is required when adding an MBeanInfo to generate MBean metadata. All this leads to a rather verbose code containing a lot of repeating boilerplate parts even for the most simple MBean registrations. This JEP proposes to add a set of annotations for registration and configuration of manageable resources (in other word 'MBeans'). These annotations will be used to generate all the metadata necessary for a resources to be accepted by the current JMX system. Thanks, -JB- From dean.long at oracle.com Tue Mar 3 19:36:44 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 03 Mar 2015 11:36:44 -0800 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <4abbf698-202a-43cc-8b9b-59926a629e07@default> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F50F21.5040104@oracle.com> <4abbf698-202a-43cc-8b9b-59926a629e07@default> Message-ID: <54F60D4C.8010402@oracle.com> Hi Markus. OK, thanks for the explanation. dl On 3/3/2015 1:15 AM, Markus Gronlund wrote: > Hi Dean, > > Thanks for your input. > > I think a monitor would be less ideal here: > > A monitor would introduce blocking in enqueuing operations. > > The "posters" are (in this case) remotely injected threads (by another process), and the processes injecting those threads are in WaitForSingleObject() on those thread handles. If a monitor is used, it needs to be held by the AttachListener over executing (arbitrary) operations. Granted, each operation today is being executed in serial fashion (but it does not need to be), but I believe we would not like to have each client also block on the monitor as part of enqueuing their operation, just in order to issue the notify. > > With a Windows Semaphore, clients can act asynchronously in regard to enqueuing. As long as the semaphore's current count is > 0, there is no blocking on the part of the AttachListener thread, WaitForSingleObject() return immediately decrementing the current count. > > Thanks > Markus > > > -----Original Message----- > From: Dean Long > Sent: den 3 mars 2015 02:32 > To: Markus Gronlund; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) > > Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. > > dl > > On 3/2/2015 4:34 AM, Markus Gronlund wrote: >> Greetings, >> >> >> >> Kindly asking for reviews for the following changeset: >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ >> >> >> >> Description: >> >> The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. >> >> >> >> Analysis: >> >> The _wakeup semaphore only allows for a single outstanding operation: >> >> CreateSemaphore(NULL, 0, 1, NULL); >> >> When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore >> count by 1 >> >> This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). >> >> >> Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); >> >> This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. >> >> Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... >> This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). >> >> This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. >> >> We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. >> >> >> >> Tests: >> >> >> >> Jcmd/dcmd test >> >> Attach tests >> >> >> >> Thanks >> >> Markus From dmitry.samersoff at oracle.com Tue Mar 3 20:10:03 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 03 Mar 2015 23:10:03 +0300 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F5B3F1.5070404@oracle.com> References: <54F5B3F1.5070404@oracle.com> Message-ID: <54F6151B.7050106@oracle.com> Kevin, The fix looks good for me, but please add a comment explaining the problem we are solving here. -Dmitry On 2015-03-03 16:15, Kevin Walls wrote: > Hi, > > This is a review request for a way to make the SA tools protect > themselves from infinite loops during initialisation. > > Attaching jmap (for example) to a JVM can fail, infinitely writing an > error - and filling a disk if being logged to a file. This reproduces > on a Solaris package based install, but not with other distribution > bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> > client/libjvm.so. If a server/libjvm.so is loaded and running, we see > libverify.so pull in client/libjvm.so, as it finds the symlink in its > $ORIGIN, in preference to finding the already loaded libjvm.so. > > Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. > There are various things wrong with that. Protection against zero > strides through the type arrays and a maximum count for duplicated types > will protect us from a few possible problems. > > I'll also work a bug for the "install" repo where we create that > symlink, but the tools need to protect themselves from this kind of > problem. > > Testing was manual. > > bug > https://bugs.openjdk.java.net/browse/JDK-8073688 > > webrev > http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ > > Thanks > Kevin -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From eamonn at mcmanus.net Wed Mar 4 01:09:57 2015 From: eamonn at mcmanus.net (Eamonn McManus) Date: Tue, 3 Mar 2015 17:09:57 -0800 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: <54F5E108.3010902@oracle.com> References: <54F5E108.3010902@oracle.com> Message-ID: Could you explain what you mean by this, regarding the annotations that were already agreed on by the JSR 255 Expert Group: * Smaller scope compared to the proposed solution * Conceptually in pre JDK7 era I have a number of other comments, but procedurally I'm not sure what the precedent is for summarily discarding work previously done in the JCP on the same subject. I'd certainly have expected this JEP to start from that work, rather than proposing a starting point that isn't even correct Java. ?amonn McManus, former JSR 255 Spec Lead 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik : > > Hi all, > > Please review this draft JEP for JMX Specific Annotations for Registration of Managed Resources: > > https://bugs.openjdk.java.net/browse/JDK-8044507 > > Background: > Current mechanism of defining an MBean requires to provide an MBean interface and its implementation. The interface and the implementation must conform to the strict naming and visibility rules in order for the introspection to be able to bind them. > > At least the same level of verbosity is required when adding an MBeanInfo to generate MBean metadata. > > All this leads to a rather verbose code containing a lot of repeating boilerplate parts even for the most simple MBean registrations. > > This JEP proposes to add a set of annotations for registration and configuration of manageable resources (in other word 'MBeans'). These annotations will be used to generate all the metadata necessary for a resources to be accepted by the current JMX system. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Mar 4 07:46:55 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Mar 2015 08:46:55 +0100 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: References: <54F5E108.3010902@oracle.com> Message-ID: <54F6B86F.7070405@oracle.com> On 4.3.2015 02:09, Eamonn McManus wrote: > Could you explain what you mean by this, regarding the annotations > that were already agreed on by the JSR 255 Expert Group: > > * Smaller scope compared to the proposed solution > * Conceptually in pre JDK7 era > > I have a number of other comments, but procedurally I'm not sure what > the precedent is for summarily discarding work previously done in the > JCP on the same subject. I'd certainly have expected this JEP to start > from that work, rather than proposing a starting point that isn't even > correct Java. I'll get back to the reasons shortly. But, in the meantime, would you care to elaborate what you find to be not "even correct Java"? -JB- > > ?amonn McManus, former JSR 255 Spec Lead > > 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik : >> >> Hi all, >> >> Please review this draft JEP for JMX Specific Annotations for Registration of Managed Resources: >> >> https://bugs.openjdk.java.net/browse/JDK-8044507 >> >> Background: >> Current mechanism of defining an MBean requires to provide an MBean interface and its implementation. The interface and the implementation must conform to the strict naming and visibility rules in order for the introspection to be able to bind them. >> >> At least the same level of verbosity is required when adding an MBeanInfo to generate MBean metadata. >> >> All this leads to a rather verbose code containing a lot of repeating boilerplate parts even for the most simple MBean registrations. >> >> This JEP proposes to add a set of annotations for registration and configuration of manageable resources (in other word 'MBeans'). These annotations will be used to generate all the metadata necessary for a resources to be accepted by the current JMX system. >> >> Thanks, >> >> -JB- From jaroslav.bachorik at oracle.com Wed Mar 4 08:47:44 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Mar 2015 09:47:44 +0100 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: References: <54F5E108.3010902@oracle.com> Message-ID: <54F6C6B0.2040908@oracle.com> On 4.3.2015 02:09, Eamonn McManus wrote: > Could you explain what you mean by this, regarding the annotations > that were already agreed on by the JSR 255 Expert Group: > > * Smaller scope compared to the proposed solution This is a leftover from the previous proposal which had wider scope than what is presented now. Still a few points remain. - ability to annotate fields turning them into attributes - ability to provide metadata directly in the annotations, not relying solely on inferring them from the annotated element - missing @ManagedConstructor to expose a constructor - optional 'service' argument to @ManagedBean annotation which will be reflected in the descriptor's 'interfaceClassName' field to provide a guidance about the recommended service interface when using JMX.newMXBeanProxy() > * Conceptually in pre JDK7 era I am afraid this relates more to the implementation - or at least the code I was able to reconstruct from the repo history. Shouldn't be mentioned here. > > I have a number of other comments, but procedurally I'm not sure what > the precedent is for summarily discarding work previously done in the > JCP on the same subject. I'd certainly have expected this JEP to start > from that work, rather than proposing a starting point that isn't even > correct Java. Well, this is a draft review. The JSR 255 annotations work is not discarded. It is mentioned in the alternatives. The purpose of the open review is to find out whether it is ok to continue with proposed feature, modify it to use eg. JSR 255 work or abandon it completely. -JB- > > ?amonn McManus, former JSR 255 Spec Lead > > 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik : >> >> Hi all, >> >> Please review this draft JEP for JMX Specific Annotations for Registration of Managed Resources: >> >> https://bugs.openjdk.java.net/browse/JDK-8044507 >> >> Background: >> Current mechanism of defining an MBean requires to provide an MBean interface and its implementation. The interface and the implementation must conform to the strict naming and visibility rules in order for the introspection to be able to bind them. >> >> At least the same level of verbosity is required when adding an MBeanInfo to generate MBean metadata. >> >> All this leads to a rather verbose code containing a lot of repeating boilerplate parts even for the most simple MBean registrations. >> >> This JEP proposes to add a set of annotations for registration and configuration of manageable resources (in other word 'MBeans'). These annotations will be used to generate all the metadata necessary for a resources to be accepted by the current JMX system. >> >> Thanks, >> >> -JB- From kevin.walls at oracle.com Wed Mar 4 11:29:29 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 04 Mar 2015 11:29:29 +0000 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F6151B.7050106@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> Message-ID: <54F6EC99.5030102@oracle.com> Thanks Dmitry - I will explain the counter's presence where we introduce it: // Counter to ensure read loops terminate: private static final int MAX_DUPLICATE_DEFINITIONS = 100; private static int duplicateDefCount = 0; Thanks Kevin On 03/03/2015 20:10, Dmitry Samersoff wrote: > Kevin, > > The fix looks good for me, but please add a comment explaining the > problem we are solving here. > > -Dmitry > > On 2015-03-03 16:15, Kevin Walls wrote: >> Hi, >> >> This is a review request for a way to make the SA tools protect >> themselves from infinite loops during initialisation. >> >> Attaching jmap (for example) to a JVM can fail, infinitely writing an >> error - and filling a disk if being logged to a file. This reproduces >> on a Solaris package based install, but not with other distribution >> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >> libverify.so pull in client/libjvm.so, as it finds the symlink in its >> $ORIGIN, in preference to finding the already loaded libjvm.so. >> >> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >> There are various things wrong with that. Protection against zero >> strides through the type arrays and a maximum count for duplicated types >> will protect us from a few possible problems. >> >> I'll also work a bug for the "install" repo where we create that >> symlink, but the tools need to protect themselves from this kind of >> problem. >> >> Testing was manual. >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8073688 >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >> >> Thanks >> Kevin > From staffan.larsen at oracle.com Wed Mar 4 12:29:03 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Mar 2015 13:29:03 +0100 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F6EC99.5030102@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> Message-ID: <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> > On 4 mar 2015, at 12:29, Kevin Walls wrote: > > Thanks Dmitry - > > I will explain the counter's presence where we introduce it: > > // Counter to ensure read loops terminate: > private static final int MAX_DUPLICATE_DEFINITIONS = 100; > private static int duplicateDefCount = 0; Should duplicateDefCount really be static? For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify? /Staffan > > > Thanks > Kevin > > > On 03/03/2015 20:10, Dmitry Samersoff wrote: >> Kevin, >> >> The fix looks good for me, but please add a comment explaining the >> problem we are solving here. >> >> -Dmitry >> >> On 2015-03-03 16:15, Kevin Walls wrote: >>> Hi, >>> >>> This is a review request for a way to make the SA tools protect >>> themselves from infinite loops during initialisation. >>> >>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>> error - and filling a disk if being logged to a file. This reproduces >>> on a Solaris package based install, but not with other distribution >>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>> $ORIGIN, in preference to finding the already loaded libjvm.so. >>> >>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>> There are various things wrong with that. Protection against zero >>> strides through the type arrays and a maximum count for duplicated types >>> will protect us from a few possible problems. >>> >>> I'll also work a bug for the "install" repo where we create that >>> symlink, but the tools need to protect themselves from this kind of >>> problem. >>> >>> Testing was manual. >>> >>> bug >>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>> >>> webrev >>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>> >>> Thanks >>> Kevin >> > From kevin.walls at oracle.com Wed Mar 4 13:07:33 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 04 Mar 2015 13:07:33 +0000 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> Message-ID: <54F70395.1050200@oracle.com> Hi Staffan -- staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase? Any doubt I will make it per HotSpotTypeDatabase. As I sometimes load multiple cores in kjdb, or load them multiple times, I should be encouraging less staticness in the SA overall: so yes let me remove that static! (updated webrev in same location) Well spotted on the structs loop: 8-) readVMTypes, readVMntConstants, readVMLongConstants may increase, or call something could increase, the counter. readVMStructs does not. These are four methods that are so similar you'd imagine they should get merged into one method one day. It seemed wrong to me to make the four methods yet more different, by taking out the check on duplicateDefCount for one of them. Also, maybe readVMStructs should be checking for duplicates anyway, and maybe one day it will. I'm guessing it doesn't because it was harder in that method compared to the others. 8-) So I put it there for regularity, but if you think it's misleading I'll take it out. In practice, as long as we have the duplicate check in readVMTypes(), we have the protection we need as this is called first. It is highly unlikely that would succeed and another of the methods would fail, the other checks are just making the code consistent. Thanks Kevin On 04/03/2015 12:29, Staffan Larsen wrote: >> On 4 mar 2015, at 12:29, Kevin Walls wrote: >> >> Thanks Dmitry - >> >> I will explain the counter's presence where we introduce it: >> >> // Counter to ensure read loops terminate: >> private static final int MAX_DUPLICATE_DEFINITIONS = 100; >> private static int duplicateDefCount = 0; > Should duplicateDefCount really be static? > > For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify? > > /Staffan > >> >> Thanks >> Kevin >> >> >> On 03/03/2015 20:10, Dmitry Samersoff wrote: >>> Kevin, >>> >>> The fix looks good for me, but please add a comment explaining the >>> problem we are solving here. >>> >>> -Dmitry >>> >>> On 2015-03-03 16:15, Kevin Walls wrote: >>>> Hi, >>>> >>>> This is a review request for a way to make the SA tools protect >>>> themselves from infinite loops during initialisation. >>>> >>>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>>> error - and filling a disk if being logged to a file. This reproduces >>>> on a Solaris package based install, but not with other distribution >>>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>>> $ORIGIN, in preference to finding the already loaded libjvm.so. >>>> >>>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>>> There are various things wrong with that. Protection against zero >>>> strides through the type arrays and a maximum count for duplicated types >>>> will protect us from a few possible problems. >>>> >>>> I'll also work a bug for the "install" repo where we create that >>>> symlink, but the tools need to protect themselves from this kind of >>>> problem. >>>> >>>> Testing was manual. >>>> >>>> bug >>>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>>> >>>> webrev >>>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>>> >>>> Thanks >>>> Kevin From staffan.larsen at oracle.com Wed Mar 4 14:05:20 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Mar 2015 15:05:20 +0100 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F70395.1050200@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> <54F70395.1050200@oracle.com> Message-ID: <19919931-9C0D-4AA5-91DA-3A0110267FD4@oracle.com> > On 4 mar 2015, at 14:07, Kevin Walls wrote: > > > Hi Staffan -- > > staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase? Any doubt I will make it per HotSpotTypeDatabase. As I sometimes load multiple cores in kjdb, or load them multiple times, I should be encouraging less staticness in the SA overall: so yes let me remove that static! (updated webrev in same location) Thanks. > > > Well spotted on the structs loop: 8-) > readVMTypes, readVMntConstants, readVMLongConstants may increase, or call something could increase, the counter. > readVMStructs does not. > > These are four methods that are so similar you'd imagine they should get merged into one method one day. It seemed wrong to me to make the four methods yet more different, by taking out the check on duplicateDefCount for one of them. > > Also, maybe readVMStructs should be checking for duplicates anyway, and maybe one day it will. I'm guessing it doesn't because it was harder in that method compared to the others. 8-) > > So I put it there for regularity, but if you think it's misleading I'll take it out. Yes, please take it out. Thanks, /Staffan > > In practice, as long as we have the duplicate check in readVMTypes(), we have the protection we need as this is called first. It is highly unlikely that would succeed and another of the methods would fail, the other checks are just making the code consistent. > > Thanks > Kevin > > > > On 04/03/2015 12:29, Staffan Larsen wrote: >>> On 4 mar 2015, at 12:29, Kevin Walls wrote: >>> >>> Thanks Dmitry - >>> >>> I will explain the counter's presence where we introduce it: >>> >>> // Counter to ensure read loops terminate: >>> private static final int MAX_DUPLICATE_DEFINITIONS = 100; >>> private static int duplicateDefCount = 0; >> Should duplicateDefCount really be static? >> >> For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify? >> >> /Staffan >> >>> >>> Thanks >>> Kevin >>> >>> >>> On 03/03/2015 20:10, Dmitry Samersoff wrote: >>>> Kevin, >>>> >>>> The fix looks good for me, but please add a comment explaining the >>>> problem we are solving here. >>>> >>>> -Dmitry >>>> >>>> On 2015-03-03 16:15, Kevin Walls wrote: >>>>> Hi, >>>>> >>>>> This is a review request for a way to make the SA tools protect >>>>> themselves from infinite loops during initialisation. >>>>> >>>>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>>>> error - and filling a disk if being logged to a file. This reproduces >>>>> on a Solaris package based install, but not with other distribution >>>>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>>>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>>>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>>>> $ORIGIN, in preference to finding the already loaded libjvm.so. >>>>> >>>>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>>>> There are various things wrong with that. Protection against zero >>>>> strides through the type arrays and a maximum count for duplicated types >>>>> will protect us from a few possible problems. >>>>> >>>>> I'll also work a bug for the "install" repo where we create that >>>>> symlink, but the tools need to protect themselves from this kind of >>>>> problem. >>>>> >>>>> Testing was manual. >>>>> >>>>> bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>>>> >>>>> webrev >>>>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>>>> >>>>> Thanks >>>>> Kevin > From kevin.walls at oracle.com Wed Mar 4 14:14:25 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 04 Mar 2015 14:14:25 +0000 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <19919931-9C0D-4AA5-91DA-3A0110267FD4@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> <54F70395.1050200@oracle.com> <19919931-9C0D-4AA5-91DA-3A0110267FD4@oracle.com> Message-ID: <54F71341.1070004@oracle.com> Sure, I updated the webrev: http://cr.openjdk.java.net/~kevinw/8073688/webrev.01/ Thanks Kevin On 04/03/2015 14:05, Staffan Larsen wrote: >> On 4 mar 2015, at 14:07, Kevin Walls wrote: >> >> >> Hi Staffan -- >> >> staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase? Any doubt I will make it per HotSpotTypeDatabase. As I sometimes load multiple cores in kjdb, or load them multiple times, I should be encouraging less staticness in the SA overall: so yes let me remove that static! (updated webrev in same location) > Thanks. > >> >> Well spotted on the structs loop: 8-) >> readVMTypes, readVMntConstants, readVMLongConstants may increase, or call something could increase, the counter. >> readVMStructs does not. >> >> These are four methods that are so similar you'd imagine they should get merged into one method one day. It seemed wrong to me to make the four methods yet more different, by taking out the check on duplicateDefCount for one of them. >> >> Also, maybe readVMStructs should be checking for duplicates anyway, and maybe one day it will. I'm guessing it doesn't because it was harder in that method compared to the others. 8-) >> >> So I put it there for regularity, but if you think it's misleading I'll take it out. > Yes, please take it out. > > Thanks, > /Staffan > >> In practice, as long as we have the duplicate check in readVMTypes(), we have the protection we need as this is called first. It is highly unlikely that would succeed and another of the methods would fail, the other checks are just making the code consistent. >> >> Thanks >> Kevin >> >> >> >> On 04/03/2015 12:29, Staffan Larsen wrote: >>>> On 4 mar 2015, at 12:29, Kevin Walls wrote: >>>> >>>> Thanks Dmitry - >>>> >>>> I will explain the counter's presence where we introduce it: >>>> >>>> // Counter to ensure read loops terminate: >>>> private static final int MAX_DUPLICATE_DEFINITIONS = 100; >>>> private static int duplicateDefCount = 0; >>> Should duplicateDefCount really be static? >>> >>> For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify? >>> >>> /Staffan >>> >>>> Thanks >>>> Kevin >>>> >>>> >>>> On 03/03/2015 20:10, Dmitry Samersoff wrote: >>>>> Kevin, >>>>> >>>>> The fix looks good for me, but please add a comment explaining the >>>>> problem we are solving here. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2015-03-03 16:15, Kevin Walls wrote: >>>>>> Hi, >>>>>> >>>>>> This is a review request for a way to make the SA tools protect >>>>>> themselves from infinite loops during initialisation. >>>>>> >>>>>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>>>>> error - and filling a disk if being logged to a file. This reproduces >>>>>> on a Solaris package based install, but not with other distribution >>>>>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>>>>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>>>>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>>>>> $ORIGIN, in preference to finding the already loaded libjvm.so. >>>>>> >>>>>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>>>>> There are various things wrong with that. Protection against zero >>>>>> strides through the type arrays and a maximum count for duplicated types >>>>>> will protect us from a few possible problems. >>>>>> >>>>>> I'll also work a bug for the "install" repo where we create that >>>>>> symlink, but the tools need to protect themselves from this kind of >>>>>> problem. >>>>>> >>>>>> Testing was manual. >>>>>> >>>>>> bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>>>>> >>>>>> webrev >>>>>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>>>>> >>>>>> Thanks >>>>>> Kevin From staffan.larsen at oracle.com Wed Mar 4 15:17:35 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Mar 2015 16:17:35 +0100 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F71341.1070004@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> <54F70395.1050200@oracle.com> <19919931-9C0D-4AA5-91DA-3A0110267FD4@oracle.com> <54F71341.1070004@oracle.com> Message-ID: <569C8868-0C46-44BC-B546-DC3A7FDCA318@oracle.com> Looks good! Thanks, /Staffan > On 4 mar 2015, at 15:14, Kevin Walls wrote: > > > Sure, I updated the webrev: > > http://cr.openjdk.java.net/~kevinw/8073688/webrev.01/ > > Thanks > Kevin > > > On 04/03/2015 14:05, Staffan Larsen wrote: >>> On 4 mar 2015, at 14:07, Kevin Walls wrote: >>> >>> >>> Hi Staffan -- >>> >>> staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase? Any doubt I will make it per HotSpotTypeDatabase. As I sometimes load multiple cores in kjdb, or load them multiple times, I should be encouraging less staticness in the SA overall: so yes let me remove that static! (updated webrev in same location) >> Thanks. >> >>> >>> Well spotted on the structs loop: 8-) >>> readVMTypes, readVMntConstants, readVMLongConstants may increase, or call something could increase, the counter. >>> readVMStructs does not. >>> >>> These are four methods that are so similar you'd imagine they should get merged into one method one day. It seemed wrong to me to make the four methods yet more different, by taking out the check on duplicateDefCount for one of them. >>> >>> Also, maybe readVMStructs should be checking for duplicates anyway, and maybe one day it will. I'm guessing it doesn't because it was harder in that method compared to the others. 8-) >>> >>> So I put it there for regularity, but if you think it's misleading I'll take it out. >> Yes, please take it out. >> >> Thanks, >> /Staffan >> >>> In practice, as long as we have the duplicate check in readVMTypes(), we have the protection we need as this is called first. It is highly unlikely that would succeed and another of the methods would fail, the other checks are just making the code consistent. >>> >>> Thanks >>> Kevin >>> >>> >>> >>> On 04/03/2015 12:29, Staffan Larsen wrote: >>>>> On 4 mar 2015, at 12:29, Kevin Walls wrote: >>>>> >>>>> Thanks Dmitry - >>>>> >>>>> I will explain the counter's presence where we introduce it: >>>>> >>>>> // Counter to ensure read loops terminate: >>>>> private static final int MAX_DUPLICATE_DEFINITIONS = 100; >>>>> private static int duplicateDefCount = 0; >>>> Should duplicateDefCount really be static? >>>> >>>> For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify? >>>> >>>> /Staffan >>>> >>>>> Thanks >>>>> Kevin >>>>> >>>>> >>>>> On 03/03/2015 20:10, Dmitry Samersoff wrote: >>>>>> Kevin, >>>>>> >>>>>> The fix looks good for me, but please add a comment explaining the >>>>>> problem we are solving here. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2015-03-03 16:15, Kevin Walls wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This is a review request for a way to make the SA tools protect >>>>>>> themselves from infinite loops during initialisation. >>>>>>> >>>>>>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>>>>>> error - and filling a disk if being logged to a file. This reproduces >>>>>>> on a Solaris package based install, but not with other distribution >>>>>>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>>>>>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>>>>>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>>>>>> $ORIGIN, in preference to finding the already loaded libjvm.so. >>>>>>> >>>>>>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>>>>>> There are various things wrong with that. Protection against zero >>>>>>> strides through the type arrays and a maximum count for duplicated types >>>>>>> will protect us from a few possible problems. >>>>>>> >>>>>>> I'll also work a bug for the "install" repo where we create that >>>>>>> symlink, but the tools need to protect themselves from this kind of >>>>>>> problem. >>>>>>> >>>>>>> Testing was manual. >>>>>>> >>>>>>> bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>>>>>> >>>>>>> webrev >>>>>>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>>>>>> >>>>>>> Thanks >>>>>>> Kevin > From kevin.walls at oracle.com Wed Mar 4 15:54:31 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 04 Mar 2015 15:54:31 +0000 Subject: RFR: 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <569C8868-0C46-44BC-B546-DC3A7FDCA318@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> <54F70395.1050200@oracle.com> <19919931-9C0D-4AA5-91DA-3A0110267FD4@oracle.com> <54F71341.1070004@oracle.com> <569C8868-0C46-44BC-B546-DC3A7FDCA318@oracle.com> Message-ID: <54F72AB7.8020300@oracle.com> Thanks! From kevin.walls at oracle.com Wed Mar 4 17:41:26 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 04 Mar 2015 17:41:26 +0000 Subject: RFR (8u): 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <569C8868-0C46-44BC-B546-DC3A7FDCA318@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> <54F70395.1050200@oracle.com> <19919931-9C0D-4AA5-91DA-3A0110267FD4@oracle.com> <54F71341.1070004@oracle.com> <569C8868-0C46-44BC-B546-DC3A7FDCA318@oracle.com> Message-ID: <54F743C6.40706@oracle.com> Hi, While this is in memory: I'd like to request review for an 8u backport. The changeset imports cleanly into jdk8u/hs-dev/hotspot Thanks Kevin On 04/03/2015 15:17, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 4 mar 2015, at 15:14, Kevin Walls wrote: >> >> >> Sure, I updated the webrev: >> >> http://cr.openjdk.java.net/~kevinw/8073688/webrev.01/ >> >> Thanks >> Kevin >> >> >> On 04/03/2015 14:05, Staffan Larsen wrote: >>>> On 4 mar 2015, at 14:07, Kevin Walls wrote: >>>> >>>> >>>> Hi Staffan -- >>>> >>>> staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase? Any doubt I will make it per HotSpotTypeDatabase. As I sometimes load multiple cores in kjdb, or load them multiple times, I should be encouraging less staticness in the SA overall: so yes let me remove that static! (updated webrev in same location) >>> Thanks. >>> >>>> Well spotted on the structs loop: 8-) >>>> readVMTypes, readVMntConstants, readVMLongConstants may increase, or call something could increase, the counter. >>>> readVMStructs does not. >>>> >>>> These are four methods that are so similar you'd imagine they should get merged into one method one day. It seemed wrong to me to make the four methods yet more different, by taking out the check on duplicateDefCount for one of them. >>>> >>>> Also, maybe readVMStructs should be checking for duplicates anyway, and maybe one day it will. I'm guessing it doesn't because it was harder in that method compared to the others. 8-) >>>> >>>> So I put it there for regularity, but if you think it's misleading I'll take it out. >>> Yes, please take it out. >>> >>> Thanks, >>> /Staffan >>> >>>> In practice, as long as we have the duplicate check in readVMTypes(), we have the protection we need as this is called first. It is highly unlikely that would succeed and another of the methods would fail, the other checks are just making the code consistent. >>>> >>>> Thanks >>>> Kevin >>>> >>>> >>>> >>>> On 04/03/2015 12:29, Staffan Larsen wrote: >>>>>> On 4 mar 2015, at 12:29, Kevin Walls wrote: >>>>>> >>>>>> Thanks Dmitry - >>>>>> >>>>>> I will explain the counter's presence where we introduce it: >>>>>> >>>>>> // Counter to ensure read loops terminate: >>>>>> private static final int MAX_DUPLICATE_DEFINITIONS = 100; >>>>>> private static int duplicateDefCount = 0; >>>>> Should duplicateDefCount really be static? >>>>> >>>>> For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify? >>>>> >>>>> /Staffan >>>>> >>>>>> Thanks >>>>>> Kevin >>>>>> >>>>>> >>>>>> On 03/03/2015 20:10, Dmitry Samersoff wrote: >>>>>>> Kevin, >>>>>>> >>>>>>> The fix looks good for me, but please add a comment explaining the >>>>>>> problem we are solving here. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2015-03-03 16:15, Kevin Walls wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is a review request for a way to make the SA tools protect >>>>>>>> themselves from infinite loops during initialisation. >>>>>>>> >>>>>>>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>>>>>>> error - and filling a disk if being logged to a file. This reproduces >>>>>>>> on a Solaris package based install, but not with other distribution >>>>>>>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>>>>>>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>>>>>>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>>>>>>> $ORIGIN, in preference to finding the already loaded libjvm.so. >>>>>>>> >>>>>>>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>>>>>>> There are various things wrong with that. Protection against zero >>>>>>>> strides through the type arrays and a maximum count for duplicated types >>>>>>>> will protect us from a few possible problems. >>>>>>>> >>>>>>>> I'll also work a bug for the "install" repo where we create that >>>>>>>> symlink, but the tools need to protect themselves from this kind of >>>>>>>> problem. >>>>>>>> >>>>>>>> Testing was manual. >>>>>>>> >>>>>>>> bug >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>>>>>>> >>>>>>>> webrev >>>>>>>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Kevin From eamonn at mcmanus.net Wed Mar 4 17:42:56 2015 From: eamonn at mcmanus.net (Eamonn McManus) Date: Wed, 4 Mar 2015 09:42:56 -0800 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: <54F6C6B0.2040908@oracle.com> References: <54F5E108.3010902@oracle.com> <54F6C6B0.2040908@oracle.com> Message-ID: Thank you for updating the JEP text referencing JSR 255. Perhaps unsurprisingly I disagree with many of the differences between this proposal and the one we carefully thought out in JSR 255. Even though a lot has changed in the meanwhile, I don't see anything that invalidates our assumptions of the time. For reference, a snapshot of the JSR 255 javadoc is at http://hg.openjdk.java.net/jmx2/jmx2/file/f417598a7b72/javadoc. Unfortunately, it appears that the Mercurial server now serves these files as application/binary, probably because of the change here: http://mercurial.selenic.com/wiki/UpgradeNotes#A1.9.1:_guessmime.2C_revert_behavior_restored. To address some specific points: > would you care to elaborate what you find to be not "even correct Java"? As of Java 8, annotation elements cannot have null values so the "default null" clauses are nonsense. I have not seen any proposal to change this in Java 9. The @ManagedBean definition also has an obvious syntax error. > - ability to annotate fields turning them into attributes This might be useful for read-only attributes. I'd question whether it is useful for read/write attributes, because I think it will be very unusual for you to want neither validation of the new value nor behaviour to be triggered by the set. > - ability to provide metadata directly in the annotations, not relying > solely on inferring them from the annotated element I'm not sure what specifically this refers to. Do you mean for example that it is possible to add @ManagedAttribute to a method that does not look like getFoo() and nevertheless have the annotation say that the attribute is called foo? I don't see any particular advantage to that flexibility. The getFoo() pattern is already familiar, and having a second, completely different way of specifying the name just complicates the spec for not much benefit. > - missing @ManagedConstructor to expose a constructor We deliberately omitted this. The fact that MBeanConstructorInfo exists at all is in my opinion a mistake in the original JMX specification. What does it mean for an MBean to tell you how to construct another instance of itself? And if the purpose is to specify which constructors from this class are available to the MBean Server, there's no use for names and descriptions, and there's no particular advantage over just saying that all public constructors are available. > - optional 'service' argument to @ManagedBean annotation which will be > reflected in the descriptor's 'interfaceClassName' field to provide a > guidance about the recommended service interface when using > JMX.newMXBeanProxy() If you have such an interface, why wouldn't you just use it to define the MBean and dispense with annotations? Some other comments: * @ManagedBean. We called this @MBean because we also had an @MXBean annotation. That annotation exists today, but JSR 255 allowed it to be applied to a class as well as to an interface. It appears that @ManagedBean only defines MXBeans, which is a legitimate choice but, first, it should be called out more explicitly, and, second, wouldn't it then make sense to extend the existing @MXBean annotation? The specification is inconsistent as to whether the annotation is @ManagedBean or @MBean. I think it is a fair idea to have an objectName field, but the idea of randomly appending numbers to the name for disambiguation is broken. Something like @ObjectNameTemplate from JSR 255 is more appropriate. The text for the notifications() member references @TypeMapping but does not say what that is. The declared type is Notification[] and the text defines an annotation @Notification, but there is already a class called Notification in javax.management. I think that the simple "name=value" syntax used by JSR 255's @DescriptorFields is preferable to the unspecified and verbose type @Tag. I don't see an advantage to making people write @Tag(name = "foo", value = "bar") rather than just "foo=bar". This syntax is already present in the JMX spec, for example in the ImmutableDescriptor constructor. * @Notification. As I mentioned, you can't use that name. The first paragraph of the description is indecipherable. The NotificationSender interface is unspecified. Based on the example, I think it could potentially be a major usability improvement but it's hard to be sure. I think it's extremely ugly to propagate the misspelling clazz into an API where people will have to write it. Also, if it must extend Notification then it should be specified as Class. * @ManagedAttribute It's extremely strange for this to have getter and setter fields. Why wouldn't it just be applied to those methods? Promoting units from a descriptor field to a separate annotation member seems like a good idea. The specified value would be copied into the Descriptor. * @ManagedOperation I don't see any reason to allow the name to be different from the method name. It just complicates the spec. Instead of repeating a description member inside every annotation, JSR 255 defined a top-level @Description, which included elements for internationalization. Hardcoded strings are a step backwards. Defining Impact inside this annotation is questionable. I'd expect user code and possible future API changes to want to reference it independently of the annotation. Also, the JSR 255 enum Impact had methods to convert to and from the integer codes used by MBeanOperationInfo. * @ManagedParameter The text repeatedly says operation name and method name when it means parameter name. I assume that if the name member is empty then the parameter name from reflection is used, which since Java 8 could be the actual name of the parameter if the class was compiled with -parameters. * @RegistrationHandler It seems like an API smell for an annotation to say that it must be applied to methods with a certain signature. I think a much better approach would be to change the existing MBeanRegistration interface so that its methods have default implementations that do nothing. That removes the main reason that this interface is a pain: having to implement four methods when you're usually only interested in one. You could also add a preDeregister overload with MBeanServer and ObjectName parameters, again with a default implementation. ?amonn 2015-03-04 0:47 GMT-08:00 Jaroslav Bachorik : > On 4.3.2015 02:09, Eamonn McManus wrote: >> >> Could you explain what you mean by this, regarding the annotations >> that were already agreed on by the JSR 255 Expert Group: >> >> * Smaller scope compared to the proposed solution > > > This is a leftover from the previous proposal which had wider scope than > what is presented now. Still a few points remain. > > - ability to annotate fields turning them into attributes > - ability to provide metadata directly in the annotations, not relying > solely on inferring them from the annotated element > - missing @ManagedConstructor to expose a constructor > - optional 'service' argument to @ManagedBean annotation which will be > reflected in the descriptor's 'interfaceClassName' field to provide a > guidance about the recommended service interface when using > JMX.newMXBeanProxy() > >> * Conceptually in pre JDK7 era > > > I am afraid this relates more to the implementation - or at least the code I > was able to reconstruct from the repo history. Shouldn't be mentioned here. > >> >> I have a number of other comments, but procedurally I'm not sure what >> the precedent is for summarily discarding work previously done in the >> JCP on the same subject. I'd certainly have expected this JEP to start >> from that work, rather than proposing a starting point that isn't even >> correct Java. > > > Well, this is a draft review. The JSR 255 annotations work is not discarded. > It is mentioned in the alternatives. The purpose of the open review is to > find out whether it is ok to continue with proposed feature, modify it to > use eg. JSR 255 work or abandon it completely. > > -JB- > > >> >> ?amonn McManus, former JSR 255 Spec Lead >> >> 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik >> : >>> >>> >>> Hi all, >>> >>> Please review this draft JEP for JMX Specific Annotations for >>> Registration of Managed Resources: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8044507 >>> >>> Background: >>> Current mechanism of defining an MBean requires to provide an MBean >>> interface and its implementation. The interface and the implementation must >>> conform to the strict naming and visibility rules in order for the >>> introspection to be able to bind them. >>> >>> At least the same level of verbosity is required when adding an MBeanInfo >>> to generate MBean metadata. >>> >>> All this leads to a rather verbose code containing a lot of repeating >>> boilerplate parts even for the most simple MBean registrations. >>> >>> This JEP proposes to add a set of annotations for registration and >>> configuration of manageable resources (in other word 'MBeans'). These >>> annotations will be used to generate all the metadata necessary for a >>> resources to be accepted by the current JMX system. >>> >>> Thanks, >>> >>> -JB- > > From shanliang.jiang at oracle.com Wed Mar 4 18:07:15 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 04 Mar 2015 19:07:15 +0100 Subject: RFR: 8073148 "The server has decided to close this client connection" repeated continuously Message-ID: <54F749D3.9070700@oracle.com> Hi, Please review this fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8073148 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8073148/00/ A JMX server was called to close, it terminated at first its notification forwarder server, then closed its communication connection (RMI), but the closing thread was blocked at the connection termination, so a client fetch request would continue arriving and the server would reply immediately with 0 notification. The fix is to ask server to return null to a client fetching request in case of termination, this informs a ClientNotifForwarder of the server termination, so the client can safely stop fetching. The fix was tested in the environment where the bug was reported. Thanks, Shanliang From jaroslav.bachorik at oracle.com Wed Mar 4 18:38:31 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Mar 2015 19:38:31 +0100 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: References: <54F5E108.3010902@oracle.com> <54F6C6B0.2040908@oracle.com> Message-ID: <54F75127.4060205@oracle.com> Thanks for taking the time to review this. I apologize for the formatting mess - clearly the JIRA's markdown processor is rather confused with more extensive usage of the code blocks. On 4.3.2015 18:42, Eamonn McManus wrote: > Thank you for updating the JEP text referencing JSR 255. > > Perhaps unsurprisingly I disagree with many of the differences between > this proposal and the one we carefully thought out in JSR 255. Even > though a lot has changed in the meanwhile, I don't see anything that > invalidates our assumptions of the time. > > For reference, a snapshot of the JSR 255 javadoc is at > http://hg.openjdk.java.net/jmx2/jmx2/file/f417598a7b72/javadoc. > Unfortunately, it appears that the Mercurial server now serves these > files as application/binary, probably because of the change here: > http://mercurial.selenic.com/wiki/UpgradeNotes#A1.9.1:_guessmime.2C_revert_behavior_restored. > > To address some specific points: >> would you care to elaborate what you find to be not "even correct Java"? > > As of Java 8, annotation elements cannot have null values so the > "default null" clauses are nonsense. I have not seen any proposal to > change this in Java 9. The @ManagedBean definition also has an obvious > syntax error. Agreed. They should not be there. During the updates JIRA failed to update the field and I failed to notice that my edits didn't apply. > >> - ability to annotate fields turning them into attributes > > This might be useful for read-only attributes. I'd question whether it > is useful for read/write attributes, because I think it will be very > unusual for you to want neither validation of the new value nor > behaviour to be triggered by the set. On the other hand it gives the possibility to expose those read-only fields (eg. metrics or settings being immutable via JMX) without the necessity to conjure the getter. > >> - ability to provide metadata directly in the annotations, not relying >> solely on inferring them from the annotated element > > I'm not sure what specifically this refers to. Do you mean for example > that it is possible to add @ManagedAttribute to a method that does not > look like getFoo() and nevertheless have the annotation say that the > attribute is called foo? I don't see any particular advantage to that > flexibility. The getFoo() pattern is already familiar, and having a > second, completely different way of specifying the name just > complicates the spec for not much benefit. And yet it can be done in DynamicMBeans. My starting point was the attempt to give the user the same flexibility she would have if she were hand-crafting the various MBean*Info classes. > >> - missing @ManagedConstructor to expose a constructor > > We deliberately omitted this. The fact that MBeanConstructorInfo > exists at all is in my opinion a mistake in the original JMX > specification. What does it mean for an MBean to tell you how to > construct another instance of itself? And if the purpose is to specify > which constructors from this class are available to the MBean Server, > there's no use for names and descriptions, and there's no particular > advantage over just saying that all public constructors are available. I don't know the meaning. I was not involved in the inception of this API. My reasoning is that if you can do it by hand than it should probably be achievable by annotation as well. The other route would be deprecating the MBeanConstructorInfo now and removing it in a subsequent release. > >> - optional 'service' argument to @ManagedBean annotation which will be >> reflected in the descriptor's 'interfaceClassName' field to provide a >> guidance about the recommended service interface when using >> JMX.newMXBeanProxy() > > If you have such an interface, why wouldn't you just use it to define > the MBean and dispense with annotations? Mainly because the long term goal (beyond the scope of this JEP, anyway) would be to get users to slowly migrate to the annotation based M(X)Beans. Not giving them the chance to specify the service interface via annotations will mean keeping this dichotomy forever. > > Some other comments: > > * @ManagedBean. > > We called this @MBean because we also had an @MXBean annotation. That > annotation exists today, but JSR 255 allowed it to be applied to a > class as well as to an interface. It appears that @ManagedBean only > defines MXBeans, which is a legitimate choice but, first, it should be > called out more explicitly, and, second, wouldn't it then make sense > to extend the existing @MXBean annotation? I thought about this and extending an existing annotation is pretty sensitive from the compatibility PoV. Also, giving the annotation different meanings depending whether it is used on interface or class is rather wobbly. I am still open to suggestions for better naming, though. > > The specification is inconsistent as to whether the annotation is > @ManagedBean or @MBean. > > I think it is a fair idea to have an objectName field, but the idea of > randomly appending numbers to the name for disambiguation is broken. Ok. Valid point. > Something like @ObjectNameTemplate from JSR 255 is more appropriate. Yes, but it brings even more complexity. > > The text for the notifications() member references @TypeMapping but > does not say what that is. The declared type is Notification[] and the > text defines an annotation @Notification, but there is already a class > called Notification in javax.management. The annotations should be placed in a sub-package of "javax.management". The "javax.management" is pretty crowded already. > > I think that the simple "name=value" syntax used by JSR 255's > @DescriptorFields is preferable to the unspecified and verbose type > @Tag. I don't see an advantage to making people write @Tag(name = > "foo", value = "bar") rather than just "foo=bar". This syntax is > already present in the JMX spec, for example in the > ImmutableDescriptor constructor. IMO, having just plain text there will open door for spurious errors due to typos in delimiters. But that's just my experience. > > * @Notification. > > As I mentioned, you can't use that name. > > The first paragraph of the description is indecipherable. > > The NotificationSender interface is unspecified. Based on the example, > I think it could potentially be a major usability improvement but it's > hard to be sure. I can add this interface to the proposal. The reason for it not being explicitly specified is that it is still very prototypical. > > I think it's extremely ugly to propagate the misspelling clazz into an > API where people will have to write it. Also, if it must extend > Notification then it should be specified as Class Notification>. The problem is that using the rather obvious "type" creates confusion with the "types". I can't use "class", of course. I am not too happy about this name either but anything else will just be more verbose. > > * @ManagedAttribute > > It's extremely strange for this to have getter and setter fields. Why > wouldn't it just be applied to those methods? Less boilerplate. One wouldn't need to retype the whole @ManagedAttribute definition twice. > > Promoting units from a descriptor field to a separate annotation > member seems like a good idea. The specified value would be copied > into the Descriptor. Exactly. > > * @ManagedOperation > > I don't see any reason to allow the name to be different from the > method name. It just complicates the spec. Well, you can do it manually. But I am open here - it would be nice to hear from potential users whether this would make sense. > > Instead of repeating a description member inside every annotation, JSR > 255 defined a top-level @Description, which included elements for > internationalization. Hardcoded strings are a step backwards. Until we have support for providing the client locale to the JMX server any internationalization is rather illusionary. > > Defining Impact inside this annotation is questionable. I'd expect > user code and possible future API changes to want to reference it > independently of the annotation. Also, the JSR 255 enum Impact had > methods to convert to and from the integer codes used by > MBeanOperationInfo. Please, consider class packaging being transitional. The classes may change their locations during the draft review. > > * @ManagedParameter > > The text repeatedly says operation name and method name when it means > parameter name. I assume that if the name member is empty then the > parameter name from reflection is used, which since Java 8 could be > the actual name of the parameter if the class was compiled with > -parameters. Precisely. > > * @RegistrationHandler > > It seems like an API smell for an annotation to say that it must be > applied to methods with a certain signature. I think a much better > approach would be to change the existing MBeanRegistration interface > so that its methods have default implementations that do nothing. That > removes the main reason that this interface is a pain: having to > implement four methods when you're usually only interested in one. You > could also add a preDeregister overload with MBeanServer and > ObjectName parameters, again with a default implementation. Well, @ManagedAttribute must be applied to methods of certain signatures only, too. I wanted to avoid the necessity for the annotated M(X)Bean to implement any other JMX specific interfaces explicitly. Therefore I proposed this annotation. -JB- > > ?amonn > > > 2015-03-04 0:47 GMT-08:00 Jaroslav Bachorik : >> On 4.3.2015 02:09, Eamonn McManus wrote: >>> >>> Could you explain what you mean by this, regarding the annotations >>> that were already agreed on by the JSR 255 Expert Group: >>> >>> * Smaller scope compared to the proposed solution >> >> >> This is a leftover from the previous proposal which had wider scope than >> what is presented now. Still a few points remain. >> >> - ability to annotate fields turning them into attributes >> - ability to provide metadata directly in the annotations, not relying >> solely on inferring them from the annotated element >> - missing @ManagedConstructor to expose a constructor >> - optional 'service' argument to @ManagedBean annotation which will be >> reflected in the descriptor's 'interfaceClassName' field to provide a >> guidance about the recommended service interface when using >> JMX.newMXBeanProxy() >> >>> * Conceptually in pre JDK7 era >> >> >> I am afraid this relates more to the implementation - or at least the code I >> was able to reconstruct from the repo history. Shouldn't be mentioned here. >> >>> >>> I have a number of other comments, but procedurally I'm not sure what >>> the precedent is for summarily discarding work previously done in the >>> JCP on the same subject. I'd certainly have expected this JEP to start >>> from that work, rather than proposing a starting point that isn't even >>> correct Java. >> >> >> Well, this is a draft review. The JSR 255 annotations work is not discarded. >> It is mentioned in the alternatives. The purpose of the open review is to >> find out whether it is ok to continue with proposed feature, modify it to >> use eg. JSR 255 work or abandon it completely. >> >> -JB- >> >> >>> >>> ?amonn McManus, former JSR 255 Spec Lead >>> >>> 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik >>> : >>>> >>>> >>>> Hi all, >>>> >>>> Please review this draft JEP for JMX Specific Annotations for >>>> Registration of Managed Resources: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8044507 >>>> >>>> Background: >>>> Current mechanism of defining an MBean requires to provide an MBean >>>> interface and its implementation. The interface and the implementation must >>>> conform to the strict naming and visibility rules in order for the >>>> introspection to be able to bind them. >>>> >>>> At least the same level of verbosity is required when adding an MBeanInfo >>>> to generate MBean metadata. >>>> >>>> All this leads to a rather verbose code containing a lot of repeating >>>> boilerplate parts even for the most simple MBean registrations. >>>> >>>> This JEP proposes to add a set of annotations for registration and >>>> configuration of manageable resources (in other word 'MBeans'). These >>>> annotations will be used to generate all the metadata necessary for a >>>> resources to be accepted by the current JMX system. >>>> >>>> Thanks, >>>> >>>> -JB- >> >> From jaroslav.bachorik at oracle.com Wed Mar 4 18:41:36 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Mar 2015 19:41:36 +0100 Subject: jmx-dev RFR: 8073148 "The server has decided to close this client connection" repeated continuously In-Reply-To: <54F749D3.9070700@oracle.com> References: <54F749D3.9070700@oracle.com> Message-ID: <54F751E0.2030700@oracle.com> Hi Shanliang, This looks fine. I have few minor nits: * ClientNotifForwarder.java#544 - Should read "Received" instead of "Receives" * copyright year updates to both of files No need to re-review. -JB- On 4.3.2015 19:07, shanliang wrote: > Hi, > > Please review this fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073148 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8073148/00/ > > A JMX server was called to close, it terminated at first its > notification forwarder server, then closed its communication connection > (RMI), but the closing thread was blocked at the connection termination, > so a client fetch request would continue arriving and the server would > reply immediately with 0 notification. > > The fix is to ask server to return null to a client fetching request in > case of termination, this informs a ClientNotifForwarder of the server > termination, so the client can safely stop fetching. > > The fix was tested in the environment where the bug was reported. > > Thanks, > Shanliang From staffan.larsen at oracle.com Wed Mar 4 19:21:10 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Mar 2015 20:21:10 +0100 Subject: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole. Message-ID: The problem is that the makefiles do "cleanup" of the resource files, accidentally deleting half of some strings. In this case GC_INFO=Name = ''{0}'', Collections = {1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2} becomes GC_INFO=Name \= ''{0}'', Collections \= {1,choice,-1# The below diff fixes the problem. I added an extra ^ before the # so that only # at the beginning of the line are treated as comments. I don?t know if this has other implications, though? Should # anywhere on the line be treated as the beginning of a comment? In that case we need to handle the jconsole resource file specially. Thanks, /Staffan diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -393,7 +393,7 @@ $(MKDIR) -p $$(@D) export LC_ALL=C ; ( $(CAT) $$< && $(ECHO) "" ) \ | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ - -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ + -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \ | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ | $(SED) -e '/^#/d' -e '/^$$$$/d' \ -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ From staffan.larsen at oracle.com Wed Mar 4 19:21:41 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Mar 2015 20:21:41 +0100 Subject: RFR (8u): 8073688: Infinite loop reading types during jmap attach. In-Reply-To: <54F743C6.40706@oracle.com> References: <54F5B3F1.5070404@oracle.com> <54F6151B.7050106@oracle.com> <54F6EC99.5030102@oracle.com> <032B4CE2-1288-4A24-AB31-FAFD89B77574@oracle.com> <54F70395.1050200@oracle.com> <19919931-9C0D-4AA5-91DA-3A0110267FD4@oracle.com> <54F71341.1070004@oracle.com> <569C8868-0C46-44BC-B546-DC3A7FDCA318@oracle.com> <54F743C6.40706@oracle.com> Message-ID: <4BE78EF9-B23F-4639-B588-582234BABD8F@oracle.com> Ok with me. Thanks, /Staffan > On 4 mar 2015, at 18:41, Kevin Walls wrote: > > > Hi, > > While this is in memory: I'd like to request review for an 8u backport. > > The changeset imports cleanly into jdk8u/hs-dev/hotspot > > Thanks > Kevin > > > On 04/03/2015 15:17, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 4 mar 2015, at 15:14, Kevin Walls wrote: >>> >>> >>> Sure, I updated the webrev: >>> >>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.01/ >>> >>> Thanks >>> Kevin >>> >>> >>> On 04/03/2015 14:05, Staffan Larsen wrote: >>>>> On 4 mar 2015, at 14:07, Kevin Walls wrote: >>>>> >>>>> >>>>> Hi Staffan -- >>>>> >>>>> staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase? Any doubt I will make it per HotSpotTypeDatabase. As I sometimes load multiple cores in kjdb, or load them multiple times, I should be encouraging less staticness in the SA overall: so yes let me remove that static! (updated webrev in same location) >>>> Thanks. >>>> >>>>> Well spotted on the structs loop: 8-) >>>>> readVMTypes, readVMntConstants, readVMLongConstants may increase, or call something could increase, the counter. >>>>> readVMStructs does not. >>>>> >>>>> These are four methods that are so similar you'd imagine they should get merged into one method one day. It seemed wrong to me to make the four methods yet more different, by taking out the check on duplicateDefCount for one of them. >>>>> >>>>> Also, maybe readVMStructs should be checking for duplicates anyway, and maybe one day it will. I'm guessing it doesn't because it was harder in that method compared to the others. 8-) >>>>> >>>>> So I put it there for regularity, but if you think it's misleading I'll take it out. >>>> Yes, please take it out. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> In practice, as long as we have the duplicate check in readVMTypes(), we have the protection we need as this is called first. It is highly unlikely that would succeed and another of the methods would fail, the other checks are just making the code consistent. >>>>> >>>>> Thanks >>>>> Kevin >>>>> >>>>> >>>>> >>>>> On 04/03/2015 12:29, Staffan Larsen wrote: >>>>>>> On 4 mar 2015, at 12:29, Kevin Walls wrote: >>>>>>> >>>>>>> Thanks Dmitry - >>>>>>> >>>>>>> I will explain the counter's presence where we introduce it: >>>>>>> >>>>>>> // Counter to ensure read loops terminate: >>>>>>> private static final int MAX_DUPLICATE_DEFINITIONS = 100; >>>>>>> private static int duplicateDefCount = 0; >>>>>> Should duplicateDefCount really be static? >>>>>> >>>>>> For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify? >>>>>> >>>>>> /Staffan >>>>>> >>>>>>> Thanks >>>>>>> Kevin >>>>>>> >>>>>>> >>>>>>> On 03/03/2015 20:10, Dmitry Samersoff wrote: >>>>>>>> Kevin, >>>>>>>> >>>>>>>> The fix looks good for me, but please add a comment explaining the >>>>>>>> problem we are solving here. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2015-03-03 16:15, Kevin Walls wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is a review request for a way to make the SA tools protect >>>>>>>>> themselves from infinite loops during initialisation. >>>>>>>>> >>>>>>>>> Attaching jmap (for example) to a JVM can fail, infinitely writing an >>>>>>>>> error - and filling a disk if being logged to a file. This reproduces >>>>>>>>> on a Solaris package based install, but not with other distribution >>>>>>>>> bundles. In those packages, there's a link JDK/jre/lib/sparc/libjvm -> >>>>>>>>> client/libjvm.so. If a server/libjvm.so is loaded and running, we see >>>>>>>>> libverify.so pull in client/libjvm.so, as it finds the symlink in its >>>>>>>>> $ORIGIN, in preference to finding the already loaded libjvm.so. >>>>>>>>> >>>>>>>>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded. >>>>>>>>> There are various things wrong with that. Protection against zero >>>>>>>>> strides through the type arrays and a maximum count for duplicated types >>>>>>>>> will protect us from a few possible problems. >>>>>>>>> >>>>>>>>> I'll also work a bug for the "install" repo where we create that >>>>>>>>> symlink, but the tools need to protect themselves from this kind of >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> Testing was manual. >>>>>>>>> >>>>>>>>> bug >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8073688 >>>>>>>>> >>>>>>>>> webrev >>>>>>>>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Kevin > From jeremymanson at google.com Wed Mar 4 20:14:53 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 4 Mar 2015 12:14:53 -0800 Subject: Question about os::getenv() Message-ID: Hey folks, We had a request internally to make it so that JAVA_TOOL_OPTIONS could accept something longer than 1024 characters. See: Arguments::parse_options_environment_variable(const char* name, SysClassPath* scp_p, bool* scp_assembly_required_p) in http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/27f0413cbea3/src/share/vm/runtime/arguments.cpp Would you folks be amenable to a refactoring so that getenv returns a newly allocated array with the contents of the envvar, which the caller has to delete? Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Mar 4 20:58:33 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Mar 2015 12:58:33 -0800 Subject: Question about os::getenv() In-Reply-To: References: Message-ID: Why doesn't hotspot use plain C getenv ? On Wed, Mar 4, 2015 at 12:14 PM, Jeremy Manson wrote: > Hey folks, > > We had a request internally to make it so that JAVA_TOOL_OPTIONS could > accept something longer than 1024 characters. See: > > Arguments::parse_options_environment_variable(const char* name, > SysClassPath* scp_p, bool* scp_assembly_required_p) > > in > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/27f0413cbea3/src/share/vm/runtime/arguments.cpp > > Would you folks be amenable to a refactoring so that getenv returns a > newly allocated array with the contents of the envvar, which the caller has > to delete? > > Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Wed Mar 4 21:58:35 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 4 Mar 2015 13:58:35 -0800 Subject: Question about os::getenv() In-Reply-To: References: Message-ID: It doesn't work on Windows? Jeremy On Wed, Mar 4, 2015 at 12:58 PM, Martin Buchholz wrote: > Why doesn't hotspot use plain C getenv ? > > On Wed, Mar 4, 2015 at 12:14 PM, Jeremy Manson > wrote: > >> Hey folks, >> >> We had a request internally to make it so that JAVA_TOOL_OPTIONS could >> accept something longer than 1024 characters. See: >> >> Arguments::parse_options_environment_variable(const char* name, >> SysClassPath* scp_p, bool* scp_assembly_required_p) >> >> in >> >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/27f0413cbea3/src/share/vm/runtime/arguments.cpp >> >> Would you folks be amenable to a refactoring so that getenv returns a >> newly allocated array with the contents of the envvar, which the caller has >> to delete? >> >> Jeremy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Mar 4 22:42:15 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Mar 2015 14:42:15 -0800 Subject: Question about os::getenv() In-Reply-To: References: Message-ID: Sad Martin wonders why he still bothers, when all the software out there is so broken... Is it really true that on the latest Windows, C getenv is simply not available? I'd be OK with it returning NULL unconditionally... -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Mar 4 23:45:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Mar 2015 09:45:11 +1000 Subject: Question about os::getenv() In-Reply-To: References: Message-ID: <54F79907.9040700@oracle.com> Hi Jeremy, On 5/03/2015 6:14 AM, Jeremy Manson wrote: > Hey folks, > > We had a request internally to make it so that JAVA_TOOL_OPTIONS could > accept something longer than 1024 characters. See: > > Arguments::parse_options_environment_variable(const char* name, > SysClassPath* scp_p, bool* scp_assembly_required_p) > > in > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/27f0413cbea3/src/share/vm/runtime/arguments.cpp > > Would you folks be amenable to a refactoring so that getenv returns a > newly allocated array with the contents of the envvar, which the caller > has to delete? I think this gets used too early in the VM startup to use the VM's allocation routines (ie with NMT support) - not 100% sure though. But I think I have to agree with Martin and wonder why we have this copying interface around getenv, rather than using the result of getenv directly? Any code that really wants to modify the returned value can copy it for themselves. That would alleviate the hard wired limits. getenv is available on Windows too. David > Jeremy From jeremymanson at google.com Thu Mar 5 00:07:53 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 4 Mar 2015 16:07:53 -0800 Subject: Question about os::getenv() In-Reply-To: <54F79907.9040700@oracle.com> References: <54F79907.9040700@oracle.com> Message-ID: I'm happy to s/os::getenv/getenv/g if we know it works on Windows. I assumed that there was some safety / security reason for requiring the copying - otherwise, why does this interface exist at all? If everyone's happy about this, I'll go ahead and file a bug / send in a patch, with the understanding that someone else has to test on non-Linux platforms... Jeremy On Wed, Mar 4, 2015 at 3:45 PM, David Holmes wrote: > Hi Jeremy, > > > On 5/03/2015 6:14 AM, Jeremy Manson wrote: > >> Hey folks, >> >> We had a request internally to make it so that JAVA_TOOL_OPTIONS could >> accept something longer than 1024 characters. See: >> >> Arguments::parse_options_environment_variable(const char* name, >> SysClassPath* scp_p, bool* scp_assembly_required_p) >> >> in >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/ >> 27f0413cbea3/src/share/vm/runtime/arguments.cpp >> >> Would you folks be amenable to a refactoring so that getenv returns a >> newly allocated array with the contents of the envvar, which the caller >> has to delete? >> > > I think this gets used too early in the VM startup to use the VM's > allocation routines (ie with NMT support) - not 100% sure though. > > But I think I have to agree with Martin and wonder why we have this > copying interface around getenv, rather than using the result of getenv > directly? Any code that really wants to modify the returned value can copy > it for themselves. That would alleviate the hard wired limits. > > getenv is available on Windows too. > > David > > Jeremy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Mar 5 01:12:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Mar 2015 11:12:13 +1000 Subject: Question about os::getenv() In-Reply-To: References: <54F79907.9040700@oracle.com> Message-ID: <54F7AD6D.5040606@oracle.com> On 5/03/2015 10:07 AM, Jeremy Manson wrote: > I'm happy to s/os::getenv/getenv/g if we know it works on Windows. I > assumed that there was some safety / security reason for requiring the > copying - otherwise, why does this interface exist at all? I don't know. Someone else (perhaps on hotspot list rather than serviceability) may, but I'd have to do a bit of archaeology to find out. > If everyone's happy about this, I'll go ahead and file a bug / send in a > patch, with the understanding that someone else has to test on non-Linux > platforms... Sure. Do the patch and I'll run it through JPRT. If you need testing other than Solaris and Windows then others will need to step up. :) Cheers, David > Jeremy > > On Wed, Mar 4, 2015 at 3:45 PM, David Holmes > wrote: > > Hi Jeremy, > > > On 5/03/2015 6:14 AM, Jeremy Manson wrote: > > Hey folks, > > We had a request internally to make it so that JAVA_TOOL_OPTIONS > could > accept something longer than 1024 characters. See: > > Arguments::parse_options___environment_variable(const char* name, > SysClassPath* scp_p, bool* scp_assembly_required_p) > > in > > http://hg.openjdk.java.net/__jdk9/jdk9/hotspot/file/__27f0413cbea3/src/share/vm/__runtime/arguments.cpp > > > Would you folks be amenable to a refactoring so that getenv > returns a > newly allocated array with the contents of the envvar, which the > caller > has to delete? > > > I think this gets used too early in the VM startup to use the VM's > allocation routines (ie with NMT support) - not 100% sure though. > > But I think I have to agree with Martin and wonder why we have this > copying interface around getenv, rather than using the result of > getenv directly? Any code that really wants to modify the returned > value can copy it for themselves. That would alleviate the hard > wired limits. > > getenv is available on Windows too. > > David > > Jeremy > > From erik.joelsson at oracle.com Thu Mar 5 09:05:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Mar 2015 10:05:21 +0100 Subject: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole. In-Reply-To: References: Message-ID: <54F81C51.4070307@oracle.com> Hello, The specification for the properties file format says that a comment is a line that has either a ! or # as the first non whitespace character. Greping around in the source shows we have several instances if comments tarting a few spaces in. I don't think we are using ! for comments anywhere though. Using this expression seems to do the trick for me: 's/^[ ]*#.*/#/g' Note that the contents of the [] is one space and a literal tab as \t is not portable to all versions of sed that we use. The cleaning mechanism is hard to make really safe without semantic parsing. Have you considered using the CompileProperties option instead? For most of the resource bundles in the jdk, we convert the properties into java src. As I understand it, resource bundles work seamlessly as classes or properties files. I assume this is done for runtime performance. You could also choose to just copy the properties files instead of cleaning them, especially if there are no or few comments in them. /Erik On 2015-03-04 20:21, Staffan Larsen wrote: > The problem is that the makefiles do "cleanup" of the resource files, accidentally deleting half of some strings. In this case > > GC_INFO=Name = ''{0}'', Collections = {1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2} > > becomes > > GC_INFO=Name \= ''{0}'', Collections \= {1,choice,-1# > > The below diff fixes the problem. I added an extra ^ before the # so that only # at the beginning of the line are treated as comments. I don?t know if this has other implications, though? Should # anywhere on the line be treated as the beginning of a comment? In that case we need to handle the jconsole resource file specially. > > Thanks, > /Staffan > > > diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -393,7 +393,7 @@ > $(MKDIR) -p $$(@D) > export LC_ALL=C ; ( $(CAT) $$< && $(ECHO) "" ) \ > | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ > - -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ > + -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \ > | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ > | $(SED) -e '/^#/d' -e '/^$$$$/d' \ > -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ From jaroslav.bachorik at oracle.com Thu Mar 5 10:37:37 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Mar 2015 11:37:37 +0100 Subject: RFR 8074041: 8074041: sun/management/jmxremote/startstop/JMXStartStopTest.java fails with InvocationTargetException Message-ID: <54F831F1.4080606@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8074041 Webrev: http://cr.openjdk.java.net/~jbachorik/8074041/webrev.00 This test fails very intermittently still and the failure is very hard to reproduce. Based on the symptoms the probable cause seems to be the asynchronous processing of a launched process stdout and stderr. The test is using ProcessTools.startProcess(...) to start the target process and process its output (stdout/stderr) to mark the occurrence of the expected test. When the target process has finished the test will check the mark to assert the correctness. However, it may happen that the assertion happens in the time interval between the target process finishing (process.waitFor() returns) and the asynchronous stderr/stdout processors had the chance to dispatch the target process output to the processor checking for the occurrence of the expected test. The proposed fix is to wrap the Process instance into a wrapper enhancing the waitFor() method with the wait for the stdout/stderr processor being finished before proceeding. I ran the test in a tight loop for 1000 times after applying this patch without any failure. Thanks, -JB- From staffan.larsen at oracle.com Thu Mar 5 10:37:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 5 Mar 2015 11:37:53 +0100 Subject: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole. In-Reply-To: <54F81C51.4070307@oracle.com> References: <54F81C51.4070307@oracle.com> Message-ID: <1CC01E7D-58A9-47E3-8311-7DB2127D8C49@oracle.com> Your expression looks good to me (and I verified that it solved the jconsole bug). I will push that. Thanks, /Staffan > On 5 mar 2015, at 10:05, Erik Joelsson wrote: > > Hello, > > The specification for the properties file format says that a comment is a line that has either a ! or # as the first non whitespace character. Greping around in the source shows we have several instances if comments tarting a few spaces in. I don't think we are using ! for comments anywhere though. Using this expression seems to do the trick for me: > > 's/^[ ]*#.*/#/g' > > Note that the contents of the [] is one space and a literal tab as \t is not portable to all versions of sed that we use. > > The cleaning mechanism is hard to make really safe without semantic parsing. Have you considered using the CompileProperties option instead? For most of the resource bundles in the jdk, we convert the properties into java src. As I understand it, resource bundles work seamlessly as classes or properties files. I assume this is done for runtime performance. You could also choose to just copy the properties files instead of cleaning them, especially if there are no or few comments in them. > > /Erik > > On 2015-03-04 20:21, Staffan Larsen wrote: >> The problem is that the makefiles do "cleanup" of the resource files, accidentally deleting half of some strings. In this case >> >> GC_INFO=Name = ''{0}'', Collections = {1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2} >> >> becomes >> >> GC_INFO=Name \= ''{0}'', Collections \= {1,choice,-1# >> >> The below diff fixes the problem. I added an extra ^ before the # so that only # at the beginning of the line are treated as comments. I don?t know if this has other implications, though? Should # anywhere on the line be treated as the beginning of a comment? In that case we need to handle the jconsole resource file specially. >> >> Thanks, >> /Staffan >> >> >> diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk >> --- a/make/common/JavaCompilation.gmk >> +++ b/make/common/JavaCompilation.gmk >> @@ -393,7 +393,7 @@ >> $(MKDIR) -p $$(@D) >> export LC_ALL=C ; ( $(CAT) $$< && $(ECHO) "" ) \ >> | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >> - -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >> + -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \ >> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ > From daniel.fuchs at oracle.com Thu Mar 5 12:37:57 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Mar 2015 13:37:57 +0100 Subject: jmx-dev RFR: 8073148 "The server has decided to close this client connection" repeated continuously In-Reply-To: <54F751E0.2030700@oracle.com> References: <54F749D3.9070700@oracle.com> <54F751E0.2030700@oracle.com> Message-ID: <54F84E25.3060403@oracle.com> Looks good to me too Shanliang. -- daniel On 04/03/15 19:41, Jaroslav Bachorik wrote: > Hi Shanliang, > > This looks fine. > > I have few minor nits: > * ClientNotifForwarder.java#544 - Should read "Received" instead of > "Receives" > * copyright year updates to both of files > > > No need to re-review. > > -JB- > > On 4.3.2015 19:07, shanliang wrote: >> Hi, >> >> Please review this fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073148 >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8073148/00/ >> >> A JMX server was called to close, it terminated at first its >> notification forwarder server, then closed its communication connection >> (RMI), but the closing thread was blocked at the connection termination, >> so a client fetch request would continue arriving and the server would >> reply immediately with 0 notification. >> >> The fix is to ask server to return null to a client fetching request in >> case of termination, this informs a ClientNotifForwarder of the server >> termination, so the client can safely stop fetching. >> >> The fix was tested in the environment where the bug was reported. >> >> Thanks, >> Shanliang > From jeremymanson at google.com Thu Mar 5 18:10:54 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 5 Mar 2015 10:10:54 -0800 Subject: Question about os::getenv() In-Reply-To: <54F7AD6D.5040606@oracle.com> References: <54F79907.9040700@oracle.com> <54F7AD6D.5040606@oracle.com> Message-ID: Martin points out that getenv on Windows isn't portable (which is to say, it doesn't work on WindowsRT). Do we care? If so, then I'll have os::getenv do an allocation on Windows, and have it return a unique pointer like thing. (Of course, I have no way of testing that). Jeremy On Wed, Mar 4, 2015 at 5:12 PM, David Holmes wrote: > On 5/03/2015 10:07 AM, Jeremy Manson wrote: > >> I'm happy to s/os::getenv/getenv/g if we know it works on Windows. I >> assumed that there was some safety / security reason for requiring the >> copying - otherwise, why does this interface exist at all? >> > > I don't know. Someone else (perhaps on hotspot list rather than > serviceability) may, but I'd have to do a bit of archaeology to find out. > > If everyone's happy about this, I'll go ahead and file a bug / send in a >> patch, with the understanding that someone else has to test on non-Linux >> platforms... >> > > Sure. Do the patch and I'll run it through JPRT. If you need testing other > than Solaris and Windows then others will need to step up. :) > > Cheers, > David > > Jeremy >> >> On Wed, Mar 4, 2015 at 3:45 PM, David Holmes > > wrote: >> >> Hi Jeremy, >> >> >> On 5/03/2015 6:14 AM, Jeremy Manson wrote: >> >> Hey folks, >> >> We had a request internally to make it so that JAVA_TOOL_OPTIONS >> could >> accept something longer than 1024 characters. See: >> >> Arguments::parse_options___environment_variable(const char* name, >> SysClassPath* scp_p, bool* scp_assembly_required_p) >> >> in >> >> http://hg.openjdk.java.net/__jdk9/jdk9/hotspot/file/__ >> 27f0413cbea3/src/share/vm/__runtime/arguments.cpp >> > 27f0413cbea3/src/share/vm/runtime/arguments.cpp> >> >> Would you folks be amenable to a refactoring so that getenv >> returns a >> newly allocated array with the contents of the envvar, which the >> caller >> has to delete? >> >> >> I think this gets used too early in the VM startup to use the VM's >> allocation routines (ie with NMT support) - not 100% sure though. >> >> But I think I have to agree with Martin and wonder why we have this >> copying interface around getenv, rather than using the result of >> getenv directly? Any code that really wants to modify the returned >> value can copy it for themselves. That would alleviate the hard >> wired limits. >> >> getenv is available on Windows too. >> >> David >> >> Jeremy >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Mar 5 21:03:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Mar 2015 07:03:31 +1000 Subject: Question about os::getenv() In-Reply-To: References: <54F79907.9040700@oracle.com> <54F7AD6D.5040606@oracle.com> Message-ID: <54F8C4A3.5040903@oracle.com> On 6/03/2015 4:10 AM, Jeremy Manson wrote: > Martin points out that getenv on Windows isn't portable (which is to > say, it doesn't work on WindowsRT). Do we care? If so, then I'll have > os::getenv do an allocation on Windows, and have it return a unique > pointer like thing. (Of course, I have no way of testing that). Many of the win32 APIs we use in the VM are not available in WindowsRT. So I don't think that is an issue. David ----- > Jeremy > > On Wed, Mar 4, 2015 at 5:12 PM, David Holmes > wrote: > > On 5/03/2015 10:07 AM, Jeremy Manson wrote: > > I'm happy to s/os::getenv/getenv/g if we know it works on > Windows. I > assumed that there was some safety / security reason for > requiring the > copying - otherwise, why does this interface exist at all? > > > I don't know. Someone else (perhaps on hotspot list rather than > serviceability) may, but I'd have to do a bit of archaeology to find > out. > > If everyone's happy about this, I'll go ahead and file a bug / > send in a > patch, with the understanding that someone else has to test on > non-Linux > platforms... > > > Sure. Do the patch and I'll run it through JPRT. If you need testing > other than Solaris and Windows then others will need to step up. :) > > Cheers, > David > > Jeremy > > On Wed, Mar 4, 2015 at 3:45 PM, David Holmes > > >> wrote: > > Hi Jeremy, > > > On 5/03/2015 6:14 AM, Jeremy Manson wrote: > > Hey folks, > > We had a request internally to make it so that > JAVA_TOOL_OPTIONS > could > accept something longer than 1024 characters. See: > > Arguments::parse_options_____environment_variable(const > char* name, > SysClassPath* scp_p, bool* scp_assembly_required_p) > > in > > http://hg.openjdk.java.net/____jdk9/jdk9/hotspot/file/____27f0413cbea3/src/share/vm/____runtime/arguments.cpp > > > > > > Would you folks be amenable to a refactoring so that getenv > returns a > newly allocated array with the contents of the envvar, > which the > caller > has to delete? > > > I think this gets used too early in the VM startup to use > the VM's > allocation routines (ie with NMT support) - not 100% sure > though. > > But I think I have to agree with Martin and wonder why we > have this > copying interface around getenv, rather than using the > result of > getenv directly? Any code that really wants to modify the > returned > value can copy it for themselves. That would alleviate the hard > wired limits. > > getenv is available on Windows too. > > David > > Jeremy > > > From david.holmes at oracle.com Fri Mar 6 07:20:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Mar 2015 17:20:33 +1000 Subject: Question about os::getenv() In-Reply-To: <54F7AD6D.5040606@oracle.com> References: <54F79907.9040700@oracle.com> <54F7AD6D.5040606@oracle.com> Message-ID: <54F95541.70501@oracle.com> On 5/03/2015 11:12 AM, David Holmes wrote: > On 5/03/2015 10:07 AM, Jeremy Manson wrote: >> I'm happy to s/os::getenv/getenv/g if we know it works on Windows. I >> assumed that there was some safety / security reason for requiring the >> copying - otherwise, why does this interface exist at all? > > I don't know. Someone else (perhaps on hotspot list rather than > serviceability) may, but I'd have to do a bit of archaeology to find out. Arguments::parse_options_environment_variable itself requires a copy as it rewrites the value of the variable in to the format needed. I also checked back and in 1.3 we used getenv but then applied strdup (and win32 used getenv too). But when hotspot turned up in 1.4 it has the os::getenv copying into a supplied buffer. Cheers, David >> If everyone's happy about this, I'll go ahead and file a bug / send in a >> patch, with the understanding that someone else has to test on non-Linux >> platforms... > > Sure. Do the patch and I'll run it through JPRT. If you need testing > other than Solaris and Windows then others will need to step up. :) > > Cheers, > David > >> Jeremy >> >> On Wed, Mar 4, 2015 at 3:45 PM, David Holmes > > wrote: >> >> Hi Jeremy, >> >> >> On 5/03/2015 6:14 AM, Jeremy Manson wrote: >> >> Hey folks, >> >> We had a request internally to make it so that JAVA_TOOL_OPTIONS >> could >> accept something longer than 1024 characters. See: >> >> Arguments::parse_options___environment_variable(const char* name, >> SysClassPath* scp_p, bool* scp_assembly_required_p) >> >> in >> >> >> http://hg.openjdk.java.net/__jdk9/jdk9/hotspot/file/__27f0413cbea3/src/share/vm/__runtime/arguments.cpp >> >> >> >> >> >> Would you folks be amenable to a refactoring so that getenv >> returns a >> newly allocated array with the contents of the envvar, which the >> caller >> has to delete? >> >> >> I think this gets used too early in the VM startup to use the VM's >> allocation routines (ie with NMT support) - not 100% sure though. >> >> But I think I have to agree with Martin and wonder why we have this >> copying interface around getenv, rather than using the result of >> getenv directly? Any code that really wants to modify the returned >> value can copy it for themselves. That would alleviate the hard >> wired limits. >> >> getenv is available on Windows too. >> >> David >> >> Jeremy >> >> From jaroslav.bachorik at oracle.com Fri Mar 6 16:08:58 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 06 Mar 2015 17:08:58 +0100 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java Message-ID: <54F9D11A.5070702@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 As the issue subject states this test is susceptible to race condition. Firstly, it uses an arbitrary time period to wait after a thread has signalled its exit vie the associated barrier to 'make sure' the thread is actually terminated when the check for the number of live threads is performed. This is quite race prone and should be replaces by Thread.join() performed on the specified threads before moving forward and checking the reported thread counts. Secondly, it is using a volatile array of boolean flags which are used for communication between the main thread and the test threads (setting an item of this array true will indicate the appropriate test thread to exit). Declaring the array as volatile does nothing for the thread safety and reads and writes to this array must be properly synchronized. I also took the liberty of replacing the arbitrary Barrier synchronization class with the standard Semaphore. Thanks, -JB- From daniel.fuchs at oracle.com Fri Mar 6 16:22:21 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 06 Mar 2015 17:22:21 +0100 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54F9D11A.5070702@oracle.com> References: <54F9D11A.5070702@oracle.com> Message-ID: <54F9D43D.2050406@oracle.com> Hi Jaroslav, Looks reasonable to me. Not sure why you replaced Barrier with Semaphore but I don't really mind. best regards, -- daniel On 06/03/15 17:08, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 > Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 > > As the issue subject states this test is susceptible to race condition. > Firstly, it uses an arbitrary time period to wait after a thread has > signalled its exit vie the associated barrier to 'make sure' the thread > is actually terminated when the check for the number of live threads is > performed. This is quite race prone and should be replaces by > Thread.join() performed on the specified threads before moving forward > and checking the reported thread counts. > > Secondly, it is using a volatile array of boolean flags which are used > for communication between the main thread and the test threads (setting > an item of this array true will indicate the appropriate test thread to > exit). Declaring the array as volatile does nothing for the thread > safety and reads and writes to this array must be properly synchronized. > > I also took the liberty of replacing the arbitrary Barrier > synchronization class with the standard Semaphore. > > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Fri Mar 6 16:25:31 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 06 Mar 2015 17:25:31 +0100 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54F9D43D.2050406@oracle.com> References: <54F9D11A.5070702@oracle.com> <54F9D43D.2050406@oracle.com> Message-ID: <54F9D4FB.3030907@oracle.com> On 6.3.2015 17:22, Daniel Fuchs wrote: > Hi Jaroslav, > > Looks reasonable to me. Not sure why you replaced Barrier with > Semaphore but I don't really mind. Well, this goes in line with the recent fixes where it was recommended to me to switch from using the test-only concurrent primitives to the standard java.util.concurrent counterparts. I tried to replace the Barrier with CyclicBarrier but the usage didn't map well. The easiest to migrate and the easiest to understand was Semaphore. -JB- > > best regards, > > -- daniel > > On 06/03/15 17:08, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >> >> As the issue subject states this test is susceptible to race condition. >> Firstly, it uses an arbitrary time period to wait after a thread has >> signalled its exit vie the associated barrier to 'make sure' the thread >> is actually terminated when the check for the number of live threads is >> performed. This is quite race prone and should be replaces by >> Thread.join() performed on the specified threads before moving forward >> and checking the reported thread counts. >> >> Secondly, it is using a volatile array of boolean flags which are used >> for communication between the main thread and the test threads (setting >> an item of this array true will indicate the appropriate test thread to >> exit). Declaring the array as volatile does nothing for the thread >> safety and reads and writes to this array must be properly synchronized. >> >> I also took the liberty of replacing the arbitrary Barrier >> synchronization class with the standard Semaphore. >> >> >> Thanks, >> >> -JB- > From david.holmes at oracle.com Sun Mar 8 13:32:07 2015 From: david.holmes at oracle.com (David Holmes) Date: Sun, 08 Mar 2015 23:32:07 +1000 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54F9D11A.5070702@oracle.com> References: <54F9D11A.5070702@oracle.com> Message-ID: <54FC4F57.70604@oracle.com> Hi Jaroslav, A couple of quick comments ... On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 > Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 > > As the issue subject states this test is susceptible to race condition. > Firstly, it uses an arbitrary time period to wait after a thread has > signalled its exit vie the associated barrier to 'make sure' the thread > is actually terminated when the check for the number of live threads is > performed. This is quite race prone and should be replaces by > Thread.join() performed on the specified threads before moving forward > and checking the reported thread counts. So now you do the join() why do you still also have an acquire() preceding the join(s) ? Also what exactly do those counters check? Even after join() can return the thread may still be in the Threads_list. David > Secondly, it is using a volatile array of boolean flags which are used > for communication between the main thread and the test threads (setting > an item of this array true will indicate the appropriate test thread to > exit). Declaring the array as volatile does nothing for the thread > safety and reads and writes to this array must be properly synchronized. > > I also took the liberty of replacing the arbitrary Barrier > synchronization class with the standard Semaphore. > > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Mar 9 07:37:34 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 09 Mar 2015 08:37:34 +0100 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54FC4F57.70604@oracle.com> References: <54F9D11A.5070702@oracle.com> <54FC4F57.70604@oracle.com> Message-ID: <54FD4DBE.1070803@oracle.com> On 8.3.2015 14:32, David Holmes wrote: > Hi Jaroslav, > > A couple of quick comments ... > > On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >> >> As the issue subject states this test is susceptible to race condition. >> Firstly, it uses an arbitrary time period to wait after a thread has >> signalled its exit vie the associated barrier to 'make sure' the thread >> is actually terminated when the check for the number of live threads is >> performed. This is quite race prone and should be replaces by >> Thread.join() performed on the specified threads before moving forward >> and checking the reported thread counts. > > So now you do the join() why do you still also have an acquire() > preceding the join(s) ? Touch? - I guess I just didn't want to mess with the test too much. I suppose joining the threads that are expected to die should suffice. > > Also what exactly do those counters check? Even after join() can return > the thread may still be in the Threads_list. The test is supposed to test whether ThreadMXBean reports correct numbers for the total number of started/finished threads and the number of threads being currently alive. Thread#join() should return only when the thread is not alive any more. The ThreadMXBean#getAllThreadIds() should return the IDs of only the threads being alive at the time the method was invoked. I didn't dig into the implementation - but according to the information available through javadocs this should work. -JB- > > David > >> Secondly, it is using a volatile array of boolean flags which are used >> for communication between the main thread and the test threads (setting >> an item of this array true will indicate the appropriate test thread to >> exit). Declaring the array as volatile does nothing for the thread >> safety and reads and writes to this array must be properly synchronized. >> >> I also took the liberty of replacing the arbitrary Barrier >> synchronization class with the standard Semaphore. >> >> >> Thanks, >> >> -JB- From david.holmes at oracle.com Mon Mar 9 11:15:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Mar 2015 21:15:09 +1000 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54FD4DBE.1070803@oracle.com> References: <54F9D11A.5070702@oracle.com> <54FC4F57.70604@oracle.com> <54FD4DBE.1070803@oracle.com> Message-ID: <54FD80BD.8040906@oracle.com> On 9/03/2015 5:37 PM, Jaroslav Bachorik wrote: > On 8.3.2015 14:32, David Holmes wrote: >> Hi Jaroslav, >> >> A couple of quick comments ... >> >> On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >>> >>> As the issue subject states this test is susceptible to race condition. >>> Firstly, it uses an arbitrary time period to wait after a thread has >>> signalled its exit vie the associated barrier to 'make sure' the thread >>> is actually terminated when the check for the number of live threads is >>> performed. This is quite race prone and should be replaces by >>> Thread.join() performed on the specified threads before moving forward >>> and checking the reported thread counts. >> >> So now you do the join() why do you still also have an acquire() >> preceding the join(s) ? > > Touch? - I guess I just didn't want to mess with the test too much. I > suppose joining the threads that are expected to die should suffice. Yes. >> >> Also what exactly do those counters check? Even after join() can return >> the thread may still be in the Threads_list. > > The test is supposed to test whether ThreadMXBean reports correct > numbers for the total number of started/finished threads and the number > of threads being currently alive. > > Thread#join() should return only when the thread is not alive any more. > The ThreadMXBean#getAllThreadIds() should return the IDs of only the > threads being alive at the time the method was invoked. I didn't dig > into the implementation - but according to the information available > through javadocs this should work. It is the actual implementation I'm concerned about - to ensure the notions of "alive" actually match. David > -JB- > >> >> David >> >>> Secondly, it is using a volatile array of boolean flags which are used >>> for communication between the main thread and the test threads (setting >>> an item of this array true will indicate the appropriate test thread to >>> exit). Declaring the array as volatile does nothing for the thread >>> safety and reads and writes to this array must be properly synchronized. >>> >>> I also took the liberty of replacing the arbitrary Barrier >>> synchronization class with the standard Semaphore. >>> >>> >>> Thanks, >>> >>> -JB- > From jaroslav.bachorik at oracle.com Mon Mar 9 12:41:33 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 09 Mar 2015 13:41:33 +0100 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54FD80BD.8040906@oracle.com> References: <54F9D11A.5070702@oracle.com> <54FC4F57.70604@oracle.com> <54FD4DBE.1070803@oracle.com> <54FD80BD.8040906@oracle.com> Message-ID: <54FD94FD.4030900@oracle.com> Hi David, On 9.3.2015 12:15, David Holmes wrote: > On 9/03/2015 5:37 PM, Jaroslav Bachorik wrote: >> On 8.3.2015 14:32, David Holmes wrote: >>> Hi Jaroslav, >>> >>> A couple of quick comments ... >>> >>> On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >>>> >>>> As the issue subject states this test is susceptible to race condition. >>>> Firstly, it uses an arbitrary time period to wait after a thread has >>>> signalled its exit vie the associated barrier to 'make sure' the thread >>>> is actually terminated when the check for the number of live threads is >>>> performed. This is quite race prone and should be replaces by >>>> Thread.join() performed on the specified threads before moving forward >>>> and checking the reported thread counts. >>> >>> So now you do the join() why do you still also have an acquire() >>> preceding the join(s) ? >> >> Touch? - I guess I just didn't want to mess with the test too much. I >> suppose joining the threads that are expected to die should suffice. > > Yes. > >>> >>> Also what exactly do those counters check? Even after join() can return >>> the thread may still be in the Threads_list. >> >> The test is supposed to test whether ThreadMXBean reports correct >> numbers for the total number of started/finished threads and the number >> of threads being currently alive. >> >> Thread#join() should return only when the thread is not alive any more. >> The ThreadMXBean#getAllThreadIds() should return the IDs of only the >> threads being alive at the time the method was invoked. I didn't dig >> into the implementation - but according to the information available >> through javadocs this should work. > > It is the actual implementation I'm concerned about - to ensure the > notions of "alive" actually match. Invoking ThreadMXBean#getAllThreadIds() will eventually mean creating a ThreadsListEnumerator (in threadService.cpp#941) and this enumerator will skip any threads where `Thread.isAlive() == false`. The Thread.join() method is using Thread.isAlive() to assert the thread state and exits only when `Thread.isAlive() == false`. Therefore, a thread T can't be in the list of live threads generated after T.join() has returned. -JB- > > David > >> -JB- >> >>> >>> David >>> >>>> Secondly, it is using a volatile array of boolean flags which are used >>>> for communication between the main thread and the test threads (setting >>>> an item of this array true will indicate the appropriate test thread to >>>> exit). Declaring the array as volatile does nothing for the thread >>>> safety and reads and writes to this array must be properly >>>> synchronized. >>>> >>>> I also took the liberty of replacing the arbitrary Barrier >>>> synchronization class with the standard Semaphore. >>>> >>>> >>>> Thanks, >>>> >>>> -JB- >> From jaroslav.bachorik at oracle.com Mon Mar 9 13:26:04 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 09 Mar 2015 14:26:04 +0100 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54FD94FD.4030900@oracle.com> References: <54F9D11A.5070702@oracle.com> <54FC4F57.70604@oracle.com> <54FD4DBE.1070803@oracle.com> <54FD80BD.8040906@oracle.com> <54FD94FD.4030900@oracle.com> Message-ID: <54FD9F6C.80000@oracle.com> On 9.3.2015 13:41, Jaroslav Bachorik wrote: > Hi David, > > On 9.3.2015 12:15, David Holmes wrote: >> On 9/03/2015 5:37 PM, Jaroslav Bachorik wrote: >>> On 8.3.2015 14:32, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> A couple of quick comments ... >>>> >>>> On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >>>>> >>>>> As the issue subject states this test is susceptible to race >>>>> condition. >>>>> Firstly, it uses an arbitrary time period to wait after a thread has >>>>> signalled its exit vie the associated barrier to 'make sure' the >>>>> thread >>>>> is actually terminated when the check for the number of live >>>>> threads is >>>>> performed. This is quite race prone and should be replaces by >>>>> Thread.join() performed on the specified threads before moving forward >>>>> and checking the reported thread counts. >>>> >>>> So now you do the join() why do you still also have an acquire() >>>> preceding the join(s) ? >>> >>> Touch? - I guess I just didn't want to mess with the test too much. I >>> suppose joining the threads that are expected to die should suffice. >> >> Yes. Here is the simplified webrev - http://cr.openjdk.java.net/~jbachorik/6712222/webrev.01 Now, when it is sufficient to synchronize only on the threads startup I can use Phaser instead of Semaphore and make the code a further bit more readable. -JB- >> >>>> >>>> Also what exactly do those counters check? Even after join() can return >>>> the thread may still be in the Threads_list. >>> >>> The test is supposed to test whether ThreadMXBean reports correct >>> numbers for the total number of started/finished threads and the number >>> of threads being currently alive. >>> >>> Thread#join() should return only when the thread is not alive any more. >>> The ThreadMXBean#getAllThreadIds() should return the IDs of only the >>> threads being alive at the time the method was invoked. I didn't dig >>> into the implementation - but according to the information available >>> through javadocs this should work. >> >> It is the actual implementation I'm concerned about - to ensure the >> notions of "alive" actually match. > > Invoking ThreadMXBean#getAllThreadIds() will eventually mean creating a > ThreadsListEnumerator (in threadService.cpp#941) and this enumerator > will skip any threads where `Thread.isAlive() == false`. The > Thread.join() method is using Thread.isAlive() to assert the thread > state and exits only when `Thread.isAlive() == false`. Therefore, a > thread T can't be in the list of live threads generated after T.join() > has returned. > > -JB- > >> >> David >> >>> -JB- >>> >>>> >>>> David >>>> >>>>> Secondly, it is using a volatile array of boolean flags which are used >>>>> for communication between the main thread and the test threads >>>>> (setting >>>>> an item of this array true will indicate the appropriate test >>>>> thread to >>>>> exit). Declaring the array as volatile does nothing for the thread >>>>> safety and reads and writes to this array must be properly >>>>> synchronized. >>>>> >>>>> I also took the liberty of replacing the arbitrary Barrier >>>>> synchronization class with the standard Semaphore. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> > From jaroslav.bachorik at oracle.com Mon Mar 9 18:40:39 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 09 Mar 2015 19:40:39 +0100 Subject: RFR 8049696: com/sun/jdi/RunToExit fails with "ConnectException: Connection refused" Message-ID: <54FDE927.4040904@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8049696 Webrev: http://cr.openjdk.java.net/~jbachorik/8049696/webrev.00 The test seems to fail due to a premature attempt to connect the debugee. The test is trying to guard against this by monitoring the debugee's stdout and allowing to proceed to connect only if something has already arrived on stdout (presumably the "Listening for transport dt_socket" message). However, it does not wait for the whole message to be present in stdout and this might contribute to the instability. The proposed fix replaces the arbitrary code used to launch the debugee with the test library ProcessTools.startProcess() and waits for the whole message being read from stdout before proceeding. If, for any reason, synchronizing on the presence of this message is still not enough, the call to method AttachingConnector.attach() is retried if it has lead to ConnectException (probably not initialized debugee). Thanks, -JB- From david.holmes at oracle.com Mon Mar 9 23:35:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 09:35:52 +1000 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54FD9F6C.80000@oracle.com> References: <54F9D11A.5070702@oracle.com> <54FC4F57.70604@oracle.com> <54FD4DBE.1070803@oracle.com> <54FD80BD.8040906@oracle.com> <54FD94FD.4030900@oracle.com> <54FD9F6C.80000@oracle.com> Message-ID: <54FE2E58.2060401@oracle.com> On 9/03/2015 11:26 PM, Jaroslav Bachorik wrote: > On 9.3.2015 13:41, Jaroslav Bachorik wrote: >> Hi David, >> >> On 9.3.2015 12:15, David Holmes wrote: >>> On 9/03/2015 5:37 PM, Jaroslav Bachorik wrote: >>>> On 8.3.2015 14:32, David Holmes wrote: >>>>> Hi Jaroslav, >>>>> >>>>> A couple of quick comments ... >>>>> >>>>> On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: >>>>>> Please, review the following test change >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >>>>>> >>>>>> As the issue subject states this test is susceptible to race >>>>>> condition. >>>>>> Firstly, it uses an arbitrary time period to wait after a thread has >>>>>> signalled its exit vie the associated barrier to 'make sure' the >>>>>> thread >>>>>> is actually terminated when the check for the number of live >>>>>> threads is >>>>>> performed. This is quite race prone and should be replaces by >>>>>> Thread.join() performed on the specified threads before moving >>>>>> forward >>>>>> and checking the reported thread counts. >>>>> >>>>> So now you do the join() why do you still also have an acquire() >>>>> preceding the join(s) ? >>>> >>>> Touch? - I guess I just didn't want to mess with the test too much. I >>>> suppose joining the threads that are expected to die should suffice. >>> >>> Yes. > > Here is the simplified webrev - > http://cr.openjdk.java.net/~jbachorik/6712222/webrev.01 > > Now, when it is sufficient to synchronize only on the threads startup I > can use Phaser instead of Semaphore and make the code a further bit more > readable. CyclicBarrier is even simpler :) Thanks for checking the "alive" status. The setLive/isLive synchronization is going to cause a bit of a bottleneck, but that mainly means threads will be blocked on the monitor instead of sleeping, I think. Minor style nits: for(int -> for (int Reviewed. Thanks, David > -JB- > >>> >>>>> >>>>> Also what exactly do those counters check? Even after join() can >>>>> return >>>>> the thread may still be in the Threads_list. >>>> >>>> The test is supposed to test whether ThreadMXBean reports correct >>>> numbers for the total number of started/finished threads and the number >>>> of threads being currently alive. >>>> >>>> Thread#join() should return only when the thread is not alive any more. >>>> The ThreadMXBean#getAllThreadIds() should return the IDs of only the >>>> threads being alive at the time the method was invoked. I didn't dig >>>> into the implementation - but according to the information available >>>> through javadocs this should work. >>> >>> It is the actual implementation I'm concerned about - to ensure the >>> notions of "alive" actually match. >> >> Invoking ThreadMXBean#getAllThreadIds() will eventually mean creating a >> ThreadsListEnumerator (in threadService.cpp#941) and this enumerator >> will skip any threads where `Thread.isAlive() == false`. The >> Thread.join() method is using Thread.isAlive() to assert the thread >> state and exits only when `Thread.isAlive() == false`. Therefore, a >> thread T can't be in the list of live threads generated after T.join() >> has returned. >> >> -JB- >> >>> >>> David >>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> >>>>>> Secondly, it is using a volatile array of boolean flags which are >>>>>> used >>>>>> for communication between the main thread and the test threads >>>>>> (setting >>>>>> an item of this array true will indicate the appropriate test >>>>>> thread to >>>>>> exit). Declaring the array as volatile does nothing for the thread >>>>>> safety and reads and writes to this array must be properly >>>>>> synchronized. >>>>>> >>>>>> I also took the liberty of replacing the arbitrary Barrier >>>>>> synchronization class with the standard Semaphore. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>> >> > From staffan.larsen at oracle.com Tue Mar 10 08:04:32 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Mar 2015 09:04:32 +0100 Subject: RFR 8049696: com/sun/jdi/RunToExit fails with "ConnectException: Connection refused" In-Reply-To: <54FDE927.4040904@oracle.com> References: <54FDE927.4040904@oracle.com> Message-ID: <93811175-BB22-4B93-A7D3-705413AECEAD@oracle.com> When catching the ConnectException, can you print it out as well? It may contain something that is interesting. With that change it looks good to me - no need for an updated review. Thanks, /Staffan > On 9 mar 2015, at 19:40, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8049696 > Webrev: http://cr.openjdk.java.net/~jbachorik/8049696/webrev.00 > > The test seems to fail due to a premature attempt to connect the debugee. The test is trying to guard against this by monitoring the debugee's stdout and allowing to proceed to connect only if something has already arrived on stdout (presumably the "Listening for transport dt_socket" message). However, it does not wait for the whole message to be present in stdout and this might contribute to the instability. > > The proposed fix replaces the arbitrary code used to launch the debugee with the test library ProcessTools.startProcess() and waits for the whole message being read from stdout before proceeding. If, for any reason, synchronizing on the presence of this message is still not enough, the call to method AttachingConnector.attach() is retried if it has lead to ConnectException (probably not initialized debugee). > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Mar 10 08:10:05 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 10 Mar 2015 09:10:05 +0100 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54FE2E58.2060401@oracle.com> References: <54F9D11A.5070702@oracle.com> <54FC4F57.70604@oracle.com> <54FD4DBE.1070803@oracle.com> <54FD80BD.8040906@oracle.com> <54FD94FD.4030900@oracle.com> <54FD9F6C.80000@oracle.com> <54FE2E58.2060401@oracle.com> Message-ID: <54FEA6DD.4010605@oracle.com> On 10.3.2015 00:35, David Holmes wrote: > On 9/03/2015 11:26 PM, Jaroslav Bachorik wrote: >> On 9.3.2015 13:41, Jaroslav Bachorik wrote: >>> Hi David, >>> >>> On 9.3.2015 12:15, David Holmes wrote: >>>> On 9/03/2015 5:37 PM, Jaroslav Bachorik wrote: >>>>> On 8.3.2015 14:32, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> A couple of quick comments ... >>>>>> >>>>>> On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test change >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >>>>>>> >>>>>>> As the issue subject states this test is susceptible to race >>>>>>> condition. >>>>>>> Firstly, it uses an arbitrary time period to wait after a thread has >>>>>>> signalled its exit vie the associated barrier to 'make sure' the >>>>>>> thread >>>>>>> is actually terminated when the check for the number of live >>>>>>> threads is >>>>>>> performed. This is quite race prone and should be replaces by >>>>>>> Thread.join() performed on the specified threads before moving >>>>>>> forward >>>>>>> and checking the reported thread counts. >>>>>> >>>>>> So now you do the join() why do you still also have an acquire() >>>>>> preceding the join(s) ? >>>>> >>>>> Touch? - I guess I just didn't want to mess with the test too much. I >>>>> suppose joining the threads that are expected to die should suffice. >>>> >>>> Yes. >> >> Here is the simplified webrev - >> http://cr.openjdk.java.net/~jbachorik/6712222/webrev.01 >> >> Now, when it is sufficient to synchronize only on the threads startup I >> can use Phaser instead of Semaphore and make the code a further bit more >> readable. > > CyclicBarrier is even simpler :) Yes, but the test threads don't need to wait for each other - Phaser.arrive() maps better here. > > Thanks for checking the "alive" status. > > The setLive/isLive synchronization is going to cause a bit of a > bottleneck, but that mainly means threads will be blocked on the monitor > instead of sleeping, I think. Exactly, the bottleneck is not a problem here. > > Minor style nits: for(int -> for (int Will fix before push. Thanks, -JB- > > Reviewed. > > Thanks, > David > >> -JB- >> >>>> >>>>>> >>>>>> Also what exactly do those counters check? Even after join() can >>>>>> return >>>>>> the thread may still be in the Threads_list. >>>>> >>>>> The test is supposed to test whether ThreadMXBean reports correct >>>>> numbers for the total number of started/finished threads and the >>>>> number >>>>> of threads being currently alive. >>>>> >>>>> Thread#join() should return only when the thread is not alive any >>>>> more. >>>>> The ThreadMXBean#getAllThreadIds() should return the IDs of only the >>>>> threads being alive at the time the method was invoked. I didn't dig >>>>> into the implementation - but according to the information available >>>>> through javadocs this should work. >>>> >>>> It is the actual implementation I'm concerned about - to ensure the >>>> notions of "alive" actually match. >>> >>> Invoking ThreadMXBean#getAllThreadIds() will eventually mean creating a >>> ThreadsListEnumerator (in threadService.cpp#941) and this enumerator >>> will skip any threads where `Thread.isAlive() == false`. The >>> Thread.join() method is using Thread.isAlive() to assert the thread >>> state and exits only when `Thread.isAlive() == false`. Therefore, a >>> thread T can't be in the list of live threads generated after T.join() >>> has returned. >>> >>> -JB- >>> >>>> >>>> David >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> Secondly, it is using a volatile array of boolean flags which are >>>>>>> used >>>>>>> for communication between the main thread and the test threads >>>>>>> (setting >>>>>>> an item of this array true will indicate the appropriate test >>>>>>> thread to >>>>>>> exit). Declaring the array as volatile does nothing for the thread >>>>>>> safety and reads and writes to this array must be properly >>>>>>> synchronized. >>>>>>> >>>>>>> I also took the liberty of replacing the arbitrary Barrier >>>>>>> synchronization class with the standard Semaphore. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>> >>> >> From jaroslav.bachorik at oracle.com Tue Mar 10 08:11:29 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 10 Mar 2015 09:11:29 +0100 Subject: RFR 8049696: com/sun/jdi/RunToExit fails with "ConnectException: Connection refused" In-Reply-To: <93811175-BB22-4B93-A7D3-705413AECEAD@oracle.com> References: <54FDE927.4040904@oracle.com> <93811175-BB22-4B93-A7D3-705413AECEAD@oracle.com> Message-ID: <54FEA731.9080305@oracle.com> On 10.3.2015 09:04, Staffan Larsen wrote: > When catching the ConnectException, can you print it out as well? It may contain something that is interesting. With that change it looks good to me - no need for an updated review. Yep, definitely. Thanks! -JB- > > Thanks, > /Staffan > >> On 9 mar 2015, at 19:40, Jaroslav Bachorik wrote: >> >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8049696 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8049696/webrev.00 >> >> The test seems to fail due to a premature attempt to connect the debugee. The test is trying to guard against this by monitoring the debugee's stdout and allowing to proceed to connect only if something has already arrived on stdout (presumably the "Listening for transport dt_socket" message). However, it does not wait for the whole message to be present in stdout and this might contribute to the instability. >> >> The proposed fix replaces the arbitrary code used to launch the debugee with the test library ProcessTools.startProcess() and waits for the whole message being read from stdout before proceeding. If, for any reason, synchronizing on the presence of this message is still not enough, the call to method AttachingConnector.attach() is retried if it has lead to ConnectException (probably not initialized debugee). >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Tue Mar 10 10:21:31 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Mar 2015 11:21:31 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure Message-ID: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> During attach, if the .java_pid file is not secure we currently say "well-known file is not secure". This can be enhanced to say _why_ the file is not considered secure. bug: https://bugs.openjdk.java.net/browse/JDK-8074812 webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.00/ Note that it is safe to call JNU_ReleaseStringPlatformChars after the calls to JNU_ThrowIOException since the latter don?t actually change the control flow. Thanks, /Staffan From david.holmes at oracle.com Tue Mar 10 11:09:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 21:09:20 +1000 Subject: RFR 6712222: 6712222: Race condition in java/lang/management/ThreadMXBean/AllThreadIds.java In-Reply-To: <54FEA6DD.4010605@oracle.com> References: <54F9D11A.5070702@oracle.com> <54FC4F57.70604@oracle.com> <54FD4DBE.1070803@oracle.com> <54FD80BD.8040906@oracle.com> <54FD94FD.4030900@oracle.com> <54FD9F6C.80000@oracle.com> <54FE2E58.2060401@oracle.com> <54FEA6DD.4010605@oracle.com> Message-ID: <54FED0E0.2010004@oracle.com> On 10/03/2015 6:10 PM, Jaroslav Bachorik wrote: > On 10.3.2015 00:35, David Holmes wrote: >> On 9/03/2015 11:26 PM, Jaroslav Bachorik wrote: >>> On 9.3.2015 13:41, Jaroslav Bachorik wrote: >>>> Hi David, >>>> >>>> On 9.3.2015 12:15, David Holmes wrote: >>>>> On 9/03/2015 5:37 PM, Jaroslav Bachorik wrote: >>>>>> On 8.3.2015 14:32, David Holmes wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> A couple of quick comments ... >>>>>>> >>>>>>> On 7/03/2015 2:08 AM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the following test change >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6712222 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6712222/webrev.00 >>>>>>>> >>>>>>>> As the issue subject states this test is susceptible to race >>>>>>>> condition. >>>>>>>> Firstly, it uses an arbitrary time period to wait after a thread >>>>>>>> has >>>>>>>> signalled its exit vie the associated barrier to 'make sure' the >>>>>>>> thread >>>>>>>> is actually terminated when the check for the number of live >>>>>>>> threads is >>>>>>>> performed. This is quite race prone and should be replaces by >>>>>>>> Thread.join() performed on the specified threads before moving >>>>>>>> forward >>>>>>>> and checking the reported thread counts. >>>>>>> >>>>>>> So now you do the join() why do you still also have an acquire() >>>>>>> preceding the join(s) ? >>>>>> >>>>>> Touch? - I guess I just didn't want to mess with the test too much. I >>>>>> suppose joining the threads that are expected to die should suffice. >>>>> >>>>> Yes. >>> >>> Here is the simplified webrev - >>> http://cr.openjdk.java.net/~jbachorik/6712222/webrev.01 >>> >>> Now, when it is sufficient to synchronize only on the threads startup I >>> can use Phaser instead of Semaphore and make the code a further bit more >>> readable. >> >> CyclicBarrier is even simpler :) > > Yes, but the test threads don't need to wait for each other - > Phaser.arrive() maps better here. Sorry I meant CountDownLatch :) But never mind. David >> >> Thanks for checking the "alive" status. >> >> The setLive/isLive synchronization is going to cause a bit of a >> bottleneck, but that mainly means threads will be blocked on the monitor >> instead of sleeping, I think. > > Exactly, the bottleneck is not a problem here. > >> >> Minor style nits: for(int -> for (int > > Will fix before push. > > Thanks, > > -JB- > >> >> Reviewed. >> >> Thanks, >> David >> >>> -JB- >>> >>>>> >>>>>>> >>>>>>> Also what exactly do those counters check? Even after join() can >>>>>>> return >>>>>>> the thread may still be in the Threads_list. >>>>>> >>>>>> The test is supposed to test whether ThreadMXBean reports correct >>>>>> numbers for the total number of started/finished threads and the >>>>>> number >>>>>> of threads being currently alive. >>>>>> >>>>>> Thread#join() should return only when the thread is not alive any >>>>>> more. >>>>>> The ThreadMXBean#getAllThreadIds() should return the IDs of only the >>>>>> threads being alive at the time the method was invoked. I didn't dig >>>>>> into the implementation - but according to the information available >>>>>> through javadocs this should work. >>>>> >>>>> It is the actual implementation I'm concerned about - to ensure the >>>>> notions of "alive" actually match. >>>> >>>> Invoking ThreadMXBean#getAllThreadIds() will eventually mean creating a >>>> ThreadsListEnumerator (in threadService.cpp#941) and this enumerator >>>> will skip any threads where `Thread.isAlive() == false`. The >>>> Thread.join() method is using Thread.isAlive() to assert the thread >>>> state and exits only when `Thread.isAlive() == false`. Therefore, a >>>> thread T can't be in the list of live threads generated after T.join() >>>> has returned. >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Secondly, it is using a volatile array of boolean flags which are >>>>>>>> used >>>>>>>> for communication between the main thread and the test threads >>>>>>>> (setting >>>>>>>> an item of this array true will indicate the appropriate test >>>>>>>> thread to >>>>>>>> exit). Declaring the array as volatile does nothing for the thread >>>>>>>> safety and reads and writes to this array must be properly >>>>>>>> synchronized. >>>>>>>> >>>>>>>> I also took the liberty of replacing the arbitrary Barrier >>>>>>>> synchronization class with the standard Semaphore. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>> >>>> >>> > From alexander.kulyakhtin at oracle.com Tue Mar 10 12:38:10 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 10 Mar 2015 05:38:10 -0700 (PDT) Subject: RFR: JDK-8072754: Getting read of unnecessary sun.misc.Version in the test Message-ID: <9a3888a3-7a0a-4cda-90de-3d5c1d46b6c4@default> Hi, Could you, please, review a small fix below. bug: https://bugs.openjdk.java.net/browse/JDK-8072754 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8072754/webrev.00/ The tests uses sun.misc.Version to check if the JVM version is greater than a certain version. For the JDK 9 the condition is always true and the usage of sun.misc.Version thus can be eliminated. Best regards, Alex From staffan.larsen at oracle.com Tue Mar 10 12:43:52 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Mar 2015 13:43:52 +0100 Subject: RFR: JDK-8072754: Getting read of unnecessary sun.misc.Version in the test In-Reply-To: <9a3888a3-7a0a-4cda-90de-3d5c1d46b6c4@default> References: <9a3888a3-7a0a-4cda-90de-3d5c1d46b6c4@default> Message-ID: <5AB807E9-5D88-4A69-85A1-8C49271CF480@oracle.com> Looks good! Thanks, /Staffan > On 10 mar 2015, at 13:38, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review a small fix below. > > bug: https://bugs.openjdk.java.net/browse/JDK-8072754 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8072754/webrev.00/ > > The tests uses sun.misc.Version to check if the JVM version is greater than a certain version. > For the JDK 9 the condition is always true and the usage of sun.misc.Version thus can be eliminated. > > Best regards, > Alex From Alan.Bateman at oracle.com Tue Mar 10 13:02:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Mar 2015 13:02:41 +0000 Subject: RFR: JDK-8072754: Getting read of unnecessary sun.misc.Version in the test In-Reply-To: <9a3888a3-7a0a-4cda-90de-3d5c1d46b6c4@default> References: <9a3888a3-7a0a-4cda-90de-3d5c1d46b6c4@default> Message-ID: <54FEEB71.90904@oracle.com> On 10/03/2015 12:38, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review a small fix below. > > bug: https://bugs.openjdk.java.net/browse/JDK-8072754 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8072754/webrev.00/ > > The tests uses sun.misc.Version to check if the JVM version is greater than a certain version. > For the JDK 9 the condition is always true and the usage of sun.misc.Version thus can be eliminated. > Looks good. -Alan From alexander.kulyakhtin at oracle.com Tue Mar 10 13:34:32 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 10 Mar 2015 06:34:32 -0700 (PDT) Subject: RFR: JDK-8072754: Getting read of unnecessary sun.misc.Version in the test Message-ID: Hi Igor, Could you, please, sponsor this small fix, as it has been already approved? Best regards, Alex ----- Original Message ----- From: Alan.Bateman at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Sent: Tuesday, March 10, 2015 4:02:43 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8072754: Getting read of unnecessary sun.misc.Version in the test On 10/03/2015 12:38, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review a small fix below. > > bug: https://bugs.openjdk.java.net/browse/JDK-8072754 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8072754/webrev.00/ > > The tests uses sun.misc.Version to check if the JVM version is greater than a certain version. > For the JDK 9 the condition is always true and the usage of sun.misc.Version thus can be eliminated. > Looks good. -Alan From staffan.larsen at oracle.com Tue Mar 10 15:37:46 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Mar 2015 16:37:46 +0100 Subject: RFR: Resolve disabled warnings for the JVMTI demos Message-ID: <9483D4B5-9B8E-4311-9B50-E0AD8D94DE4F@oracle.com> Please review these small fixes to remove a couple of warnings in the JVMTI demos. bug: https://bugs.openjdk.java.net/browse/JDK-8074841 bug: https://bugs.openjdk.java.net/browse/JDK-8074842 webrev: http://cr.openjdk.java.net/~sla/8074841/webrev.00/ Thanks, /Staffan From Alan.Bateman at oracle.com Tue Mar 10 15:45:08 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Mar 2015 15:45:08 +0000 Subject: RFR: Resolve disabled warnings for the JVMTI demos In-Reply-To: <9483D4B5-9B8E-4311-9B50-E0AD8D94DE4F@oracle.com> References: <9483D4B5-9B8E-4311-9B50-E0AD8D94DE4F@oracle.com> Message-ID: <54FF1184.7060808@oracle.com> On 10/03/2015 15:37, Staffan Larsen wrote: > Please review these small fixes to remove a couple of warnings in the JVMTI demos. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074841 > bug: https://bugs.openjdk.java.net/browse/JDK-8074842 > webrev: http://cr.openjdk.java.net/~sla/8074841/webrev.00/ > > Using %p looks right here, the removal of the unused locals too. So I think this looks good to me. -Alan From jaroslav.bachorik at oracle.com Tue Mar 10 15:49:06 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 10 Mar 2015 16:49:06 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> Message-ID: <54FF1272.6070306@oracle.com> Hi Staffan, On 10.3.2015 11:21, Staffan Larsen wrote: > During attach, if the .java_pid file is not secure we currently say "well-known file is not secure". This can be enhanced to say _why_ the file is not considered secure. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074812 > webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.00/ > > Note that it is safe to call JNU_ReleaseStringPlatformChars after the calls to JNU_ThrowIOException since the latter don?t actually change the control flow. Makes one wonder why it wasn't there since beginning :) The fix looks good - just a nit @src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c#28 the '#include "jvm.h"' seems to be superfluous. This include has not been added to any of the other modified files. -JB- > > Thanks, > /Staffan > From igor.ignatyev at oracle.com Tue Mar 10 16:40:50 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 10 Mar 2015 19:40:50 +0300 Subject: RFR (S) : 8073607 : add trace events for inlining In-Reply-To: <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> References: <54ECE8E0.2080201@oracle.com> <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> Message-ID: <54FF1E92.8020302@oracle.com> Hi Markus/Erik, I've slightly updated the patch according to your comments: - changed event path to 'vm/compiler/optimization/inlining' - replaced acronym BCI by its meaning Also I changed caller type to 'Method*'. http://cr.openjdk.java.net/~iignatyev/8073607/webrev.01/ Igor On 02/27/2015 01:25 PM, Markus Gronlund wrote: > Hi Igor, > > In trace.xml: > > > 404 > 405 > 406 > 407 > > You don't need to write an individual UTF8 string for every class, method and desc as we have "intrinsics" for taking care of this for you. > > This also means you wouldn't need to create a separate struct, as you can just define the necessary fields as type METHOD in the CompilerInlining event: > > 410 has_thread="true" is_instant="true"> > 411 > 412 > 413 > 414 > 415 > 416 > 417 > > > // I also removed these attributes " is_requestable="false" is_constant="false" - they are defaults. I changed to "is_instant=true" since it looks like the event does not span over a duration in bytecodeInfo.cpp. > > At the event site, you will now need to pass the Hotspot Method* as the values (unsure how you pull that out of a ci* artifact, but you have the Metadata* for the Method there somewhere): > > result.set_caller(Method* caller_method); > result.set_callee(Method* callee_method); > > Thanks > Markus > > -----Original Message----- > From: Igor Ignatyev > Sent: den 24 februari 2015 22:11 > To: hotspot-compiler-dev at openjdk.java.net compiler; serviceability-dev at openjdk.java.net > Subject: RFR (S) : 8073607 : add trace events for inlining > > Hi guys, > > could you please review the patch which adds trace events for inlining for c1/c2 compiler? > > An added event provides information about caller, callee, bci, inline status and message. > > webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 > -- > Igor > From magnus.ihse.bursie at oracle.com Tue Mar 10 17:32:45 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 10 Mar 2015 18:32:45 +0100 Subject: RFR: Resolve disabled warnings for the JVMTI demos In-Reply-To: <9483D4B5-9B8E-4311-9B50-E0AD8D94DE4F@oracle.com> References: <9483D4B5-9B8E-4311-9B50-E0AD8D94DE4F@oracle.com> Message-ID: Looks good to me. /Magnus > 10 mar 2015 kl. 16:37 skrev Staffan Larsen : > > Please review these small fixes to remove a couple of warnings in the JVMTI demos. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074841 > bug: https://bugs.openjdk.java.net/browse/JDK-8074842 > webrev: http://cr.openjdk.java.net/~sla/8074841/webrev.00/ > > Thanks, > /Staffan From martinrb at google.com Tue Mar 10 17:40:37 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Mar 2015 10:40:37 -0700 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> Message-ID: It's traditional (at least on Unix) to put the message after a ": " not within parens. http://pubs.opengroup.org/onlinepubs/009695399/functions/perror.html 374 if (sb.st_uid != uid) { 375 msg = "file is not owned by the current user"; 376 } else if (sb.st_gid != gid) { 377 msg = "file's group is not the effective group"; Why do you use the word "effective" with the gid, but not the uid? On Tue, Mar 10, 2015 at 3:21 AM, Staffan Larsen wrote: > During attach, if the .java_pid file is not secure we currently say > "well-known file is not secure". This can be enhanced to say _why_ the file > is not considered secure. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074812 > webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.00/ > > Note that it is safe to call JNU_ReleaseStringPlatformChars after the > calls to JNU_ThrowIOException since the latter don?t actually change the > control flow. > > Thanks, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Mar 10 17:45:36 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Mar 2015 18:45:36 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> Message-ID: <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> Hi Martin, > On 10 mar 2015, at 18:40, Martin Buchholz wrote: > > It's traditional (at least on Unix) to put the message after a ": " not within parens. > http://pubs.opengroup.org/onlinepubs/009695399/functions/perror.html Good point. I?ll change it to ?: ?. > 374 if (sb.st_uid != uid) { > 375 msg = "file is not owned by the current user"; > 376 } else if (sb.st_gid != gid) { > 377 msg = "file's group is not the effective group"; > > Why do you use the word "effective" with the gid, but not the uid? No reason. How do you think I should word it? I?ve been struggling? /Staffan > > > On Tue, Mar 10, 2015 at 3:21 AM, Staffan Larsen > wrote: > During attach, if the .java_pid file is not secure we currently say "well-known file is not secure". This can be enhanced to say _why_ the file is not considered secure. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074812 > webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.00/ > > Note that it is safe to call JNU_ReleaseStringPlatformChars after the calls to JNU_ThrowIOException since the latter don?t actually change the control flow. > > Thanks, > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Mar 10 17:53:45 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 10 Mar 2015 18:53:45 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> Message-ID: <54FF2FA9.6070908@oracle.com> On 10.3.2015 18:45, Staffan Larsen wrote: > Hi Martin, > >> On 10 mar 2015, at 18:40, Martin Buchholz > > wrote: >> >> It's traditional (at least on Unix) to put the message after a ": " >> not within parens. >> http://pubs.opengroup.org/onlinepubs/009695399/functions/perror.html > > Good point. I?ll change it to ?: ?. > >> 374 if (sb.st_uid != uid) { >> 375 msg = "file is not owned by the current user"; >> 376 } else if (sb.st_gid != gid) { >> 377 msg = "file's group is not the effective group"; >> >> Why do you use the word "effective" with the gid, but not the uid? > > No reason. How do you think I should word it? I?ve been struggling? IDK, 'effective group' sounds quite reasonable (http://en.wikipedia.org/wiki/Group_identifier) This just got me thinking - would including [sb.st_uid, uid] and [sb.st_gid, gid] in the error message be of any additional benefit? -JB- > > /Staffan > >> >> >> On Tue, Mar 10, 2015 at 3:21 AM, Staffan Larsen >> > wrote: >> >> During attach, if the .java_pid file is not secure we currently >> say "well-known file is not secure". This can be enhanced to say >> _why_ the file is not considered secure. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8074812 >> webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.00/ >> >> Note that it is safe to call JNU_ReleaseStringPlatformChars after >> the calls to JNU_ThrowIOException since the latter don?t actually >> change the control flow. >> >> Thanks, >> /Staffan >> >> > From martinrb at google.com Tue Mar 10 18:07:25 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Mar 2015 11:07:25 -0700 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: <54FF2FA9.6070908@oracle.com> References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> <54FF2FA9.6070908@oracle.com> Message-ID: On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik < jaroslav.bachorik at oracle.com> wrote: > > This just got me thinking - would including [sb.st_uid, uid] and > [sb.st_gid, gid] in the error message be of any additional benefit? > Yes. How much do you want to improve the quality of error messages? You could use the word "effective" only when effective and real users don't match. You could print out the two mismatched values. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Mar 10 20:28:01 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 10 Mar 2015 23:28:01 +0300 Subject: RFR: Resolve disabled warnings for the JVMTI demos In-Reply-To: <9483D4B5-9B8E-4311-9B50-E0AD8D94DE4F@oracle.com> References: <9483D4B5-9B8E-4311-9B50-E0AD8D94DE4F@oracle.com> Message-ID: <54FF53D1.1090108@oracle.com> Staffan, Looks good for me. -Dmitry On 2015-03-10 18:37, Staffan Larsen wrote: > Please review these small fixes to remove a couple of warnings in the JVMTI demos. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074841 > bug: https://bugs.openjdk.java.net/browse/JDK-8074842 > webrev: http://cr.openjdk.java.net/~sla/8074841/webrev.00/ > > Thanks, > /Staffan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From martinrb at google.com Tue Mar 10 20:30:25 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Mar 2015 13:30:25 -0700 Subject: Question about os::getenv() In-Reply-To: <54F95541.70501@oracle.com> References: <54F79907.9040700@oracle.com> <54F7AD6D.5040606@oracle.com> <54F95541.70501@oracle.com> Message-ID: The story of getenv and friends is very sad. getenv is (very suprisingly!) under a cloud http://austingroupbugs.net/view.php?id=188 and the hotspot copy-to-buffer variant of the windows api returns a boolean instead of a length, not allowing the caller to respond with a properly resized buffer. And of course Windows really wants you to use the UTF-16 "W" API. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Mar 10 21:02:03 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 10 Mar 2015 14:02:03 -0700 (PDT) Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make Message-ID: Greetings, Please review this small update to the Visual Studio projectcreator.make in order to exclude aarch64 files. Bug: https://bugs.openjdk.java.net/browse/JDK-8074905 Webrev: http://cr.openjdk.java.net/~mgronlun/8074905/webrev01/ Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tornqvist at oracle.com Tue Mar 10 21:27:07 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 10 Mar 2015 17:27:07 -0400 Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make In-Reply-To: References: Message-ID: <003701d05b78$f63ab4b0$e2b01e10$@oracle.com> Hi Markus, This looks good, thanks for fixing this. Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Markus Gronlund Sent: Tuesday, March 10, 2015 5:02 PM To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make Greetings, Please review this small update to the Visual Studio projectcreator.make in order to exclude aarch64 files. Bug: https://bugs.openjdk.java.net/browse/JDK-8074905 Webrev: http://cr.openjdk.java.net/~mgronlun/8074905/webrev01/ Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Mar 11 07:44:55 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Mar 2015 08:44:55 +0100 Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make In-Reply-To: References: Message-ID: <15265D77-FBE5-4B87-99BC-65C688157AC1@oracle.com> Looks good! Thanks, /Staffan > On 10 mar 2015, at 22:02, Markus Gronlund wrote: > > Greetings, > > > > Please review this small update to the Visual Studio projectcreator.make in order to exclude aarch64 files. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074905 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8074905/webrev01/ > > > > > > Thanks > > Markus From jaroslav.bachorik at oracle.com Wed Mar 11 08:35:43 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Mar 2015 09:35:43 +0100 Subject: [ping] Re: RFR 8074041: sun/management/jmxremote/startstop/JMXStartStopTest.java fails with InvocationTargetException In-Reply-To: <54F831F1.4080606@oracle.com> References: <54F831F1.4080606@oracle.com> Message-ID: <54FFFE5F.7040009@oracle.com> On 5.3.2015 11:37, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8074041 > Webrev: http://cr.openjdk.java.net/~jbachorik/8074041/webrev.00 > > This test fails very intermittently still and the failure is very hard > to reproduce. Based on the symptoms the probable cause seems to be the > asynchronous processing of a launched process stdout and stderr. > > The test is using ProcessTools.startProcess(...) to start the target > process and process its output (stdout/stderr) to mark the occurrence of > the expected string. When the target process has finished the test will > check the mark to assert the correctness. However, it may happen that > the assertion occurs in the time interval between the target process > finishing (process.waitFor() returns) and the asynchronous stderr/stdout > processors had the chance to dispatch the target process output to the > processor checking for the occurrence of the expected test. > > The proposed fix is to wrap the Process instance into a wrapper > enhancing the waitFor() method with the wait for the stdout/stderr > processor being finished before proceeding. I ran the test in a tight > loop for 1000 times after applying this patch without any failure. > > > Thanks, > > -JB- From yekaterina.kantserova at oracle.com Wed Mar 11 08:58:42 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 11 Mar 2015 09:58:42 +0100 Subject: [ping] Re: RFR 8074041: sun/management/jmxremote/startstop/JMXStartStopTest.java fails with InvocationTargetException In-Reply-To: <54FFFE5F.7040009@oracle.com> References: <54F831F1.4080606@oracle.com> <54FFFE5F.7040009@oracle.com> Message-ID: <550003C2.9040600@oracle.com> Hi Jaroslav, That's exactly the functionality I've been looking for! Not only it will solveJDK-8074041 the ProcessImpl will help me to solve https://bugs.openjdk.java.net/browse/JDK-8073794 since I'll be able to analyse out and err streams outside startProcess() function. Best regards, Katja (not a reviwer) On 03/11/2015 09:35 AM, Jaroslav Bachorik wrote: > On 5.3.2015 11:37, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8074041 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8074041/webrev.00 >> >> This test fails very intermittently still and the failure is very hard >> to reproduce. Based on the symptoms the probable cause seems to be the >> asynchronous processing of a launched process stdout and stderr. >> >> The test is using ProcessTools.startProcess(...) to start the target >> process and process its output (stdout/stderr) to mark the occurrence of >> the expected string. When the target process has finished the test will >> check the mark to assert the correctness. However, it may happen that >> the assertion occurs in the time interval between the target process >> finishing (process.waitFor() returns) and the asynchronous stderr/stdout >> processors had the chance to dispatch the target process output to the >> processor checking for the occurrence of the expected test. >> >> The proposed fix is to wrap the Process instance into a wrapper >> enhancing the waitFor() method with the wait for the stdout/stderr >> processor being finished before proceeding. I ran the test in a tight >> loop for 1000 times after applying this patch without any failure. >> >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Wed Mar 11 09:30:48 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Mar 2015 10:30:48 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> <54FF2FA9.6070908@oracle.com> Message-ID: Thanks for the feedback. Here is a new version that prints out more details for each of the errors messages. Let me know if you have suggestions for better wording. It also adds an #include for jvm.h that was missing from some of the files (it is needed for jio_snprintf). webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.01/ /Staffan > On 10 mar 2015, at 19:07, Martin Buchholz wrote: > > > > On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik > wrote: > > This just got me thinking - would including [sb.st_uid, uid] and [sb.st_gid, gid] in the error message be of any additional benefit? > > Yes. How much do you want to improve the quality of error messages? > > You could use the word "effective" only when effective and real users don't match. > You could print out the two mismatched values. -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Mar 11 12:20:21 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Mar 2015 13:20:21 +0100 Subject: [ping] RFR 8074041: sun/management/jmxremote/startstop/JMXStartStopTest.java fails with InvocationTargetException In-Reply-To: <54FFFE5F.7040009@oracle.com> References: <54F831F1.4080606@oracle.com> <54FFFE5F.7040009@oracle.com> Message-ID: <8B593E6B-652E-4A1E-BD95-C50A475D1971@oracle.com> Let try this! /Staffan > On 11 mar 2015, at 09:35, Jaroslav Bachorik wrote: > > On 5.3.2015 11:37, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8074041 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8074041/webrev.00 >> >> This test fails very intermittently still and the failure is very hard >> to reproduce. Based on the symptoms the probable cause seems to be the >> asynchronous processing of a launched process stdout and stderr. >> >> The test is using ProcessTools.startProcess(...) to start the target >> process and process its output (stdout/stderr) to mark the occurrence of >> the expected string. When the target process has finished the test will >> check the mark to assert the correctness. However, it may happen that >> the assertion occurs in the time interval between the target process >> finishing (process.waitFor() returns) and the asynchronous stderr/stdout >> processors had the chance to dispatch the target process output to the >> processor checking for the occurrence of the expected test. >> >> The proposed fix is to wrap the Process instance into a wrapper >> enhancing the waitFor() method with the wait for the stdout/stderr >> processor being finished before proceeding. I ran the test in a tight >> loop for 1000 times after applying this patch without any failure. >> >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Wed Mar 11 12:38:41 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Mar 2015 13:38:41 +0100 Subject: RFR: 8074948 javadoc typo in DiagnosticCommandMBean.java: {code instead of {@code Message-ID: <36B842D2-68F9-4227-BF0D-1836B4488A79@oracle.com> Please review this addition of a missing @. /Staffan diff --git a/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java b/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java --- a/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java +++ b/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java @@ -31,7 +31,7 @@ /** * Management interface for the diagnostic commands for the HotSpot Virtual Machine. * - *

The {code DiagnosticCommandMBean} is registered to the + *

The {@code DiagnosticCommandMBean} is registered to the * {@linkplain java.lang.management.ManagementFactory#getPlatformMBeanServer * platform MBeanServer} as are other platform MBeans. * From jaroslav.bachorik at oracle.com Wed Mar 11 13:10:02 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Mar 2015 14:10:02 +0100 Subject: RFR: 8074948 javadoc typo in DiagnosticCommandMBean.java: {code instead of {@code In-Reply-To: <36B842D2-68F9-4227-BF0D-1836B4488A79@oracle.com> References: <36B842D2-68F9-4227-BF0D-1836B4488A79@oracle.com> Message-ID: <55003EAA.3040403@oracle.com> On 11.3.2015 13:38, Staffan Larsen wrote: > Please review this addition of a missing @. Thumbs up! -JB- > > /Staffan > > > diff --git a/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java b/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java > --- a/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java > +++ b/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java > @@ -31,7 +31,7 @@ > /** > * Management interface for the diagnostic commands for the HotSpot Virtual Machine. > * > - *

The {code DiagnosticCommandMBean} is registered to the > + *

The {@code DiagnosticCommandMBean} is registered to the > * {@linkplain java.lang.management.ManagementFactory#getPlatformMBeanServer > * platform MBeanServer} as are other platform MBeans. > * > From yasuenag at gmail.com Wed Mar 11 13:13:27 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 11 Mar 2015 22:13:27 +0900 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DF4956.7030709@gmail.com> References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com> <54DF4956.7030709@gmail.com> Message-ID: <55003F77.80606@gmail.com> Hi all, > So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run > to it. I've uploaded new webrev, and I've applied it to new patch. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/ I also updated jtreg testcase. It works fine in my environment. Thanks, Yasumasa On 2015/02/14 22:10, Yasumasa Suenaga wrote: > Hi Mikael, > >> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run > > Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ? > This function is used with GCCause::is_serviceability_requested_gc() . > CMSCollector::is_external_interruption() and AdaptiveSizePolicy::check_gc_overhead_limit() > > is_user_requested_gc() and is_serviceability_requested_gc() checkes _jvmti_force_gc > is selected. > So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run > to it. > >> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. > > We can use GCCause::is_user_requested_gc() if the proposal in above is accepted. > > > Thanks > > Yasumasa > > > > On 2015/02/13 21:33, Mikael Gerdin wrote: >> Hi Yasumasa, >> >> On 2015-02-11 15:02, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I've committed JDK-8068589 to add new GCCause - Diagnostic Command. >>> However, it has been backouted because test is failed [1] and it is not considered >>> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. >>> >>> I've created patch for this enhancement. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ >> >> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run >> >> Given that the documentation of the GC.run command is: >> "GC.run >> Call java.lang.System.gc(). >> >> Impact: Medium: Depends on Java heap size and content. >> >> Syntax: GC.run" >> >> I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc(). >> >> This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC >> >> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. >> >> /Mikael >> >>> >>> >>> I'm jdk9 committer, but I'm not employee at Oracle. >>> So I need a Sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html >>> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html >>> From mandy.chung at oracle.com Wed Mar 11 16:22:42 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Mar 2015 09:22:42 -0700 Subject: RFR: 8074948 javadoc typo in DiagnosticCommandMBean.java: {code instead of {@code In-Reply-To: <36B842D2-68F9-4227-BF0D-1836B4488A79@oracle.com> References: <36B842D2-68F9-4227-BF0D-1836B4488A79@oracle.com> Message-ID: <55006BD2.7050706@oracle.com> On 3/11/15 5:38 AM, Staffan Larsen wrote: > Please review this addition of a missing @. > > /Staffan > > > diff --git a/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java b/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java > --- a/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java > +++ b/src/java.management/share/classes/com/sun/management/DiagnosticCommandMBean.java > @@ -31,7 +31,7 @@ > /** > * Management interface for the diagnostic commands for the HotSpot Virtual Machine. > * > - *

The {code DiagnosticCommandMBean} is registered to the > + *

The {@code DiagnosticCommandMBean} is registered to the > * {@linkplain java.lang.management.ManagementFactory#getPlatformMBeanServer > * platform MBeanServer} as are other platform MBeans. > * Looks good to me. Mandy From martinrb at google.com Wed Mar 11 19:37:41 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 Mar 2015 12:37:41 -0700 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> <54FF2FA9.6070908@oracle.com> Message-ID: Producing good error messages is such hard work! Instead of 0%3o, use 0%03o Since you want to print the lowest 9 bits of the mode, don't you want & 0x1ff On Wed, Mar 11, 2015 at 2:30 AM, Staffan Larsen wrote: > Thanks for the feedback. Here is a new version that prints out more > details for each of the errors messages. Let me know if you have > suggestions for better wording. It also adds an #include for jvm.h that was > missing from some of the files (it is needed for jio_snprintf). > > webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.01/ > > /Staffan > > On 10 mar 2015, at 19:07, Martin Buchholz wrote: > > > > On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik < > jaroslav.bachorik at oracle.com> wrote: > >> >> This just got me thinking - would including [sb.st_uid, uid] and >> [sb.st_gid, gid] in the error message be of any additional benefit? >> > > Yes. How much do you want to improve the quality of error messages? > > You could use the word "effective" only when effective and real users > don't match. > You could print out the two mismatched values. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Mar 12 07:18:40 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Mar 2015 08:18:40 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> <54FF2FA9.6070908@oracle.com> Message-ID: <99A8A23E-77F6-4617-B4FF-4535CF776AA2@oracle.com> > On 11 mar 2015, at 20:37, Martin Buchholz wrote: > > Producing good error messages is such hard work! Aye. And so often forgotten. > > Instead of 0%3o, use 0%03o > Since you want to print the lowest 9 bits of the mode, don't you want & 0x1ff Absolutely. I opted for the octal representation 0777 instead which seemed fitting here. new webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.02/ Thanks, /Staffan > > On Wed, Mar 11, 2015 at 2:30 AM, Staffan Larsen > wrote: > Thanks for the feedback. Here is a new version that prints out more details for each of the errors messages. Let me know if you have suggestions for better wording. It also adds an #include for jvm.h that was missing from some of the files (it is needed for jio_snprintf). > > webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.01/ > > /Staffan > >> On 10 mar 2015, at 19:07, Martin Buchholz > wrote: >> >> >> >> On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik > wrote: >> >> This just got me thinking - would including [sb.st_uid, uid] and [sb.st_gid, gid] in the error message be of any additional benefit? >> >> Yes. How much do you want to improve the quality of error messages? >> >> You could use the word "effective" only when effective and real users don't match. >> You could print out the two mismatched values. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Mar 12 08:39:24 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Mar 2015 09:39:24 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: <99A8A23E-77F6-4617-B4FF-4535CF776AA2@oracle.com> References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> <54FF2FA9.6070908@oracle.com> <99A8A23E-77F6-4617-B4FF-4535CF776AA2@oracle.com> Message-ID: <550150BC.9020505@oracle.com> On 12.3.2015 08:18, Staffan Larsen wrote: > >> On 11 mar 2015, at 20:37, Martin Buchholz > > wrote: >> >> Producing good error messages is such hard work! > > Aye. And so often forgotten. > >> >> Instead of 0%3o, use 0%03o >> Since you want to print the lowest 9 bits of the mode, don't you want & 0x1ff > Absolutely. I opted for the octal representation 0777 instead which > seemed fitting here. > > new webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.02/ This looks fine. -JB- > > Thanks, > /Staffan > > >> >> On Wed, Mar 11, 2015 at 2:30 AM, Staffan Larsen >> > wrote: >> >> Thanks for the feedback. Here is a new version that prints out >> more details for each of the errors messages. Let me know if you >> have suggestions for better wording. It also adds an #include for >> jvm.h that was missing from some of the files (it is needed >> for jio_snprintf). >> >> webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.01/ >> >> /Staffan >> >>> On 10 mar 2015, at 19:07, Martin Buchholz >> > wrote: >>> >>> >>> >>> On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik >>> >> > wrote: >>> >>> >>> This just got me thinking - would including [sb.st_uid, uid] >>> and [sb.st_gid, gid] in the error message be of any >>> additional benefit? >>> >>> >>> Yes. How much do you want to improve the quality of error messages? >>> >>> You could use the word "effective" only when effective and real >>> users don't match. >>> You could print out the two mismatched values. >> >> > From yasuenag at gmail.com Thu Mar 12 11:58:15 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 12 Mar 2015 20:58:15 +0900 Subject: inlining AllocateHeap() Message-ID: Hi all, I tried to use NMT with details option on OpenJDK7 on RHEL6.6, but I got address at AllocateHeap() as malloc() caller. I checked symbol in libjvm.so in OracleJDK8u40 Linux x64, it has AllocateHeap() symbol. AllocateHeap() is defined as inline function, and it gives CURRENT_PC to os::malloc(). I guess that implementation expects AllocateHeap() will be inlined. It may occur with GCC (g++) optimization only, however I want to fix it to analyze native memory with NMT on Linux. I applied patch as below. This patch makes AllocateHeap() as inline function. -------------- diff -r af3b0db91659 src/share/vm/memory/allocation.inline.hpp --- a/src/share/vm/memory/allocation.inline.hpp Mon Mar 09 09:30:16 2015 -0700 +++ b/src/share/vm/memory/allocation.inline.hpp Thu Mar 12 20:45:57 2015 +0900 @@ -62,11 +62,18 @@ } return p; } + +#ifdef __GNUC__ +__attribute__((always_inline)) +#endif inline char* AllocateHeap(size_t size, MEMFLAGS flags, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); } +#ifdef __GNUC__ +__attribute__((always_inline)) +#endif inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); -------------- If this patch is accepted, I will file it to JBS and will upload webrev. Thanks, Yasumasa -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Mar 12 12:54:17 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Mar 2015 13:54:17 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole Message-ID: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. bug: https://bugs.openjdk.java.net/browse/JDK-8075056 webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Mar 12 12:57:54 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 12 Mar 2015 13:57:54 +0100 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <55003F77.80606@gmail.com> References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com> <54DF4956.7030709@gmail.com> <55003F77.80606@gmail.com> Message-ID: <55018D52.9060003@oracle.com> Hi, On 2015-03-11 14:13, Yasumasa Suenaga wrote: > Hi all, > >> So I think we can remove _jvmti_force_gc from is_user_requested_gc() >> and add _dcmd_gc_run >> to it. > > I've uploaded new webrev, and I've applied it to new patch. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/ Sorry for the delay, I've been pretty busy lately. Does anyone have time to look at this change? /Mikael > > I also updated jtreg testcase. > It works fine in my environment. > > > Thanks, > > Yasumasa > > > On 2015/02/14 22:10, Yasumasa Suenaga wrote: >> Hi Mikael, >> >>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() >>> which returns true for some set of GCCause enum values, such as >>> _java_lang_system_gc and _dcmd_gc_run >> >> Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ? >> This function is used with GCCause::is_serviceability_requested_gc() . >> CMSCollector::is_external_interruption() and >> AdaptiveSizePolicy::check_gc_overhead_limit() >> >> is_user_requested_gc() and is_serviceability_requested_gc() checkes >> _jvmti_force_gc >> is selected. >> So I think we can remove _jvmti_force_gc from is_user_requested_gc() >> and add _dcmd_gc_run >> to it. >> >>> A "grep" for _java_lang_system_gc should yield more places where >>> updates may be necessary. >> >> We can use GCCause::is_user_requested_gc() if the proposal in above is >> accepted. >> >> >> Thanks >> >> Yasumasa >> >> >> >> On 2015/02/13 21:33, Mikael Gerdin wrote: >>> Hi Yasumasa, >>> >>> On 2015-02-11 15:02, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I've committed JDK-8068589 to add new GCCause - Diagnostic Command. >>>> However, it has been backouted because test is failed [1] and it is >>>> not considered >>>> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. >>>> >>>> I've created patch for this enhancement. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ >>> >>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() >>> which returns true for some set of GCCause enum values, such as >>> _java_lang_system_gc and _dcmd_gc_run >>> >>> Given that the documentation of the GC.run command is: >>> "GC.run >>> Call java.lang.System.gc(). >>> >>> Impact: Medium: Depends on Java heap size and content. >>> >>> Syntax: GC.run" >>> >>> I interpret the documentation that the GC is supposed to be (for all >>> intents and purposes) equivalent to the application invoking >>> System.gc(). >>> >>> This would also require updates to other places where we refer to the >>> _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC >>> >>> A "grep" for _java_lang_system_gc should yield more places where >>> updates may be necessary. >>> >>> /Mikael >>> >>>> >>>> >>>> I'm jdk9 committer, but I'm not employee at Oracle. >>>> So I need a Sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html >>>> >>>> From erik.joelsson at oracle.com Thu Mar 12 13:00:07 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Mar 2015 14:00:07 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <55018DD7.4010100@oracle.com> Looks good. /Erik On 2015-03-12 13:54, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > Thanks, > /Staffan From Alan.Bateman at oracle.com Thu Mar 12 13:07:44 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Mar 2015 13:07:44 +0000 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <55018FA0.6030900@oracle.com> On 12/03/2015 12:54, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > Looks okay to me. -Alan From magnus.ihse.bursie at oracle.com Thu Mar 12 14:05:42 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Mar 2015 15:05:42 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <55019D36.2060501@oracle.com> On 2015-03-12 13:54, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > Thanks, > /Staffan Looks good. Thank you! /Magnus From mandy.chung at oracle.com Thu Mar 12 16:05:55 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Mar 2015 09:05:55 -0700 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <5501B963.9010002@oracle.com> On 3/12/2015 5:54 AM, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ jconsole is redistributable. It's possible that customers can run jconsole with a JRE of different version. Now it's linked in the image and we will have look into whether we want to continue jconsole be redistributable and perhaps it will not be in JDK 9 and this change would be okay. Mandy From iris.clark at oracle.com Thu Mar 12 16:19:01 2015 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 12 Mar 2015 09:19:01 -0700 (PDT) Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: Hi, Staffan. > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ Looks good. I'm always happy to see changes where complexity is reduced. Thanks, iris From martinrb at google.com Thu Mar 12 17:47:13 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Mar 2015 10:47:13 -0700 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: <99A8A23E-77F6-4617-B4FF-4535CF776AA2@oracle.com> References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> <54FF2FA9.6070908@oracle.com> <99A8A23E-77F6-4617-B4FF-4535CF776AA2@oracle.com> Message-ID: Looks good to me! On Thu, Mar 12, 2015 at 12:18 AM, Staffan Larsen wrote: > > On 11 mar 2015, at 20:37, Martin Buchholz wrote: > > Producing good error messages is such hard work! > > > Aye. And so often forgotten. > > > Instead of 0%3o, use 0%03o > > Since you want to print the lowest 9 bits of the mode, don't you want & 0x1ff > > Absolutely. I opted for the octal representation 0777 instead which seemed > fitting here. > > new webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.02/ > > Thanks, > /Staffan > > > > On Wed, Mar 11, 2015 at 2:30 AM, Staffan Larsen > wrote: > >> Thanks for the feedback. Here is a new version that prints out more >> details for each of the errors messages. Let me know if you have >> suggestions for better wording. It also adds an #include for jvm.h that was >> missing from some of the files (it is needed for jio_snprintf). >> >> webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.01/ >> >> /Staffan >> >> On 10 mar 2015, at 19:07, Martin Buchholz wrote: >> >> >> >> On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik < >> jaroslav.bachorik at oracle.com> wrote: >> >>> >>> This just got me thinking - would including [sb.st_uid, uid] and >>> [sb.st_gid, gid] in the error message be of any additional benefit? >>> >> >> Yes. How much do you want to improve the quality of error messages? >> >> You could use the word "effective" only when effective and real users >> don't match. >> You could print out the two mismatched values. >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Thu Mar 12 20:53:23 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 12 Mar 2015 21:53:23 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <5501FCC3.3010905@oracle.com> Looks good, jconsole now compile in Eclipse! Erik Staffan Larsen skrev 2015-03-12 13:54: > The build for jconsole currently takes a template file and inserts the > version number of the build into the file. We can simplify this by > removing the template file and reading the java.runtime.version system > property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > > Thanks, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Mar 13 05:27:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Mar 2015 22:27:54 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. Message-ID: <5502755A.5060309@oracle.com> Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8067662 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ Open webrev for unit test update: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ Summary: An NPE is trown in a thread dumping via JMX when doing CPU profiling in NetBeans Profiler and VisualVM. The issue is that the methods and related klass versions are not kept alive if a class redefinition takes place between catching a Throwable and taking a thread dump. It can result in loosing an obsolete method, and so, the reconstruction of method name becomes impossible. In such a case, the null reference is returned instead of a valid method name. The solution is to use current klass version and method orig_idnum instead of ordinary method idnum to find required method pointer. In the worst case when the related klass version is gone (was not included to or was removed from the previous_versions linked list), a saved method name CP index of the latest klass version can be used to restore the method name. The footprint extra overhead for this approach is u2 per stack frame. The plan is also to backport the fix to 8u60. Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument Thanks, Serguei From david.holmes at oracle.com Fri Mar 13 05:40:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 15:40:02 +1000 Subject: inlining AllocateHeap() In-Reply-To: References: Message-ID: <55027832.8030203@oracle.com> Hi Yasumasa, On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: > Hi all, > > I tried to use NMT with details option on OpenJDK7 on RHEL6.6, but I got > address at AllocateHeap() as malloc() caller. > > I checked symbol in libjvm.so in OracleJDK8u40 Linux > x64, it has AllocateHeap() > symbol. > > AllocateHeap() is defined as inline function, and it gives CURRENT_PC to > os::malloc(). I guess that implementation expects AllocateHeap() will be > inlined. It seems so. > It may occur with GCC (g++) optimization only, however I want to fix it to > analyze native memory with NMT on Linux. According to the docs [1]: "GCC does not inline any functions when not optimizing unless you specify the ?always_inline? attribute for the function" > I applied patch as below. This patch makes AllocateHeap() as inline > function. > -------------- > diff -r af3b0db91659 src/share/vm/memory/allocation.inline.hpp > --- a/src/share/vm/memory/allocation.inline.hpp Mon Mar 09 09:30:16 2015 > -0700 > +++ b/src/share/vm/memory/allocation.inline.hpp Thu Mar 12 20:45:57 2015 > +0900 > @@ -62,11 +62,18 @@ > } > return p; > } > + > +#ifdef __GNUC__ > +__attribute__((always_inline)) > +#endif I dislike seeing the gcc specific directives in common code. I'm wondering whether we should perhaps only use CURRENT_PC in product (and optimized?) builds and use CALLER_PC otherwise. That would be imperfect of course It also makes me wonder whether the inlining is occurring as expected on other platforms. I'd like to get other people's views on this. Thanks, David [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html > inline char* AllocateHeap(size_t size, MEMFLAGS flags, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); > } > > +#ifdef __GNUC__ > +__attribute__((always_inline)) > +#endif > inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); > -------------- > > If this patch is accepted, I will file it to JBS and will upload webrev. > > Thanks, > > Yasumasa > From staffan.larsen at oracle.com Fri Mar 13 07:38:09 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Mar 2015 08:38:09 +0100 Subject: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure In-Reply-To: References: <355B4923-0C68-4816-9FE9-51D787CAF79E@oracle.com> <9A3E0E82-4DF2-4E24-B0B2-867E1D7056E2@oracle.com> <54FF2FA9.6070908@oracle.com> <99A8A23E-77F6-4617-B4FF-4535CF776AA2@oracle.com> Message-ID: <6C4F7440-5953-4347-B99C-2EA868BEE3E1@oracle.com> Martin, Jaroslav: Thank you! > On 12 mar 2015, at 18:47, Martin Buchholz wrote: > > Looks good to me! > > > On Thu, Mar 12, 2015 at 12:18 AM, Staffan Larsen > wrote: > >> On 11 mar 2015, at 20:37, Martin Buchholz > wrote: >> >> Producing good error messages is such hard work! > > Aye. And so often forgotten. > >> >> Instead of 0%3o, use 0%03o >> Since you want to print the lowest 9 bits of the mode, don't you want & 0x1ff > > Absolutely. I opted for the octal representation 0777 instead which seemed fitting here. > > new webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.02/ > > Thanks, > /Staffan > > >> >> On Wed, Mar 11, 2015 at 2:30 AM, Staffan Larsen > wrote: >> Thanks for the feedback. Here is a new version that prints out more details for each of the errors messages. Let me know if you have suggestions for better wording. It also adds an #include for jvm.h that was missing from some of the files (it is needed for jio_snprintf). >> >> webrev: http://cr.openjdk.java.net/~sla/8074812/webrev.01/ >> >> /Staffan >> >>> On 10 mar 2015, at 19:07, Martin Buchholz > wrote: >>> >>> >>> >>> On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik > wrote: >>> >>> This just got me thinking - would including [sb.st_uid, uid] and [sb.st_gid, gid] in the error message be of any additional benefit? >>> >>> Yes. How much do you want to improve the quality of error messages? >>> >>> You could use the word "effective" only when effective and real users don't match. >>> You could print out the two mismatched values. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Mar 13 08:13:19 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 13 Mar 2015 09:13:19 +0100 Subject: inlining AllocateHeap() In-Reply-To: <55027832.8030203@oracle.com> References: <55027832.8030203@oracle.com> Message-ID: Hi Yasumasa, David, Maybe it would make sense to make the number-of-frames-to-skip-parameter configurable? Because the direct caller of AllocateHeap or os::malloc may also not be interesting but still a generic wrapper. So, the user doing the allocation trace could finetune this parameter to fit his needs. Thomas On Fri, Mar 13, 2015 at 6:40 AM, David Holmes wrote: > Hi Yasumasa, > > On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: > >> Hi all, >> >> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, but I got >> address at AllocateHeap() as malloc() caller. >> >> I checked symbol in libjvm.so in OracleJDK8u40 Linux >> x64, it has AllocateHeap() >> symbol. >> >> AllocateHeap() is defined as inline function, and it gives CURRENT_PC to >> os::malloc(). I guess that implementation expects AllocateHeap() will be >> inlined. >> > > It seems so. > > It may occur with GCC (g++) optimization only, however I want to fix it to >> analyze native memory with NMT on Linux. >> > > According to the docs [1]: > > "GCC does not inline any functions when not optimizing unless you specify > the ?always_inline? attribute for the function" > > I applied patch as below. This patch makes AllocateHeap() as inline >> function. >> -------------- >> diff -r af3b0db91659 src/share/vm/memory/allocation.inline.hpp >> --- a/src/share/vm/memory/allocation.inline.hpp Mon Mar 09 09:30:16 2015 >> -0700 >> +++ b/src/share/vm/memory/allocation.inline.hpp Thu Mar 12 20:45:57 2015 >> +0900 >> @@ -62,11 +62,18 @@ >> } >> return p; >> } >> + >> +#ifdef __GNUC__ >> +__attribute__((always_inline)) >> +#endif >> > > I dislike seeing the gcc specific directives in common code. I'm wondering > whether we should perhaps only use CURRENT_PC in product (and optimized?) > builds and use CALLER_PC otherwise. That would be imperfect of course It > also makes me wonder whether the inlining is occurring as expected on other > platforms. > > I'd like to get other people's views on this. > > Thanks, > David > > [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html > > > inline char* AllocateHeap(size_t size, MEMFLAGS flags, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); >> } >> >> +#ifdef __GNUC__ >> +__attribute__((always_inline)) >> +#endif >> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); >> -------------- >> >> If this patch is accepted, I will file it to JBS and will upload webrev. >> >> Thanks, >> >> Yasumasa >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Mar 13 08:35:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 18:35:14 +1000 Subject: inlining AllocateHeap() In-Reply-To: References: <55027832.8030203@oracle.com> Message-ID: <5502A142.90403@oracle.com> On 13/03/2015 6:13 PM, Thomas St?fe wrote: > Hi Yasumasa, David, > > Maybe it would make sense to make the number-of-frames-to-skip-parameter > configurable? That would require more significant changes to NMT I think - plus I don't see how it will help if you have to know a-priori whether inlining has occurred or not. ?? Thanks, David > Because the direct caller of AllocateHeap or os::malloc may also not be > interesting but still a generic wrapper. So, the user doing the > allocation trace could finetune this parameter to fit his needs. > > Thomas > > > > On Fri, Mar 13, 2015 at 6:40 AM, David Holmes > wrote: > > Hi Yasumasa, > > On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: > > Hi all, > > I tried to use NMT with details option on OpenJDK7 on RHEL6.6, > but I got > address at AllocateHeap() as malloc() caller. > > I checked symbol in libjvm.so in > OracleJDK8u40 Linux > x64, it has AllocateHeap() > symbol. > > AllocateHeap() is defined as inline function, and it gives > CURRENT_PC to > os::malloc(). I guess that implementation expects AllocateHeap() > will be > inlined. > > > It seems so. > > It may occur with GCC (g++) optimization only, however I want to > fix it to > analyze native memory with NMT on Linux. > > > According to the docs [1]: > > "GCC does not inline any functions when not optimizing unless you > specify the ?always_inline? attribute for the function" > > I applied patch as below. This patch makes AllocateHeap() as inline > function. > -------------- > diff -r af3b0db91659 src/share/vm/memory/__allocation.inline.hpp > --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 > 09:30:16 2015 > -0700 > +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 > 20:45:57 2015 > +0900 > @@ -62,11 +62,18 @@ > } > return p; > } > + > +#ifdef __GNUC__ > +__attribute__((always_inline)__) > +#endif > > > I dislike seeing the gcc specific directives in common code. I'm > wondering whether we should perhaps only use CURRENT_PC in product > (and optimized?) builds and use CALLER_PC otherwise. That would be > imperfect of course It also makes me wonder whether the inlining is > occurring as expected on other platforms. > > I'd like to get other people's views on this. > > Thanks, > David > > [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html > > > > inline char* AllocateHeap(size_t size, MEMFLAGS flags, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); > } > > +#ifdef __GNUC__ > +__attribute__((always_inline)__) > +#endif > inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); > -------------- > > If this patch is accepted, I will file it to JBS and will upload > webrev. > > Thanks, > > Yasumasa > > From yasuenag at gmail.com Fri Mar 13 13:16:14 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 13 Mar 2015 22:16:14 +0900 Subject: inlining AllocateHeap() In-Reply-To: <5502A142.90403@oracle.com> References: <55027832.8030203@oracle.com> <5502A142.90403@oracle.com> Message-ID: <5502E31E.10005@gmail.com> Hi, > That would require more significant changes to NMT I think I think two changes: 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . I think that caller of AllocateHeap() and ReallocateHeap() should give PC to them. However, it is significant changes. Thus I proposed to add always_inline . > I don't see how it will help if you have to know a-priori whether inlining has occurred or not. ?? I think we can use SA. In case of Linux, sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() can lookup symbol from target process - we can check whether the function has been inlined (cannot lookup) or not (can lookup). So I think that we can write jtreg testcase. BTW, should I file it to JBS? Thanks, Yasumasa On 2015/03/13 17:35, David Holmes wrote: > On 13/03/2015 6:13 PM, Thomas St?fe wrote: >> Hi Yasumasa, David, >> >> Maybe it would make sense to make the number-of-frames-to-skip-parameter >> configurable? > > That would require more significant changes to NMT I think - plus I don't see how it will help if you have to know a-priori whether inlining has occurred or not. ?? > > Thanks, > David > >> Because the direct caller of AllocateHeap or os::malloc may also not be >> interesting but still a generic wrapper. So, the user doing the >> allocation trace could finetune this parameter to fit his needs. >> >> Thomas >> >> >> >> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes > > wrote: >> >> Hi Yasumasa, >> >> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, >> but I got >> address at AllocateHeap() as malloc() caller. >> >> I checked symbol in libjvm.so in >> OracleJDK8u40 Linux >> x64, it has AllocateHeap() >> symbol. >> >> AllocateHeap() is defined as inline function, and it gives >> CURRENT_PC to >> os::malloc(). I guess that implementation expects AllocateHeap() >> will be >> inlined. >> >> >> It seems so. >> >> It may occur with GCC (g++) optimization only, however I want to >> fix it to >> analyze native memory with NMT on Linux. >> >> >> According to the docs [1]: >> >> "GCC does not inline any functions when not optimizing unless you >> specify the ?always_inline? attribute for the function" >> >> I applied patch as below. This patch makes AllocateHeap() as inline >> function. >> -------------- >> diff -r af3b0db91659 src/share/vm/memory/__allocation.inline.hpp >> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 >> 09:30:16 2015 >> -0700 >> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 >> 20:45:57 2015 >> +0900 >> @@ -62,11 +62,18 @@ >> } >> return p; >> } >> + >> +#ifdef __GNUC__ >> +__attribute__((always_inline)__) >> +#endif >> >> >> I dislike seeing the gcc specific directives in common code. I'm >> wondering whether we should perhaps only use CURRENT_PC in product >> (and optimized?) builds and use CALLER_PC otherwise. That would be >> imperfect of course It also makes me wonder whether the inlining is >> occurring as expected on other platforms. >> >> I'd like to get other people's views on this. >> >> Thanks, >> David >> >> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >> >> >> >> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); >> } >> >> +#ifdef __GNUC__ >> +__attribute__((always_inline)__) >> +#endif >> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); >> -------------- >> >> If this patch is accepted, I will file it to JBS and will upload >> webrev. >> >> Thanks, >> >> Yasumasa >> >> From markus.gronlund at oracle.com Fri Mar 13 14:11:14 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 13 Mar 2015 07:11:14 -0700 (PDT) Subject: RFR (S) : 8073607 : add trace events for inlining In-Reply-To: <54FF1E92.8020302@oracle.com> References: <54ECE8E0.2080201@oracle.com> <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> <54FF1E92.8020302@oracle.com> Message-ID: HI Igor, Looks good! Thanks Markus -----Original Message----- From: Igor Ignatyev Sent: den 10 mars 2015 17:41 To: Markus Gronlund; erik.gahlin at oracle.com >> Erik Gahlin Cc: hotspot-compiler-dev at openjdk.java.net compiler; serviceability-dev at openjdk.java.net Subject: Re: RFR (S) : 8073607 : add trace events for inlining Hi Markus/Erik, I've slightly updated the patch according to your comments: - changed event path to 'vm/compiler/optimization/inlining' - replaced acronym BCI by its meaning Also I changed caller type to 'Method*'. http://cr.openjdk.java.net/~iignatyev/8073607/webrev.01/ Igor On 02/27/2015 01:25 PM, Markus Gronlund wrote: > Hi Igor, > > In trace.xml: > > > 404 > 405 > 406 > 407 > > You don't need to write an individual UTF8 string for every class, method and desc as we have "intrinsics" for taking care of this for you. > > This also means you wouldn't need to create a separate struct, as you can just define the necessary fields as type METHOD in the CompilerInlining event: > > 410 has_thread="true" is_instant="true"> > 411 > 412 > 413 > 414 > 415 > 416 > 417 > > > // I also removed these attributes " is_requestable="false" is_constant="false" - they are defaults. I changed to "is_instant=true" since it looks like the event does not span over a duration in bytecodeInfo.cpp. > > At the event site, you will now need to pass the Hotspot Method* as the values (unsure how you pull that out of a ci* artifact, but you have the Metadata* for the Method there somewhere): > > result.set_caller(Method* caller_method); > result.set_callee(Method* callee_method); > > Thanks > Markus > > -----Original Message----- > From: Igor Ignatyev > Sent: den 24 februari 2015 22:11 > To: hotspot-compiler-dev at openjdk.java.net compiler; serviceability-dev at openjdk.java.net > Subject: RFR (S) : 8073607 : add trace events for inlining > > Hi guys, > > could you please review the patch which adds trace events for inlining for c1/c2 compiler? > > An added event provides information about caller, callee, bci, inline status and message. > > webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 > -- > Igor > From yekaterina.kantserova at oracle.com Fri Mar 13 14:23:56 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 13 Mar 2015 07:23:56 -0700 (PDT) Subject: RFR(S): 8073794: jdk/test/com/sun/jdi/BadHandshakeTest.java should retry if tcp port is taken Message-ID: <6397c528-b195-4880-9370-98ce3707dd14@default> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8073794 webrev: http://cr.openjdk.java.net/~ykantser/8073794/webrev.00/ Thanks, Katja From coleen.phillimore at oracle.com Fri Mar 13 17:40:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Mar 2015 13:40:43 -0400 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5502755A.5060309@oracle.com> References: <5502755A.5060309@oracle.com> Message-ID: <5503211B.90309@oracle.com> Serguei, This looks good. This works a lot harder to find the original method than the code used to. Thanks, Coleen On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ > > > Open webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ > > > > Summary: > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > The plan is also to backport the fix to 8u60. > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei From jaroslav.bachorik at oracle.com Fri Mar 13 18:00:22 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 13 Mar 2015 19:00:22 +0100 Subject: RFR(S): 8073794: jdk/test/com/sun/jdi/BadHandshakeTest.java should retry if tcp port is taken In-Reply-To: <6397c528-b195-4880-9370-98ce3707dd14@default> References: <6397c528-b195-4880-9370-98ce3707dd14@default> Message-ID: <550325B6.6010200@oracle.com> Hi Katja, Thumbs up! -JB- On 13.3.2015 15:23, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8073794 > webrev: http://cr.openjdk.java.net/~ykantser/8073794/webrev.00/ > > Thanks, > Katja > From serguei.spitsyn at oracle.com Fri Mar 13 18:36:13 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Mar 2015 11:36:13 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5503211B.90309@oracle.com> References: <5502755A.5060309@oracle.com> <5503211B.90309@oracle.com> Message-ID: <55032E1D.6080403@oracle.com> Coleen, Thank you for review and great idea to use the method name cp index! However, this approach is going stop working if we get rid of the CP merge in the future. Thanks, Serguei On 3/13/15 10:40 AM, Coleen Phillimore wrote: > > Serguei, > > This looks good. This works a lot harder to find the original method > than the code used to. > > Thanks, > Coleen > > On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >> >> >> Open webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >> >> >> >> Summary: >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> The plan is also to backport the fix to 8u60. >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei > From coleen.phillimore at oracle.com Fri Mar 13 18:37:52 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Mar 2015 14:37:52 -0400 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55032E1D.6080403@oracle.com> References: <5502755A.5060309@oracle.com> <5503211B.90309@oracle.com> <55032E1D.6080403@oracle.com> Message-ID: <55032E80.9060008@oracle.com> On 3/13/15, 2:36 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > Thank you for review and great idea to use the method name cp index! > However, this approach is going stop working if we get rid of the CP > merge in the future. Yes, it will. I was just thinking about how to resolve that. We'll have to brainstorm this in the summer. Coleen > > Thanks, > Serguei > > On 3/13/15 10:40 AM, Coleen Phillimore wrote: >> >> Serguei, >> >> This looks good. This works a lot harder to find the original method >> than the code used to. >> >> Thanks, >> Coleen >> >> On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 9 fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>> >>> >>> Open hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >>> >>> >>> Open webrev for unit test update: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >>> >>> >>> >>> Summary: >>> An NPE is trown in a thread dumping via JMX when doing CPU >>> profiling in NetBeans Profiler and VisualVM. >>> The issue is that the methods and related klass versions are not >>> kept alive if a class redefinition >>> takes place between catching a Throwable and taking a thread dump. >>> It can result in loosing an obsolete method, and so, the >>> reconstruction of method name becomes impossible. >>> In such a case, the null reference is returned instead of a valid >>> method name. >>> >>> The solution is to use current klass version and method orig_idnum >>> instead of ordinary method idnum >>> to find required method pointer. In the worst case when the >>> related klass version is gone >>> (was not included to or was removed from the previous_versions >>> linked list), a saved method name >>> CP index of the latest klass version can be used to restore the >>> method name. >>> The footprint extra overhead for this approach is u2 per stack frame. >>> >>> The plan is also to backport the fix to 8u60. >>> >>> Testing: >>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>> >>> >>> Thanks, >>> Serguei >> > From yekaterina.kantserova at oracle.com Mon Mar 16 07:41:17 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 16 Mar 2015 08:41:17 +0100 Subject: RFR(S): 8073794: jdk/test/com/sun/jdi/BadHandshakeTest.java should retry if tcp port is taken In-Reply-To: <550325B6.6010200@oracle.com> References: <6397c528-b195-4880-9370-98ce3707dd14@default> <550325B6.6010200@oracle.com> Message-ID: <5506891D.4070303@oracle.com> Thanks Jaroslav! // Katja On 03/13/2015 07:00 PM, Jaroslav Bachorik wrote: > Hi Katja, > > Thumbs up! > > -JB- > > On 13.3.2015 15:23, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8073794 >> webrev: http://cr.openjdk.java.net/~ykantser/8073794/webrev.00/ >> >> Thanks, >> Katja >> > From volker.simonis at gmail.com Tue Mar 17 17:40:09 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 17 Mar 2015 18:40:09 +0100 Subject: RFR(XS): 8071687: AIX port of "8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework" Message-ID: Hi, can I please have a review for this AIX-only change. It is an exact copy of the changes done in "8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework" into the corresponding AIX files. http://cr.openjdk.java.net/~simonis/webrevs/2015/8071687 https://bugs.openjdk.java.net/browse/JDK-8071687 Thank you and best regards, Volker From staffan.larsen at oracle.com Tue Mar 17 18:55:30 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Mar 2015 19:55:30 +0100 Subject: RFR(XS): 8071687: AIX port of "8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework" In-Reply-To: References: Message-ID: Looks good to me. Sorry I didn?t do those changes as well. /Staffan > On 17 mar 2015, at 18:40, Volker Simonis wrote: > > Hi, > > can I please have a review for this AIX-only change. > > It is an exact copy of the changes done in "8039173: Propagate errors > from Diagnostic Commands as exceptions in the attach framework" into > the corresponding AIX files. > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8071687 > https://bugs.openjdk.java.net/browse/JDK-8071687 > > Thank you and best regards, > Volker From volker.simonis at gmail.com Wed Mar 18 08:08:03 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Mar 2015 09:08:03 +0100 Subject: RFR(XS): 8071687: AIX port of "8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework" In-Reply-To: References: Message-ID: No problem:) Thanks for the review, Volker On Tue, Mar 17, 2015 at 7:55 PM, Staffan Larsen wrote: > Looks good to me. Sorry I didn?t do those changes as well. > > /Staffan > >> On 17 mar 2015, at 18:40, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for this AIX-only change. >> >> It is an exact copy of the changes done in "8039173: Propagate errors >> from Diagnostic Commands as exceptions in the attach framework" into >> the corresponding AIX files. >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8071687 >> https://bugs.openjdk.java.net/browse/JDK-8071687 >> >> Thank you and best regards, >> Volker > From yekaterina.kantserova at oracle.com Wed Mar 18 16:37:23 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 18 Mar 2015 17:37:23 +0100 Subject: RFR(XXS): 8064923: [TESTBUG] jps doesn't display anything on embedded platforms and it causes some tests to fail Message-ID: <5509A9C3.3010102@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8064923 webrev: http://cr.openjdk.java.net/~ykantser/8064923/webrev.00/ Thanks, Katja From erik.gahlin at oracle.com Wed Mar 18 17:25:19 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 18 Mar 2015 18:25:19 +0100 Subject: RFR(XXS): 8064923: [TESTBUG] jps doesn't display anything on embedded platforms and it causes some tests to fail In-Reply-To: <5509A9C3.3010102@oracle.com> References: <5509A9C3.3010102@oracle.com> Message-ID: <5509B4FF.3050006@oracle.com> Looks good. Erik Yekaterina Kantserova skrev den 18/03/15 17:37: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8064923 > webrev: http://cr.openjdk.java.net/~ykantser/8064923/webrev.00/ > > Thanks, > Katja From jaroslav.bachorik at oracle.com Wed Mar 18 17:33:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 18 Mar 2015 18:33:47 +0100 Subject: RFR(XXS): 8064923: [TESTBUG] jps doesn't display anything on embedded platforms and it causes some tests to fail In-Reply-To: <5509B4FF.3050006@oracle.com> References: <5509A9C3.3010102@oracle.com> <5509B4FF.3050006@oracle.com> Message-ID: <5509B6FB.6000507@oracle.com> Thumbs up! On 18.3.2015 18:25, Erik Gahlin wrote: > Looks good. > > Erik > > Yekaterina Kantserova skrev den 18/03/15 17:37: >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8064923 >> webrev: http://cr.openjdk.java.net/~ykantser/8064923/webrev.00/ >> >> Thanks, >> Katja > From eamonn at mcmanus.net Wed Mar 18 22:28:18 2015 From: eamonn at mcmanus.net (Eamonn McManus) Date: Wed, 18 Mar 2015 15:28:18 -0700 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: <54F75127.4060205@oracle.com> References: <54F5E108.3010902@oracle.com> <54F6C6B0.2040908@oracle.com> <54F75127.4060205@oracle.com> Message-ID: > Mainly because the long term goal (beyond the scope of this JEP, anyway) would be to get users to slowly migrate to the annotation based M(X)Beans. Not giving them the chance to specify the service interface via annotations will mean keeping this dichotomy forever. I'm not sure that is a good goal. M(X)Bean interfaces allow clients to make proxies, and there's no obvious equivalent with annotations. Though I suppose you could provide a standard annotation processor that would generate the implied interface from the annotations. Re @Notification: Please don't add types to the JMX API with the same name as types that are already there. That will make the API very unpleasant to use. I don't understand what this text means: "It can also be used as a parameter annotation for a field of type NotificationSender." Is it applied to parameters or fields? The code example shows the former, but that seems a bit limiting. What if the MBean wants to send a notification at some point unrelated to method invocation? ?amonn 2015-03-04 10:38 GMT-08:00 Jaroslav Bachorik : > Thanks for taking the time to review this. > I apologize for the formatting mess - clearly the JIRA's markdown processor > is rather confused with more extensive usage of the code blocks. > > On 4.3.2015 18:42, Eamonn McManus wrote: >> >> Thank you for updating the JEP text referencing JSR 255. >> >> Perhaps unsurprisingly I disagree with many of the differences between >> this proposal and the one we carefully thought out in JSR 255. Even >> though a lot has changed in the meanwhile, I don't see anything that >> invalidates our assumptions of the time. >> >> For reference, a snapshot of the JSR 255 javadoc is at >> http://hg.openjdk.java.net/jmx2/jmx2/file/f417598a7b72/javadoc. >> Unfortunately, it appears that the Mercurial server now serves these >> files as application/binary, probably because of the change here: >> >> http://mercurial.selenic.com/wiki/UpgradeNotes#A1.9.1:_guessmime.2C_revert_behavior_restored. >> >> To address some specific points: >>> >>> would you care to elaborate what you find to be not "even correct Java"? >> >> >> As of Java 8, annotation elements cannot have null values so the >> "default null" clauses are nonsense. I have not seen any proposal to >> change this in Java 9. The @ManagedBean definition also has an obvious >> syntax error. > > > Agreed. They should not be there. During the updates JIRA failed to update > the field and I failed to notice that my edits didn't apply. > >> >>> - ability to annotate fields turning them into attributes >> >> >> This might be useful for read-only attributes. I'd question whether it >> is useful for read/write attributes, because I think it will be very >> unusual for you to want neither validation of the new value nor >> behaviour to be triggered by the set. > > > On the other hand it gives the possibility to expose those read-only fields > (eg. metrics or settings being immutable via JMX) without the necessity to > conjure the getter. > >> >>> - ability to provide metadata directly in the annotations, not relying >>> solely on inferring them from the annotated element >> >> >> I'm not sure what specifically this refers to. Do you mean for example >> that it is possible to add @ManagedAttribute to a method that does not >> look like getFoo() and nevertheless have the annotation say that the >> attribute is called foo? I don't see any particular advantage to that >> flexibility. The getFoo() pattern is already familiar, and having a >> second, completely different way of specifying the name just >> complicates the spec for not much benefit. > > > And yet it can be done in DynamicMBeans. My starting point was the attempt > to give the user the same flexibility she would have if she were > hand-crafting the various MBean*Info classes. > >> >>> - missing @ManagedConstructor to expose a constructor >> >> >> We deliberately omitted this. The fact that MBeanConstructorInfo >> exists at all is in my opinion a mistake in the original JMX >> specification. What does it mean for an MBean to tell you how to >> construct another instance of itself? And if the purpose is to specify >> which constructors from this class are available to the MBean Server, >> there's no use for names and descriptions, and there's no particular >> advantage over just saying that all public constructors are available. > > > I don't know the meaning. I was not involved in the inception of this API. > My reasoning is that if you can do it by hand than it should probably be > achievable by annotation as well. The other route would be deprecating the > MBeanConstructorInfo now and removing it in a subsequent release. > >> >>> - optional 'service' argument to @ManagedBean annotation which will be >>> reflected in the descriptor's 'interfaceClassName' field to provide a >>> guidance about the recommended service interface when using >>> JMX.newMXBeanProxy() >> >> >> If you have such an interface, why wouldn't you just use it to define >> the MBean and dispense with annotations? > > > Mainly because the long term goal (beyond the scope of this JEP, anyway) > would be to get users to slowly migrate to the annotation based M(X)Beans. > Not giving them the chance to specify the service interface via annotations > will mean keeping this dichotomy forever. > >> >> Some other comments: >> >> * @ManagedBean. >> >> We called this @MBean because we also had an @MXBean annotation. That >> annotation exists today, but JSR 255 allowed it to be applied to a >> class as well as to an interface. It appears that @ManagedBean only >> defines MXBeans, which is a legitimate choice but, first, it should be >> called out more explicitly, and, second, wouldn't it then make sense >> to extend the existing @MXBean annotation? > > > I thought about this and extending an existing annotation is pretty > sensitive from the compatibility PoV. Also, giving the annotation different > meanings depending whether it is used on interface or class is rather > wobbly. I am still open to suggestions for better naming, though. > >> >> The specification is inconsistent as to whether the annotation is >> @ManagedBean or @MBean. >> >> I think it is a fair idea to have an objectName field, but the idea of >> randomly appending numbers to the name for disambiguation is broken. > > > Ok. Valid point. > >> Something like @ObjectNameTemplate from JSR 255 is more appropriate. > > > Yes, but it brings even more complexity. > >> >> The text for the notifications() member references @TypeMapping but >> does not say what that is. The declared type is Notification[] and the >> text defines an annotation @Notification, but there is already a class >> called Notification in javax.management. > > > The annotations should be placed in a sub-package of "javax.management". The > "javax.management" is pretty crowded already. > >> >> I think that the simple "name=value" syntax used by JSR 255's >> @DescriptorFields is preferable to the unspecified and verbose type >> @Tag. I don't see an advantage to making people write @Tag(name = >> "foo", value = "bar") rather than just "foo=bar". This syntax is >> already present in the JMX spec, for example in the >> ImmutableDescriptor constructor. > > > IMO, having just plain text there will open door for spurious errors due to > typos in delimiters. But that's just my experience. > >> >> * @Notification. >> >> As I mentioned, you can't use that name. >> >> The first paragraph of the description is indecipherable. >> >> The NotificationSender interface is unspecified. Based on the example, >> I think it could potentially be a major usability improvement but it's >> hard to be sure. > > > I can add this interface to the proposal. The reason for it not being > explicitly specified is that it is still very prototypical. > >> >> I think it's extremely ugly to propagate the misspelling clazz into an >> API where people will have to write it. Also, if it must extend >> Notification then it should be specified as Class> Notification>. > > > The problem is that using the rather obvious "type" creates confusion with > the "types". I can't use "class", of course. I am not too happy about this > name either but anything else will just be more verbose. > >> >> * @ManagedAttribute >> >> It's extremely strange for this to have getter and setter fields. Why >> wouldn't it just be applied to those methods? > > > Less boilerplate. One wouldn't need to retype the whole @ManagedAttribute > definition twice. > >> >> Promoting units from a descriptor field to a separate annotation >> member seems like a good idea. The specified value would be copied >> into the Descriptor. > > > Exactly. > >> >> * @ManagedOperation >> >> I don't see any reason to allow the name to be different from the >> method name. It just complicates the spec. > > > Well, you can do it manually. But I am open here - it would be nice to hear > from potential users whether this would make sense. > >> >> Instead of repeating a description member inside every annotation, JSR >> 255 defined a top-level @Description, which included elements for >> internationalization. Hardcoded strings are a step backwards. > > > Until we have support for providing the client locale to the JMX server any > internationalization is rather illusionary. > >> >> Defining Impact inside this annotation is questionable. I'd expect >> user code and possible future API changes to want to reference it >> independently of the annotation. Also, the JSR 255 enum Impact had >> methods to convert to and from the integer codes used by >> MBeanOperationInfo. > > > Please, consider class packaging being transitional. The classes may change > their locations during the draft review. > >> >> * @ManagedParameter >> >> The text repeatedly says operation name and method name when it means >> parameter name. I assume that if the name member is empty then the >> parameter name from reflection is used, which since Java 8 could be >> the actual name of the parameter if the class was compiled with >> -parameters. > > > Precisely. > >> >> * @RegistrationHandler >> >> It seems like an API smell for an annotation to say that it must be >> applied to methods with a certain signature. I think a much better >> approach would be to change the existing MBeanRegistration interface >> so that its methods have default implementations that do nothing. That >> removes the main reason that this interface is a pain: having to >> implement four methods when you're usually only interested in one. You >> could also add a preDeregister overload with MBeanServer and >> ObjectName parameters, again with a default implementation. > > > Well, @ManagedAttribute must be applied to methods of certain signatures > only, too. > > I wanted to avoid the necessity for the annotated M(X)Bean to implement any > other JMX specific interfaces explicitly. Therefore I proposed this > annotation. > > -JB- > > > >> >> ?amonn >> >> >> 2015-03-04 0:47 GMT-08:00 Jaroslav Bachorik >> : >>> >>> On 4.3.2015 02:09, Eamonn McManus wrote: >>>> >>>> >>>> Could you explain what you mean by this, regarding the annotations >>>> that were already agreed on by the JSR 255 Expert Group: >>>> >>>> * Smaller scope compared to the proposed solution >>> >>> >>> >>> This is a leftover from the previous proposal which had wider scope than >>> what is presented now. Still a few points remain. >>> >>> - ability to annotate fields turning them into attributes >>> - ability to provide metadata directly in the annotations, not relying >>> solely on inferring them from the annotated element >>> - missing @ManagedConstructor to expose a constructor >>> - optional 'service' argument to @ManagedBean annotation which will be >>> reflected in the descriptor's 'interfaceClassName' field to provide a >>> guidance about the recommended service interface when using >>> JMX.newMXBeanProxy() >>> >>>> * Conceptually in pre JDK7 era >>> >>> >>> >>> I am afraid this relates more to the implementation - or at least the >>> code I >>> was able to reconstruct from the repo history. Shouldn't be mentioned >>> here. >>> >>>> >>>> I have a number of other comments, but procedurally I'm not sure what >>>> the precedent is for summarily discarding work previously done in the >>>> JCP on the same subject. I'd certainly have expected this JEP to start >>>> from that work, rather than proposing a starting point that isn't even >>>> correct Java. >>> >>> >>> >>> Well, this is a draft review. The JSR 255 annotations work is not >>> discarded. >>> It is mentioned in the alternatives. The purpose of the open review is to >>> find out whether it is ok to continue with proposed feature, modify it to >>> use eg. JSR 255 work or abandon it completely. >>> >>> -JB- >>> >>> >>>> >>>> ?amonn McManus, former JSR 255 Spec Lead >>>> >>>> 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik >>>> : >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> Please review this draft JEP for JMX Specific Annotations for >>>>> Registration of Managed Resources: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8044507 >>>>> >>>>> Background: >>>>> Current mechanism of defining an MBean requires to provide an MBean >>>>> interface and its implementation. The interface and the implementation >>>>> must >>>>> conform to the strict naming and visibility rules in order for the >>>>> introspection to be able to bind them. >>>>> >>>>> At least the same level of verbosity is required when adding an >>>>> MBeanInfo >>>>> to generate MBean metadata. >>>>> >>>>> All this leads to a rather verbose code containing a lot of repeating >>>>> boilerplate parts even for the most simple MBean registrations. >>>>> >>>>> This JEP proposes to add a set of annotations for registration and >>>>> configuration of manageable resources (in other word 'MBeans'). These >>>>> annotations will be used to generate all the metadata necessary for a >>>>> resources to be accepted by the current JMX system. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> >>> >>> > From yekaterina.kantserova at oracle.com Thu Mar 19 07:38:46 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 19 Mar 2015 08:38:46 +0100 Subject: RFR(XXS): 8064923: [TESTBUG] jps doesn't display anything on embedded platforms and it causes some tests to fail In-Reply-To: <5509B4FF.3050006@oracle.com> References: <5509A9C3.3010102@oracle.com> <5509B4FF.3050006@oracle.com> Message-ID: <550A7D06.30009@oracle.com> Erik, Jaroslav, thanks for your reviews! // Katja On 03/18/2015 06:25 PM, Erik Gahlin wrote: > Looks good. > > Erik > > Yekaterina Kantserova skrev den 18/03/15 17:37: >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8064923 >> webrev: http://cr.openjdk.java.net/~ykantser/8064923/webrev.00/ >> >> Thanks, >> Katja > From jaroslav.bachorik at oracle.com Thu Mar 19 09:59:23 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 19 Mar 2015 10:59:23 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' Message-ID: <550A9DFB.1070204@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. JVMTI.data_dump will send the data dump request to JVMTI. Both of these commands are covered by the corresponding tests. Thanks, -JB- From frederic.parain at oracle.com Thu Mar 19 11:20:16 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Mar 2015 12:20:16 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550A9DFB.1070204@oracle.com> References: <550A9DFB.1070204@oracle.com> Message-ID: <550AB0F0.1010100@oracle.com> Jaroslav, src/share/vm/services/diagnosticCommand.cpp No comments src/share/vm/services/diagnosticCommand.hpp Why adding #include "services/attachListener.hpp" ? test/serviceability/dcmd/jvmti/DataDumpDcmdTest.java test/serviceability/dcmd/vm/SetVMFlagTest.java I don't know the new test framework, so I cannot comment on these files. Regards, Fred On 03/19/2015 10:59 AM, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 > Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 > > This patch is about adding 2 new diagnostic commands - VM.set_flag and > JVMTI.data_dump. > > VM.set_flag allows to set any writeable flag. It takes the flag name and > the flag value in textual form. The mutability of the flag and the value > format checks are forwarded to the shared vm management code. > > JVMTI.data_dump will send the data dump request to JVMTI. > > Both of these commands are covered by the corresponding tests. > > Thanks, > > -JB- -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From serguei.spitsyn at oracle.com Thu Mar 19 16:16:47 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 Mar 2015 09:16:47 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5503211B.90309@oracle.com> References: <5502755A.5060309@oracle.com> <5503211B.90309@oracle.com> Message-ID: <550AF66F.8000102@oracle.com> I need another reviewer for this. Thanks, Serguei On 3/13/15 10:40 AM, Coleen Phillimore wrote: > > Serguei, > > This looks good. This works a lot harder to find the original method > than the code used to. > > Thanks, > Coleen > > On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >> >> >> Open webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >> >> >> >> Summary: >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> The plan is also to backport the fix to 8u60. >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei > From daniel.daugherty at oracle.com Thu Mar 19 18:11:16 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Mar 2015 12:11:16 -0600 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5502755A.5060309@oracle.com> References: <5502755A.5060309@oracle.com> Message-ID: <550B1144.303@oracle.com> On 3/12/15 11:27 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ > Thumbs up. None of these comments are critical. src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/classfile/javaClasses.cpp line 1316: return method != NULL && (method->constants()->version() == version line 1317: && version < MAX_VERSION); Don't really need the parens and the indenting implies a logical grouping that isn't really there. Perhaps: return method != NULL && method->constants()->version() == version && version < MAX_VERSION; Although I also wonder why the caller would pass a 'version' value that is >= MAX_VERSION. Perhaps this instead: assert(version < MAX_VERSION, "version is too big"); return method != NULL && method->constants()->version() == version line 1347: typeArrayOop _cprefs; Perhaps add a comment: // needed to insulate method name against redefinition line 1486: holder = holder->get_klass_version(version); // Use specific ik version as a holder Perhaps the following comment instead: // Use specific ik version as a holder since the mirror might // refer to version that is now obsolete. I'm not sure "obsolete" is the right term here, but say something about why the mirror version is not good enough. Update: 'obsolete' is the right term now that I've re-read the code review invite! Perhaps this is better: // Use specific ik version as a holder since the mirror might // refer to version that is now obsolete and no longer accessible // via the previous versions list. line 1854: // Get method id, cpref, bci, version and mirror from chunk Perhaps: // Get method id, bci, version, mirror and cpref from chunk since that's the order you do the work... line 1909: holder = holder->get_klass_version(version); // Use specific ik version as a holder Similar comment as on line 1486. src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/oops/instanceKlass.cpp No comments. > Open webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ > test/java/lang/instrument/RedefineMethodInBacktrace.sh No comments. test/java/lang/instrument/RedefineMethodInBacktraceApp.java line 175: System.exit(1); A comment to explain why this test needs to exit on failure would be good. When the work to get rid of shell script driven tests gets here, it would be useful for understanding why this test must be standalone. test/java/lang/instrument/RedefineMethodInBacktraceTarget.java No comments. test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java No comments. test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java No comments. test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java No commetns. Dan > > > Summary: > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > The plan is also to backport the fix to 8u60. > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > > From coleen.phillimore at oracle.com Thu Mar 19 18:16:03 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 19 Mar 2015 14:16:03 -0400 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55032E80.9060008@oracle.com> References: <5502755A.5060309@oracle.com> <5503211B.90309@oracle.com> <55032E1D.6080403@oracle.com> <55032E80.9060008@oracle.com> Message-ID: <550B1263.9010406@oracle.com> On 3/13/15, 2:37 PM, Coleen Phillimore wrote: > > On 3/13/15, 2:36 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> Thank you for review and great idea to use the method name cp index! >> However, this approach is going stop working if we get rid of the CP >> merge in the future. > > Yes, it will. I was just thinking about how to resolve that. We'll > have to brainstorm this in the summer. There's still a huge snowbank outside my window, but I've been thinking about this. I have been working on the enhanced class redefinition sources. This is how we can resolve the stack trace problem, which is better than what we have today: When we do a class redefinition with enhanced class redefinition, we walk the heap to replace oop->_klass fields with the new classes. We replace a few other things too. We can change backtraces to have the Method* again and when we walk the heap during redefinition, we can also build a GrowableArray of all Method* found in the backtraces. This GrowableArray of Method* can be used to mark the Method* on_stack so that they are not deallocated during class unloading. If the method isn't deallocated, neither is the old class where it came from. This is good because we can get the line number at bci and source file name also from the old Method*. Coleen > Coleen > >> >> Thanks, >> Serguei >> >> On 3/13/15 10:40 AM, Coleen Phillimore wrote: >>> >>> Serguei, >>> >>> This looks good. This works a lot harder to find the original >>> method than the code used to. >>> >>> Thanks, >>> Coleen >>> >>> On 3/13/15, 1:27 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the jdk 9 fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>> >>>> >>>> Open hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >>>> >>>> >>>> Open webrev for unit test update: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >>>> >>>> >>>> >>>> Summary: >>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>> profiling in NetBeans Profiler and VisualVM. >>>> The issue is that the methods and related klass versions are not >>>> kept alive if a class redefinition >>>> takes place between catching a Throwable and taking a thread dump. >>>> It can result in loosing an obsolete method, and so, the >>>> reconstruction of method name becomes impossible. >>>> In such a case, the null reference is returned instead of a valid >>>> method name. >>>> >>>> The solution is to use current klass version and method >>>> orig_idnum instead of ordinary method idnum >>>> to find required method pointer. In the worst case when the >>>> related klass version is gone >>>> (was not included to or was removed from the previous_versions >>>> linked list), a saved method name >>>> CP index of the latest klass version can be used to restore the >>>> method name. >>>> The footprint extra overhead for this approach is u2 per stack >>>> frame. >>>> >>>> The plan is also to backport the fix to 8u60. >>>> >>>> Testing: >>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>>> >>>> >>>> Thanks, >>>> Serguei >>> >> > From serguei.spitsyn at oracle.com Thu Mar 19 18:37:14 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 Mar 2015 11:37:14 -0700 Subject: RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <550B1144.303@oracle.com> References: <5502755A.5060309@oracle.com> <550B1144.303@oracle.com> Message-ID: <550B175A.9060405@oracle.com> On 3/19/15 11:11 AM, Daniel D. Daugherty wrote: > On 3/12/15 11:27 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.1/ >> > > Thumbs up. None of these comments are critical. Thanks a lot for the review, Dan! > > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/classfile/javaClasses.cpp > > line 1316: return method != NULL && > (method->constants()->version() == version > line 1317: && version < MAX_VERSION); > Don't really need the parens and the indenting implies > a logical grouping that isn't really there. Perhaps: > > return method != NULL && method->constants()->version() == > version > && version < MAX_VERSION; > > Although I also wonder why the caller would pass a 'version' > value that is >= MAX_VERSION. Perhaps this instead: > > assert(version < MAX_VERSION, "version is too big"); > return method != NULL && method->constants()->version() == > version > > line 1347: typeArrayOop _cprefs; > Perhaps add a comment: // needed to insulate method name > against redefinition > > line 1486: holder = holder->get_klass_version(version); // Use > specific ik version as a holder > Perhaps the following comment instead: > > // Use specific ik version as a holder since the mirror might > // refer to version that is now obsolete. > > I'm not sure "obsolete" is the right term here, but say > something about why the mirror version is not good enough. > > Update: 'obsolete' is the right term now that I've re-read the > code review invite! Perhaps this is better: > > // Use specific ik version as a holder since the mirror might > // refer to version that is now obsolete and no longer accessible > // via the previous versions list. > > line 1854: // Get method id, cpref, bci, version and mirror from > chunk > Perhaps: > > // Get method id, bci, version, mirror and cpref from chunk > > since that's the order you do the work... > > line 1909: holder = holder->get_klass_version(version); // Use > specific ik version as a holder > Similar comment as on line 1486. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > >> Open webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.1/ >> > > test/java/lang/instrument/RedefineMethodInBacktrace.sh > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceApp.java > line 175: System.exit(1); > A comment to explain why this test needs to exit on > failure would be good. When the work to get rid of > shell script driven tests gets here, it would be > useful for understanding why this test must be > standalone. All of the above suggestions are good. Will update before the push. Thanks! > > test/java/lang/instrument/RedefineMethodInBacktraceTarget.java > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java > No commetns. > Thanks! Serguei > > Dan > > >> >> >> Summary: >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> The plan is also to backport the fix to 8u60. >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> >> > From alexander.kulyakhtin at oracle.com Fri Mar 20 12:16:32 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 20 Mar 2015 05:16:32 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: Hi, Could you, please, review the fix below. CR: https://bugs.openjdk.java.net/browse/JDK-8075586 webrev: http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ The fix adds @modules keyword to the existing hotspot tests, as needed, so that the tests can access the required API when the new modular architecture is in place. Best regards, Alex From staffan.larsen at oracle.com Fri Mar 20 16:38:58 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 20 Mar 2015 17:38:58 +0100 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: References: Message-ID: <108932A4-E30A-42D7-8AA1-7080BAC98D8D@oracle.com> I haven?t looked at the changes in detail, but please change the requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. Thanks, /Staffan > On 20 mar 2015, at 13:16, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review the fix below. > > CR: https://bugs.openjdk.java.net/browse/JDK-8075586 > webrev: http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ > > The fix adds @modules keyword to the existing hotspot tests, as needed, so that the tests can access the required API when the new modular architecture is in place. > > Best regards, > Alex From dmitry.samersoff at oracle.com Sat Mar 21 10:50:09 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 21 Mar 2015 13:50:09 +0300 Subject: RFR(S, TEST) JDK-8075569: jmap test fails due to "ERROR: java.nio.file.NoSuchFileException: 2906081d-06bc-4738-a7e8-f37b8bf13658.lck Message-ID: <550D4CE1.6070201@oracle.com> Hi Everyone, Please review small, test only fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8075569/webrev.01/ Lock deleted while we are setting last modified time. Ignore error and lets the app exits -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Sat Mar 21 10:57:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Mar 2015 10:57:12 +0000 Subject: RFR(S, TEST) JDK-8075569: jmap test fails due to "ERROR: java.nio.file.NoSuchFileException: 2906081d-06bc-4738-a7e8-f37b8bf13658.lck In-Reply-To: <550D4CE1.6070201@oracle.com> References: <550D4CE1.6070201@oracle.com> Message-ID: <550D4E88.5050306@oracle.com> On 21/03/2015 10:50, Dmitry Samersoff wrote: > Hi Everyone, > > Please review small, test only fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8075569/webrev.01/ > > Lock deleted while we are setting last modified time. > Ignore error and lets the app exits > This looks okay to me but since it now handles the lock file going away at any time then the Files.exists can be removed if you want (it's harmless to keep it of course). -Alan From dmitry.samersoff at oracle.com Sat Mar 21 13:29:49 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 21 Mar 2015 16:29:49 +0300 Subject: RFR(S, TEST) JDK-8075569: jmap test fails due to "ERROR: java.nio.file.NoSuchFileException: 2906081d-06bc-4738-a7e8-f37b8bf13658.lck In-Reply-To: <550D4E88.5050306@oracle.com> References: <550D4CE1.6070201@oracle.com> <550D4E88.5050306@oracle.com> Message-ID: <550D724D.3020401@oracle.com> Alan, Thank you for the review. I agree that File.exists is no longer required, but I would prefer to keep it for better readability. -Dmitry On 2015-03-21 13:57, Alan Bateman wrote: > On 21/03/2015 10:50, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review small, test only fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8075569/webrev.01/ >> >> Lock deleted while we are setting last modified time. >> Ignore error and lets the app exits >> > This looks okay to me but since it now handles the lock file going away > at any time then the Files.exists can be removed if you want (it's > harmless to keep it of course). > > -Alan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Sat Mar 21 18:04:48 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Mar 2015 18:04:48 +0000 Subject: RFR(S, TEST) JDK-8075569: jmap test fails due to "ERROR: java.nio.file.NoSuchFileException: 2906081d-06bc-4738-a7e8-f37b8bf13658.lck In-Reply-To: <550D724D.3020401@oracle.com> References: <550D4CE1.6070201@oracle.com> <550D4E88.5050306@oracle.com> <550D724D.3020401@oracle.com> Message-ID: <550DB2C0.9080508@oracle.com> On 21/03/2015 13:29, Dmitry Samersoff wrote: > Alan, > > Thank you for the review. > > I agree that File.exists is no longer required, but I would prefer to > keep it for better readability. > > -Dmitry > > Fair enough, either way will work. From erik.gahlin at oracle.com Sat Mar 21 18:56:01 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sat, 21 Mar 2015 19:56:01 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550A9DFB.1070204@oracle.com> References: <550A9DFB.1070204@oracle.com> Message-ID: <550DBEC1.3030002@oracle.com> Looks good! Erik Jaroslav Bachorik skrev 2015-03-19 10:59: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 > Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 > > This patch is about adding 2 new diagnostic commands - VM.set_flag and > JVMTI.data_dump. > > VM.set_flag allows to set any writeable flag. It takes the flag name > and the flag value in textual form. The mutability of the flag and the > value format checks are forwarded to the shared vm management code. > > JVMTI.data_dump will send the data dump request to JVMTI. > > Both of these commands are covered by the corresponding tests. > > Thanks, > > -JB- From staffan.larsen at oracle.com Mon Mar 23 07:50:27 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Mar 2015 08:50:27 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550A9DFB.1070204@oracle.com> References: <550A9DFB.1070204@oracle.com> Message-ID: <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> diagnosticCommand.cpp: - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? - L227-234: strange indentation /Staffan > On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 > Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 > > This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. > > VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. > > JVMTI.data_dump will send the data dump request to JVMTI. > > Both of these commands are covered by the corresponding tests. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Mar 23 10:55:03 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 23 Mar 2015 11:55:03 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> References: <550A9DFB.1070204@oracle.com> <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> Message-ID: <550FF107.5030504@oracle.com> On 23.3.2015 08:50, Staffan Larsen wrote: > diagnosticCommand.cpp: > - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? Probably not. On the other hand, the JVMTIDataDumpDCmd registration should probably be guarded by #if INCLUDE_JVMTI > - L227-234: strange indentation Fixed. Updated webrev (+ removing the extraneous #include "services/attachListener.hpp" in diagnosticCommand.hpp) : http://cr.openjdk.java.net/~jbachorik/8054890/webrev.01 -JB- > > > /Staffan > > >> On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: >> >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 >> >> This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. >> >> VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. >> >> JVMTI.data_dump will send the data dump request to JVMTI. >> >> Both of these commands are covered by the corresponding tests. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Mon Mar 23 11:41:34 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Mar 2015 12:41:34 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <550FF107.5030504@oracle.com> References: <550A9DFB.1070204@oracle.com> <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> <550FF107.5030504@oracle.com> Message-ID: <743A07B6-736B-43FE-8961-6F6FB218AF63@oracle.com> Looks good! Thanks, /Staffan > On 23 mar 2015, at 11:55, Jaroslav Bachorik wrote: > > On 23.3.2015 08:50, Staffan Larsen wrote: >> diagnosticCommand.cpp: >> - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? > > Probably not. On the other hand, the JVMTIDataDumpDCmd registration should probably be guarded by #if INCLUDE_JVMTI > >> - L227-234: strange indentation > > Fixed. > > Updated webrev (+ removing the extraneous #include "services/attachListener.hpp" in diagnosticCommand.hpp) : http://cr.openjdk.java.net/~jbachorik/8054890/webrev.01 > > -JB- > > >> >> >> /Staffan >> >> >>> On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: >>> >>> Please, review the following change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 >>> >>> This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. >>> >>> VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. >>> >>> JVMTI.data_dump will send the data dump request to JVMTI. >>> >>> Both of these commands are covered by the corresponding tests. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Mon Mar 23 11:42:54 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 23 Mar 2015 12:42:54 +0100 Subject: RFR 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails Message-ID: <550FFC3E.4000209@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8024055 Webrev: http://cr.openjdk.java.net/~jbachorik/8024055/webrev.00 This request is a follow-up to the stalled review request http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-October/015785.html (the issue has changed its owner since then) As stated in the original request: " This patch fixes two intermittent issues seen over the past year: a) Possible failure where an existing pid-file is not owned by the test user b) Race during startup where we try to attach to the target before it?s ready (removed arbitrary 5sec sleep) " This version is addressing David's comment about better processing the target process' stdout directly and not asynchronously. Thanks, -JB- From jaroslav.bachorik at oracle.com Mon Mar 23 12:12:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 23 Mar 2015 13:12:47 +0100 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: References: <54F5E108.3010902@oracle.com> <54F6C6B0.2040908@oracle.com> <54F75127.4060205@oracle.com> Message-ID: <5510033F.8030205@oracle.com> On 18.3.2015 23:28, Eamonn McManus wrote: >> Mainly because the long term goal (beyond the scope of this JEP, anyway) would be to get users to slowly migrate to the annotation based M(X)Beans. Not giving them the chance to specify the service interface via annotations will mean keeping this dichotomy forever. > > I'm not sure that is a good goal. M(X)Bean interfaces allow clients to > make proxies, and there's no obvious equivalent with annotations. You still can create proxies for MXBeans defined through annotations - the 'service' attribute of '@ManagedBean' annotation serves exactly this purpose. The value of this attribute will be used in the associated Descriptor under the 'interfaceClassName' key. In fact, the resulting instance registered in the MBeanServer for an annotation based MXBean is undistinguishable from the one based on MXBean interface. > Though I suppose you could provide a standard annotation processor > that would generate the implied interface from the annotations. Yes, this might be an option. But probably beyond the scope of this JEP. I need to keep the change as simple as possible - otherwise it might not make it for JDK 9. > > Re @Notification: Please don't add types to the JMX API with the same > name as types that are already there. That will make the API very > unpleasant to use. Agreed. A nice, simple name for this annotation will have to be found. > > I don't understand what this text means: "It can also be used as a > parameter annotation for a field of type NotificationSender." Is it Should read '... for an argument of type NotificationSender' > applied to parameters or fields? The code example shows the former, > but that seems a bit limiting. What if the MBean wants to send a > notification at some point unrelated to method invocation? For the sakes of simplicity I opted for something that seemed to be the common case - sending notification from within the managed operations or attribute getters/setters. Could you come up with a use case when it is inevitable to send notification from a code not reachable either through a managed operation or attribute getter/setter? If it is something generally needed I might make the @Notification applicable to fields as well. Thanks, -JB- > > ?amonn > > > 2015-03-04 10:38 GMT-08:00 Jaroslav Bachorik : >> Thanks for taking the time to review this. >> I apologize for the formatting mess - clearly the JIRA's markdown processor >> is rather confused with more extensive usage of the code blocks. >> >> On 4.3.2015 18:42, Eamonn McManus wrote: >>> >>> Thank you for updating the JEP text referencing JSR 255. >>> >>> Perhaps unsurprisingly I disagree with many of the differences between >>> this proposal and the one we carefully thought out in JSR 255. Even >>> though a lot has changed in the meanwhile, I don't see anything that >>> invalidates our assumptions of the time. >>> >>> For reference, a snapshot of the JSR 255 javadoc is at >>> http://hg.openjdk.java.net/jmx2/jmx2/file/f417598a7b72/javadoc. >>> Unfortunately, it appears that the Mercurial server now serves these >>> files as application/binary, probably because of the change here: >>> >>> http://mercurial.selenic.com/wiki/UpgradeNotes#A1.9.1:_guessmime.2C_revert_behavior_restored. >>> >>> To address some specific points: >>>> >>>> would you care to elaborate what you find to be not "even correct Java"? >>> >>> >>> As of Java 8, annotation elements cannot have null values so the >>> "default null" clauses are nonsense. I have not seen any proposal to >>> change this in Java 9. The @ManagedBean definition also has an obvious >>> syntax error. >> >> >> Agreed. They should not be there. During the updates JIRA failed to update >> the field and I failed to notice that my edits didn't apply. >> >>> >>>> - ability to annotate fields turning them into attributes >>> >>> >>> This might be useful for read-only attributes. I'd question whether it >>> is useful for read/write attributes, because I think it will be very >>> unusual for you to want neither validation of the new value nor >>> behaviour to be triggered by the set. >> >> >> On the other hand it gives the possibility to expose those read-only fields >> (eg. metrics or settings being immutable via JMX) without the necessity to >> conjure the getter. >> >>> >>>> - ability to provide metadata directly in the annotations, not relying >>>> solely on inferring them from the annotated element >>> >>> >>> I'm not sure what specifically this refers to. Do you mean for example >>> that it is possible to add @ManagedAttribute to a method that does not >>> look like getFoo() and nevertheless have the annotation say that the >>> attribute is called foo? I don't see any particular advantage to that >>> flexibility. The getFoo() pattern is already familiar, and having a >>> second, completely different way of specifying the name just >>> complicates the spec for not much benefit. >> >> >> And yet it can be done in DynamicMBeans. My starting point was the attempt >> to give the user the same flexibility she would have if she were >> hand-crafting the various MBean*Info classes. >> >>> >>>> - missing @ManagedConstructor to expose a constructor >>> >>> >>> We deliberately omitted this. The fact that MBeanConstructorInfo >>> exists at all is in my opinion a mistake in the original JMX >>> specification. What does it mean for an MBean to tell you how to >>> construct another instance of itself? And if the purpose is to specify >>> which constructors from this class are available to the MBean Server, >>> there's no use for names and descriptions, and there's no particular >>> advantage over just saying that all public constructors are available. >> >> >> I don't know the meaning. I was not involved in the inception of this API. >> My reasoning is that if you can do it by hand than it should probably be >> achievable by annotation as well. The other route would be deprecating the >> MBeanConstructorInfo now and removing it in a subsequent release. >> >>> >>>> - optional 'service' argument to @ManagedBean annotation which will be >>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>> guidance about the recommended service interface when using >>>> JMX.newMXBeanProxy() >>> >>> >>> If you have such an interface, why wouldn't you just use it to define >>> the MBean and dispense with annotations? >> >> >> Mainly because the long term goal (beyond the scope of this JEP, anyway) >> would be to get users to slowly migrate to the annotation based M(X)Beans. >> Not giving them the chance to specify the service interface via annotations >> will mean keeping this dichotomy forever. >> >>> >>> Some other comments: >>> >>> * @ManagedBean. >>> >>> We called this @MBean because we also had an @MXBean annotation. That >>> annotation exists today, but JSR 255 allowed it to be applied to a >>> class as well as to an interface. It appears that @ManagedBean only >>> defines MXBeans, which is a legitimate choice but, first, it should be >>> called out more explicitly, and, second, wouldn't it then make sense >>> to extend the existing @MXBean annotation? >> >> >> I thought about this and extending an existing annotation is pretty >> sensitive from the compatibility PoV. Also, giving the annotation different >> meanings depending whether it is used on interface or class is rather >> wobbly. I am still open to suggestions for better naming, though. >> >>> >>> The specification is inconsistent as to whether the annotation is >>> @ManagedBean or @MBean. >>> >>> I think it is a fair idea to have an objectName field, but the idea of >>> randomly appending numbers to the name for disambiguation is broken. >> >> >> Ok. Valid point. >> >>> Something like @ObjectNameTemplate from JSR 255 is more appropriate. >> >> >> Yes, but it brings even more complexity. >> >>> >>> The text for the notifications() member references @TypeMapping but >>> does not say what that is. The declared type is Notification[] and the >>> text defines an annotation @Notification, but there is already a class >>> called Notification in javax.management. >> >> >> The annotations should be placed in a sub-package of "javax.management". The >> "javax.management" is pretty crowded already. >> >>> >>> I think that the simple "name=value" syntax used by JSR 255's >>> @DescriptorFields is preferable to the unspecified and verbose type >>> @Tag. I don't see an advantage to making people write @Tag(name = >>> "foo", value = "bar") rather than just "foo=bar". This syntax is >>> already present in the JMX spec, for example in the >>> ImmutableDescriptor constructor. >> >> >> IMO, having just plain text there will open door for spurious errors due to >> typos in delimiters. But that's just my experience. >> >>> >>> * @Notification. >>> >>> As I mentioned, you can't use that name. >>> >>> The first paragraph of the description is indecipherable. >>> >>> The NotificationSender interface is unspecified. Based on the example, >>> I think it could potentially be a major usability improvement but it's >>> hard to be sure. >> >> >> I can add this interface to the proposal. The reason for it not being >> explicitly specified is that it is still very prototypical. >> >>> >>> I think it's extremely ugly to propagate the misspelling clazz into an >>> API where people will have to write it. Also, if it must extend >>> Notification then it should be specified as Class>> Notification>. >> >> >> The problem is that using the rather obvious "type" creates confusion with >> the "types". I can't use "class", of course. I am not too happy about this >> name either but anything else will just be more verbose. >> >>> >>> * @ManagedAttribute >>> >>> It's extremely strange for this to have getter and setter fields. Why >>> wouldn't it just be applied to those methods? >> >> >> Less boilerplate. One wouldn't need to retype the whole @ManagedAttribute >> definition twice. >> >>> >>> Promoting units from a descriptor field to a separate annotation >>> member seems like a good idea. The specified value would be copied >>> into the Descriptor. >> >> >> Exactly. >> >>> >>> * @ManagedOperation >>> >>> I don't see any reason to allow the name to be different from the >>> method name. It just complicates the spec. >> >> >> Well, you can do it manually. But I am open here - it would be nice to hear >> from potential users whether this would make sense. >> >>> >>> Instead of repeating a description member inside every annotation, JSR >>> 255 defined a top-level @Description, which included elements for >>> internationalization. Hardcoded strings are a step backwards. >> >> >> Until we have support for providing the client locale to the JMX server any >> internationalization is rather illusionary. >> >>> >>> Defining Impact inside this annotation is questionable. I'd expect >>> user code and possible future API changes to want to reference it >>> independently of the annotation. Also, the JSR 255 enum Impact had >>> methods to convert to and from the integer codes used by >>> MBeanOperationInfo. >> >> >> Please, consider class packaging being transitional. The classes may change >> their locations during the draft review. >> >>> >>> * @ManagedParameter >>> >>> The text repeatedly says operation name and method name when it means >>> parameter name. I assume that if the name member is empty then the >>> parameter name from reflection is used, which since Java 8 could be >>> the actual name of the parameter if the class was compiled with >>> -parameters. >> >> >> Precisely. >> >>> >>> * @RegistrationHandler >>> >>> It seems like an API smell for an annotation to say that it must be >>> applied to methods with a certain signature. I think a much better >>> approach would be to change the existing MBeanRegistration interface >>> so that its methods have default implementations that do nothing. That >>> removes the main reason that this interface is a pain: having to >>> implement four methods when you're usually only interested in one. You >>> could also add a preDeregister overload with MBeanServer and >>> ObjectName parameters, again with a default implementation. >> >> >> Well, @ManagedAttribute must be applied to methods of certain signatures >> only, too. >> >> I wanted to avoid the necessity for the annotated M(X)Bean to implement any >> other JMX specific interfaces explicitly. Therefore I proposed this >> annotation. >> >> -JB- >> >> >> >>> >>> ?amonn >>> >>> >>> 2015-03-04 0:47 GMT-08:00 Jaroslav Bachorik >>> : >>>> >>>> On 4.3.2015 02:09, Eamonn McManus wrote: >>>>> >>>>> >>>>> Could you explain what you mean by this, regarding the annotations >>>>> that were already agreed on by the JSR 255 Expert Group: >>>>> >>>>> * Smaller scope compared to the proposed solution >>>> >>>> >>>> >>>> This is a leftover from the previous proposal which had wider scope than >>>> what is presented now. Still a few points remain. >>>> >>>> - ability to annotate fields turning them into attributes >>>> - ability to provide metadata directly in the annotations, not relying >>>> solely on inferring them from the annotated element >>>> - missing @ManagedConstructor to expose a constructor >>>> - optional 'service' argument to @ManagedBean annotation which will be >>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>> guidance about the recommended service interface when using >>>> JMX.newMXBeanProxy() >>>> >>>>> * Conceptually in pre JDK7 era >>>> >>>> >>>> >>>> I am afraid this relates more to the implementation - or at least the >>>> code I >>>> was able to reconstruct from the repo history. Shouldn't be mentioned >>>> here. >>>> >>>>> >>>>> I have a number of other comments, but procedurally I'm not sure what >>>>> the precedent is for summarily discarding work previously done in the >>>>> JCP on the same subject. I'd certainly have expected this JEP to start >>>>> from that work, rather than proposing a starting point that isn't even >>>>> correct Java. >>>> >>>> >>>> >>>> Well, this is a draft review. The JSR 255 annotations work is not >>>> discarded. >>>> It is mentioned in the alternatives. The purpose of the open review is to >>>> find out whether it is ok to continue with proposed feature, modify it to >>>> use eg. JSR 255 work or abandon it completely. >>>> >>>> -JB- >>>> >>>> >>>>> >>>>> ?amonn McManus, former JSR 255 Spec Lead >>>>> >>>>> 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik >>>>> : >>>>>> >>>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review this draft JEP for JMX Specific Annotations for >>>>>> Registration of Managed Resources: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8044507 >>>>>> >>>>>> Background: >>>>>> Current mechanism of defining an MBean requires to provide an MBean >>>>>> interface and its implementation. The interface and the implementation >>>>>> must >>>>>> conform to the strict naming and visibility rules in order for the >>>>>> introspection to be able to bind them. >>>>>> >>>>>> At least the same level of verbosity is required when adding an >>>>>> MBeanInfo >>>>>> to generate MBean metadata. >>>>>> >>>>>> All this leads to a rather verbose code containing a lot of repeating >>>>>> boilerplate parts even for the most simple MBean registrations. >>>>>> >>>>>> This JEP proposes to add a set of annotations for registration and >>>>>> configuration of manageable resources (in other word 'MBeans'). These >>>>>> annotations will be used to generate all the metadata necessary for a >>>>>> resources to be accepted by the current JMX system. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>> >>>> >>>> >> From staffan.larsen at oracle.com Mon Mar 23 12:44:48 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Mar 2015 13:44:48 +0100 Subject: RFR 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails In-Reply-To: <550FFC3E.4000209@oracle.com> References: <550FFC3E.4000209@oracle.com> Message-ID: <1A5AFAA8-9BC0-4F15-8CB1-80EF0E807C55@oracle.com> Looks good, but please print the exception at line 118 in AttachWithStalePidFile.java. Thanks, /Staffan > On 23 mar 2015, at 12:42, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8024055 > Webrev: http://cr.openjdk.java.net/~jbachorik/8024055/webrev.00 > > This request is a follow-up to the stalled review request http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-October/015785.html (the issue has changed its owner since then) > > As stated in the original request: > " > This patch fixes two intermittent issues seen over the past year: > > a) Possible failure where an existing pid-file is not owned by the test user > b) Race during startup where we try to attach to the target before it?s ready (removed arbitrary 5sec sleep) > " > > This version is addressing David's comment about better processing the target process' stdout directly and not asynchronously. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Mar 23 19:20:58 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 23 Mar 2015 20:20:58 +0100 Subject: RFR 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails In-Reply-To: <1A5AFAA8-9BC0-4F15-8CB1-80EF0E807C55@oracle.com> References: <550FFC3E.4000209@oracle.com> <1A5AFAA8-9BC0-4F15-8CB1-80EF0E807C55@oracle.com> Message-ID: <5510679A.3010609@oracle.com> On 23.3.2015 13:44, Staffan Larsen wrote: > Looks good, but please print the exception at line 118 in AttachWithStalePidFile.java. Hm, like this http://cr.openjdk.java.net/~jbachorik/8024055/webrev.01 ? -JB- > > Thanks, > /Staffan > >> On 23 mar 2015, at 12:42, Jaroslav Bachorik wrote: >> >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8024055 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8024055/webrev.00 >> >> This request is a follow-up to the stalled review request http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-October/015785.html (the issue has changed its owner since then) >> >> As stated in the original request: >> " >> This patch fixes two intermittent issues seen over the past year: >> >> a) Possible failure where an existing pid-file is not owned by the test user >> b) Race during startup where we try to attach to the target before it?s ready (removed arbitrary 5sec sleep) >> " >> >> This version is addressing David's comment about better processing the target process' stdout directly and not asynchronously. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Tue Mar 24 08:03:01 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 Mar 2015 09:03:01 +0100 Subject: RFR 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails In-Reply-To: <5510679A.3010609@oracle.com> References: <550FFC3E.4000209@oracle.com> <1A5AFAA8-9BC0-4F15-8CB1-80EF0E807C55@oracle.com> <5510679A.3010609@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 23 mar 2015, at 20:20, Jaroslav Bachorik wrote: > > On 23.3.2015 13:44, Staffan Larsen wrote: >> Looks good, but please print the exception at line 118 in AttachWithStalePidFile.java. > > Hm, like this http://cr.openjdk.java.net/~jbachorik/8024055/webrev.01 ? > > -JB- > >> >> Thanks, >> /Staffan >> >>> On 23 mar 2015, at 12:42, Jaroslav Bachorik wrote: >>> >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8024055 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024055/webrev.00 >>> >>> This request is a follow-up to the stalled review request http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-October/015785.html (the issue has changed its owner since then) >>> >>> As stated in the original request: >>> " >>> This patch fixes two intermittent issues seen over the past year: >>> >>> a) Possible failure where an existing pid-file is not owned by the test user >>> b) Race during startup where we try to attach to the target before it?s ready (removed arbitrary 5sec sleep) >>> " >>> >>> This version is addressing David's comment about better processing the target process' stdout directly and not asynchronously. >>> >>> Thanks, >>> >>> -JB- >> > From serguei.spitsyn at oracle.com Tue Mar 24 09:22:49 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Mar 2015 02:22:49 -0700 Subject: RFR 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails In-Reply-To: <5510679A.3010609@oracle.com> References: <550FFC3E.4000209@oracle.com> <1A5AFAA8-9BC0-4F15-8CB1-80EF0E807C55@oracle.com> <5510679A.3010609@oracle.com> Message-ID: <55112CE9.2050008@oracle.com> Jaroslav, test/serviceability/attach/AttachWithStalePidFile.java A question: 101 private static void waitForTargetReady(Process target) throws IOException { 102 BufferedReader br = new BufferedReader(new InputStreamReader(target.getInputStream())); 103 String line = br.readLine(); 104 while (line != null && !line.equals(AttachWithStalePidFileTarget.READY_MSG)) { 105 line = br.readLine(); 106 } 107 // target VM ready 108 } Not sure, in what condition the br.readLine() returns null. Will null be returned if the target thread did not write anything to the stdout yet? The while loop will complete if line == null. Do we really want this condition? : 104 while (line == null || !line.equals(AttachWithStalePidFileTarget.READY_MSG)) { Otherwise, it looks good. Thanks, Serguei On 3/23/15 12:20 PM, Jaroslav Bachorik wrote: > On 23.3.2015 13:44, Staffan Larsen wrote: >> Looks good, but please print the exception at line 118 in >> AttachWithStalePidFile.java. > > Hm, like this http://cr.openjdk.java.net/~jbachorik/8024055/webrev.01 ? > > -JB- > >> >> Thanks, >> /Staffan >> >>> On 23 mar 2015, at 12:42, Jaroslav Bachorik >>> wrote: >>> >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8024055 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024055/webrev.00 >>> >>> This request is a follow-up to the stalled review request >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-October/015785.html >>> (the issue has changed its owner since then) >>> >>> As stated in the original request: >>> " >>> This patch fixes two intermittent issues seen over the past year: >>> >>> a) Possible failure where an existing pid-file is not owned by the >>> test user >>> b) Race during startup where we try to attach to the target before >>> it?s ready (removed arbitrary 5sec sleep) >>> " >>> >>> This version is addressing David's comment about better processing >>> the target process' stdout directly and not asynchronously. >>> >>> Thanks, >>> >>> -JB- >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Mar 24 09:44:15 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 24 Mar 2015 10:44:15 +0100 Subject: RFR 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails In-Reply-To: <55112CE9.2050008@oracle.com> References: <550FFC3E.4000209@oracle.com> <1A5AFAA8-9BC0-4F15-8CB1-80EF0E807C55@oracle.com> <5510679A.3010609@oracle.com> <55112CE9.2050008@oracle.com> Message-ID: <551131EF.1050906@oracle.com> Hi Serguei, On 24.3.2015 10:22, serguei.spitsyn at oracle.com wrote: > Jaroslav, > > > test/serviceability/attach/AttachWithStalePidFile.java > > A question: > > 101 private static void waitForTargetReady(Process target) throws IOException { > 102 BufferedReader br = new BufferedReader(new InputStreamReader(target.getInputStream())); > 103 String line = br.readLine(); > 104 while (line != null && !line.equals(AttachWithStalePidFileTarget.READY_MSG)) { > 105 line = br.readLine(); > 106 } > 107 // target VM ready > 108 } > > Not sure, in what condition the br.readLine() returns null. > Will null be returned if the target thread did not write anything to the stdout yet? No, NULL will be returned only in case of EOF (eg. stream has been closed). Otherwise the readLine() will block until some data is available. > The while loop will complete if line == null. > > Do we really want this condition? : > 104 while (line == null || !line.equals(AttachWithStalePidFileTarget.READY_MSG)) { The crucial part is the comparison with the READY_MSG which indicates that the target VM has actually passed the initialization and is ready for the test. The 'line != null' is necessary to prevent NPE being thrown. While the test would fail anyway it is more informational to fail while trying to attach than an NPE. -JB- > > > Otherwise, it looks good. > > > Thanks, > Serguei > > > On 3/23/15 12:20 PM, Jaroslav Bachorik wrote: >> On 23.3.2015 13:44, Staffan Larsen wrote: >>> Looks good, but please print the exception at line 118 in >>> AttachWithStalePidFile.java. >> >> Hm, like this http://cr.openjdk.java.net/~jbachorik/8024055/webrev.01 ? >> >> -JB- >> >>> >>> Thanks, >>> /Staffan >>> >>>> On 23 mar 2015, at 12:42, Jaroslav Bachorik >>>> wrote: >>>> >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8024055 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024055/webrev.00 >>>> >>>> This request is a follow-up to the stalled review request >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-October/015785.html >>>> (the issue has changed its owner since then) >>>> >>>> As stated in the original request: >>>> " >>>> This patch fixes two intermittent issues seen over the past year: >>>> >>>> a) Possible failure where an existing pid-file is not owned by the >>>> test user >>>> b) Race during startup where we try to attach to the target before >>>> it?s ready (removed arbitrary 5sec sleep) >>>> " >>>> >>>> This version is addressing David's comment about better processing >>>> the target process' stdout directly and not asynchronously. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From serguei.spitsyn at oracle.com Tue Mar 24 09:55:09 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Mar 2015 02:55:09 -0700 Subject: RFR 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails In-Reply-To: <551131EF.1050906@oracle.com> References: <550FFC3E.4000209@oracle.com> <1A5AFAA8-9BC0-4F15-8CB1-80EF0E807C55@oracle.com> <5510679A.3010609@oracle.com> <55112CE9.2050008@oracle.com> <551131EF.1050906@oracle.com> Message-ID: <5511347D.7050700@oracle.com> Thank you for explanation, Jaroslav! Would it make sense to add short comment before the loop? No need to re-review. Thanks, Serguei On 3/24/15 2:44 AM, Jaroslav Bachorik wrote: > Hi Serguei, > > On 24.3.2015 10:22, serguei.spitsyn at oracle.com wrote: >> Jaroslav, >> >> >> test/serviceability/attach/AttachWithStalePidFile.java >> >> A question: >> >> 101 private static void waitForTargetReady(Process target) throws >> IOException { >> 102 BufferedReader br = new BufferedReader(new >> InputStreamReader(target.getInputStream())); >> 103 String line = br.readLine(); >> 104 while (line != null && >> !line.equals(AttachWithStalePidFileTarget.READY_MSG)) { >> 105 line = br.readLine(); >> 106 } >> 107 // target VM ready >> 108 } >> >> Not sure, in what condition the br.readLine() returns null. >> Will null be returned if the target thread did not write anything >> to the stdout yet? > > No, NULL will be returned only in case of EOF (eg. stream has been > closed). Otherwise the readLine() will block until some data is > available. > >> The while loop will complete if line == null. >> >> Do we really want this condition? : >> 104 while (line == null || >> !line.equals(AttachWithStalePidFileTarget.READY_MSG)) { > > The crucial part is the comparison with the READY_MSG which indicates > that the target VM has actually passed the initialization and is ready > for the test. The 'line != null' is necessary to prevent NPE being > thrown. While the test would fail anyway it is more informational to > fail while trying to attach than an NPE. > > -JB- > >> >> >> Otherwise, it looks good. >> >> >> Thanks, >> Serguei >> >> >> On 3/23/15 12:20 PM, Jaroslav Bachorik wrote: >>> On 23.3.2015 13:44, Staffan Larsen wrote: >>>> Looks good, but please print the exception at line 118 in >>>> AttachWithStalePidFile.java. >>> >>> Hm, like this http://cr.openjdk.java.net/~jbachorik/8024055/webrev.01 ? >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 23 mar 2015, at 12:42, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8024055 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024055/webrev.00 >>>>> >>>>> This request is a follow-up to the stalled review request >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-October/015785.html >>>>> >>>>> (the issue has changed its owner since then) >>>>> >>>>> As stated in the original request: >>>>> " >>>>> This patch fixes two intermittent issues seen over the past year: >>>>> >>>>> a) Possible failure where an existing pid-file is not owned by the >>>>> test user >>>>> b) Race during startup where we try to attach to the target before >>>>> it?s ready (removed arbitrary 5sec sleep) >>>>> " >>>>> >>>>> This version is addressing David's comment about better processing >>>>> the target process' stdout directly and not asynchronously. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From alexander.kulyakhtin at oracle.com Tue Mar 24 10:48:17 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 24 Mar 2015 03:48:17 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: <3698f540-73e0-4cfa-b356-6fb5ccea5b6f@default> Could the reviewers, please, have a look at the proposed changes below? In addition, we are going to make a change to the TEST.ROOT file as indicated by Staffan in the mail below. Do you think the changes (plus the one-line change to the TEST.ROOT) can be pushed into the jdk? Best regards, Alex ----- Original Message ----- From: staffan.larsen at oracle.com To: alexander.kulyakhtin at oracle.com Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests I haven?t looked at the changes in detail, but please change the requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. Thanks, /Staffan > On 20 mar 2015, at 13:16, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review the fix below. > > CR: https://bugs.openjdk.java.net/browse/JDK-8075586 > webrev: http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ > > The fix adds @modules keyword to the existing hotspot tests, as needed, so that the tests can access the required API when the new modular architecture is in place. > > Best regards, > Alex From yekaterina.kantserova at oracle.com Tue Mar 24 12:09:21 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 24 Mar 2015 13:09:21 +0100 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <3698f540-73e0-4cfa-b356-6fb5ccea5b6f@default> References: <3698f540-73e0-4cfa-b356-6fb5ccea5b6f@default> Message-ID: <551153F1.70409@oracle.com> Notifying hotspot-dev as well. // Katja On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: > Could the reviewers, please, have a look at the proposed changes below? > > In addition, we are going to make a change to the TEST.ROOT file as indicated by Staffan in the mail below. > > Do you think the changes (plus the one-line change to the TEST.ROOT) can be pushed into the jdk? > > Best regards, > Alex > > ----- Original Message ----- > From: staffan.larsen at oracle.com > To: alexander.kulyakhtin at oracle.com > Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com > Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests > > I haven?t looked at the changes in detail, but please change the requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. > > Thanks, > /Staffan > >> On 20 mar 2015, at 13:16, Alexander Kulyakhtin wrote: >> >> Hi, >> >> Could you, please, review the fix below. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >> webrev: http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >> >> The fix adds @modules keyword to the existing hotspot tests, as needed, so that the tests can access the required API when the new modular architecture is in place. >> >> Best regards, >> Alex From lois.foltan at oracle.com Tue Mar 24 12:57:48 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 24 Mar 2015 08:57:48 -0400 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <551153F1.70409@oracle.com> References: <3698f540-73e0-4cfa-b356-6fb5ccea5b6f@default> <551153F1.70409@oracle.com> Message-ID: <55115F4C.5040203@oracle.com> This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From alexander.kulyakhtin at oracle.com Tue Mar 24 14:04:52 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 24 Mar 2015 07:04:52 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: <0ac9a75a-d1a7-4a07-95e9-36bb338419b4@default> Lois, Thank you very much for your findings. We are going to remove the blank comments as you have suggested. If possible, however, we would prefer to pursue the copyrights issue under a different CR as this is another and not strictly related bulk change, which, probably, can be best achieved by an unrelated, script. I believe, there already is a separate CR for updating the copyrights. However if there's no such CR we are going to create a new one. Do you think it could be possible to have a separate CR for the copyrights issue (and if necessary to submit a new one)? Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From christian.tornqvist at oracle.com Tue Mar 24 15:07:21 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 24 Mar 2015 11:07:21 -0400 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <0ac9a75a-d1a7-4a07-95e9-36bb338419b4@default> References: <0ac9a75a-d1a7-4a07-95e9-36bb338419b4@default> Message-ID: <276701d06644$3b03abd0$b10b0370$@oracle.com> Hi Alex, I assume you've run all the tests and that they are still passing? The @module changes looks good. As Lois pointed out, you need to update the copyrights and this should be done as part of this change. Thanks, Christian -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Alexander Kulyakhtin Sent: Tuesday, March 24, 2015 10:05 AM To: lois.foltan at oracle.com Cc: hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; alexandre.iline at oracle.com Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Lois, Thank you very much for your findings. We are going to remove the blank comments as you have suggested. If possible, however, we would prefer to pursue the copyrights issue under a different CR as this is another and not strictly related bulk change, which, probably, can be best achieved by an unrelated, script. I believe, there already is a separate CR for updating the copyrights. However if there's no such CR we are going to create a new one. Do you think it could be possible to have a separate CR for the copyrights issue (and if necessary to submit a new one)? Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From alexander.kulyakhtin at oracle.com Tue Mar 24 15:26:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 24 Mar 2015 08:26:29 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: <7bb82b4c-1a08-4fe0-a340-dc01f39cbf22@default> Hi Christian, Yes, I have run the tests and they do pass the same as before. According to your and Lois' comments I'm going to fix the copyrights and resubmit the webrev as soon as I'm done. Best regards, Alex ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com, lois.foltan at oracle.com Cc: hotspot-dev at openjdk.java.net, serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 6:07:27 PM GMT +04:00 Abu Dhabi / Muscat Subject: RE: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Hi Alex, I assume you've run all the tests and that they are still passing? The @module changes looks good. As Lois pointed out, you need to update the copyrights and this should be done as part of this change. Thanks, Christian -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Alexander Kulyakhtin Sent: Tuesday, March 24, 2015 10:05 AM To: lois.foltan at oracle.com Cc: hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; alexandre.iline at oracle.com Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Lois, Thank you very much for your findings. We are going to remove the blank comments as you have suggested. If possible, however, we would prefer to pursue the copyrights issue under a different CR as this is another and not strictly related bulk change, which, probably, can be best achieved by an unrelated, script. I believe, there already is a separate CR for updating the copyrights. However if there's no such CR we are going to create a new one. Do you think it could be possible to have a separate CR for the copyrights issue (and if necessary to submit a new one)? Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From yekaterina.kantserova at oracle.com Wed Mar 25 10:05:54 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 25 Mar 2015 03:05:54 -0700 (PDT) Subject: RFR(XXS): 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined Message-ID: Hi, Could I please have a review of these 2 very small fixes. bug: https://bugs.openjdk.java.net/browse/JDK-8075818 webrev: http://cr.openjdk.java.net/~ykantser/8075818/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8075820 webrev: http://cr.openjdk.java.net/~ykantser/8075820/webrev.00/ Thanks, Katja From jaroslav.bachorik at oracle.com Wed Mar 25 10:19:21 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 25 Mar 2015 11:19:21 +0100 Subject: RFR(XXS): 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined In-Reply-To: References: Message-ID: <55128BA9.40802@oracle.com> Hi Katja, this looks good. Just update the copyright years before pushing. No need to re-review. -JB- On 25.3.2015 11:05, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of these 2 very small fixes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075818 > webrev: http://cr.openjdk.java.net/~ykantser/8075818/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8075820 > webrev: http://cr.openjdk.java.net/~ykantser/8075820/webrev.00/ > > Thanks, > Katja > From yekaterina.kantserova at oracle.com Wed Mar 25 10:22:40 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 25 Mar 2015 03:22:40 -0700 (PDT) Subject: RFR(XXS): 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined Message-ID: I will. Thanks for the review! // Katja ----- Original Message ----- From: jaroslav.bachorik at oracle.com To: serviceability-dev at openjdk.java.net Sent: Wednesday, March 25, 2015 11:19:31 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR(XXS): 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined Hi Katja, this looks good. Just update the copyright years before pushing. No need to re-review. -JB- On 25.3.2015 11:05, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of these 2 very small fixes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075818 > webrev: http://cr.openjdk.java.net/~ykantser/8075818/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8075820 > webrev: http://cr.openjdk.java.net/~ykantser/8075820/webrev.00/ > > Thanks, > Katja > From serguei.spitsyn at oracle.com Wed Mar 25 11:35:29 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 25 Mar 2015 04:35:29 -0700 Subject: RFR(XXS): 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined In-Reply-To: References: Message-ID: <55129D81.9080701@oracle.com> Hi Katya, It looks good. Thanks, Serguei On 3/25/15 3:05 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of these 2 very small fixes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075818 > webrev: http://cr.openjdk.java.net/~ykantser/8075818/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8075820 > webrev: http://cr.openjdk.java.net/~ykantser/8075820/webrev.00/ > > Thanks, > Katja From yekaterina.kantserova at oracle.com Wed Mar 25 11:37:47 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 25 Mar 2015 04:37:47 -0700 (PDT) Subject: RFR(XXS): 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined Message-ID: Serguei, thanks for the review! // Katja ----- Original Message ----- From: serguei.spitsyn at oracle.com To: yekaterina.kantserova at oracle.com, serviceability-dev at openjdk.java.net Sent: Wednesday, March 25, 2015 12:35:30 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR(XXS): 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined Hi Katya, It looks good. Thanks, Serguei On 3/25/15 3:05 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of these 2 very small fixes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075818 > webrev: http://cr.openjdk.java.net/~ykantser/8075818/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8075820 > webrev: http://cr.openjdk.java.net/~ykantser/8075820/webrev.00/ > > Thanks, > Katja From alexander.kulyakhtin at oracle.com Wed Mar 25 14:38:15 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 25 Mar 2015 07:38:15 -0700 (PDT) Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests Message-ID: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> Hi Please, find the updated review for the bulk @modules change at the link below. We have fixed the copyrights and the files mentioned in the mail from Lois. http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html Best regards, Alex ----- Original Message ----- From: lois.foltan at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests This looks good, thank you for making these changes! A couple of comments that I don't feel need another webrev but should be fixed before pushing. - copyrights on all the tests need to be updated - the following tests have a blank comment line before the new "@modules" line that could be removed test/gc/metaspace/TestMetaspacePerfCounters.java test/runtime/contended/Basic.java test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java test/compiler/cpuflags/RestoreMXCSR.java test/compiler/debug/VerifyAdapterSharing.java Thanks, Lois On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: > Notifying hotspot-dev as well. > > // Katja > > > > On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >> Could the reviewers, please, have a look at the proposed changes below? >> >> In addition, we are going to make a change to the TEST.ROOT file as >> indicated by Staffan in the mail below. >> >> Do you think the changes (plus the one-line change to the TEST.ROOT) >> can be pushed into the jdk? >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> I haven?t looked at the changes in detail, but please change the >> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >> >> Thanks, >> /Staffan >> >>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>> wrote: >>> >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>> webrev: >>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>> >>> The fix adds @modules keyword to the existing hotspot tests, as >>> needed, so that the tests can access the required API when the new >>> modular architecture is in place. >>> >>> Best regards, >>> Alex > From jaroslav.bachorik at oracle.com Wed Mar 25 16:53:18 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 25 Mar 2015 17:53:18 +0100 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: <5510033F.8030205@oracle.com> References: <54F5E108.3010902@oracle.com> <54F6C6B0.2040908@oracle.com> <54F75127.4060205@oracle.com> <5510033F.8030205@oracle.com> Message-ID: <5512E7FE.9090707@oracle.com> On 23.3.2015 13:12, Jaroslav Bachorik wrote: > On 18.3.2015 23:28, Eamonn McManus wrote: >>> Mainly because the long term goal (beyond the scope of this JEP, >>> anyway) would be to get users to slowly migrate to the annotation >>> based M(X)Beans. Not giving them the chance to specify the service >>> interface via annotations will mean keeping this dichotomy forever. >> >> I'm not sure that is a good goal. M(X)Bean interfaces allow clients to >> make proxies, and there's no obvious equivalent with annotations. > > You still can create proxies for MXBeans defined through annotations - > the 'service' attribute of '@ManagedBean' annotation serves exactly this > purpose. The value of this attribute will be used in the associated > Descriptor under the 'interfaceClassName' key. > > In fact, the resulting instance registered in the MBeanServer for an > annotation based MXBean is undistinguishable from the one based on > MXBean interface. > >> Though I suppose you could provide a standard annotation processor >> that would generate the implied interface from the annotations. > > Yes, this might be an option. But probably beyond the scope of this JEP. > I need to keep the change as simple as possible - otherwise it might not > make it for JDK 9. > >> >> Re @Notification: Please don't add types to the JMX API with the same >> name as types that are already there. That will make the API very >> unpleasant to use. > > Agreed. A nice, simple name for this annotation will have to be found. > >> >> I don't understand what this text means: "It can also be used as a >> parameter annotation for a field of type NotificationSender." Is it > > Should read '... for an argument of type NotificationSender' > >> applied to parameters or fields? The code example shows the former, >> but that seems a bit limiting. What if the MBean wants to send a >> notification at some point unrelated to method invocation? > > For the sakes of simplicity I opted for something that seemed to be the > common case - sending notification from within the managed operations or > attribute getters/setters. Could you come up with a use case when it is > inevitable to send notification from a code not reachable either through > a managed operation or attribute getter/setter? If it is something > generally needed I might make the @Notification applicable to fields as > well. I was able to cleanup the notifications part a bit - moving the declaration from the top level annotation and the per-parameter annotations to just one place - an annotated field of type NotificationSender. This will also solve the problem with emitting notifications from the methods associated with neither the managed operations nor attributes. Basically a custom dependency injection - but very simple one without all the bells-and-whistles. Unfortunately, the @Resource annotation has been moved to jaxws in JDK 9 :( I also simplified the @RegistrationHandler - the solution you proposed, extending the MBeanRegistration interface, is not something I would really like to do now - mostly because a logical part of this interface is hidden in DynamicMBean2 (preRegister2 method) and consolidating this will take a major effort on its own. Hopefully I was able to come up with concise and simple naming for the annotations - conveying their purpose and not being too chatty. Eamonn, thank you once again for taking your time to review this draft. I am planning to submit this JEP in the next two days. Submitting the JEP does not mean freezing the specification - just acknowledging that the JEP is worth of pursuing. There will be at least one more additional JEP review in the process and then the final code review before push. -JB- > > Thanks, > > -JB- > >> >> ?amonn >> >> >> 2015-03-04 10:38 GMT-08:00 Jaroslav Bachorik >> : >>> Thanks for taking the time to review this. >>> I apologize for the formatting mess - clearly the JIRA's markdown >>> processor >>> is rather confused with more extensive usage of the code blocks. >>> >>> On 4.3.2015 18:42, Eamonn McManus wrote: >>>> >>>> Thank you for updating the JEP text referencing JSR 255. >>>> >>>> Perhaps unsurprisingly I disagree with many of the differences between >>>> this proposal and the one we carefully thought out in JSR 255. Even >>>> though a lot has changed in the meanwhile, I don't see anything that >>>> invalidates our assumptions of the time. >>>> >>>> For reference, a snapshot of the JSR 255 javadoc is at >>>> http://hg.openjdk.java.net/jmx2/jmx2/file/f417598a7b72/javadoc. >>>> Unfortunately, it appears that the Mercurial server now serves these >>>> files as application/binary, probably because of the change here: >>>> >>>> http://mercurial.selenic.com/wiki/UpgradeNotes#A1.9.1:_guessmime.2C_revert_behavior_restored. >>>> >>>> >>>> To address some specific points: >>>>> >>>>> would you care to elaborate what you find to be not "even correct >>>>> Java"? >>>> >>>> >>>> As of Java 8, annotation elements cannot have null values so the >>>> "default null" clauses are nonsense. I have not seen any proposal to >>>> change this in Java 9. The @ManagedBean definition also has an obvious >>>> syntax error. >>> >>> >>> Agreed. They should not be there. During the updates JIRA failed to >>> update >>> the field and I failed to notice that my edits didn't apply. >>> >>>> >>>>> - ability to annotate fields turning them into attributes >>>> >>>> >>>> This might be useful for read-only attributes. I'd question whether it >>>> is useful for read/write attributes, because I think it will be very >>>> unusual for you to want neither validation of the new value nor >>>> behaviour to be triggered by the set. >>> >>> >>> On the other hand it gives the possibility to expose those read-only >>> fields >>> (eg. metrics or settings being immutable via JMX) without the >>> necessity to >>> conjure the getter. >>> >>>> >>>>> - ability to provide metadata directly in the annotations, not relying >>>>> solely on inferring them from the annotated element >>>> >>>> >>>> I'm not sure what specifically this refers to. Do you mean for example >>>> that it is possible to add @ManagedAttribute to a method that does not >>>> look like getFoo() and nevertheless have the annotation say that the >>>> attribute is called foo? I don't see any particular advantage to that >>>> flexibility. The getFoo() pattern is already familiar, and having a >>>> second, completely different way of specifying the name just >>>> complicates the spec for not much benefit. >>> >>> >>> And yet it can be done in DynamicMBeans. My starting point was the >>> attempt >>> to give the user the same flexibility she would have if she were >>> hand-crafting the various MBean*Info classes. >>> >>>> >>>>> - missing @ManagedConstructor to expose a constructor >>>> >>>> >>>> We deliberately omitted this. The fact that MBeanConstructorInfo >>>> exists at all is in my opinion a mistake in the original JMX >>>> specification. What does it mean for an MBean to tell you how to >>>> construct another instance of itself? And if the purpose is to specify >>>> which constructors from this class are available to the MBean Server, >>>> there's no use for names and descriptions, and there's no particular >>>> advantage over just saying that all public constructors are available. >>> >>> >>> I don't know the meaning. I was not involved in the inception of this >>> API. >>> My reasoning is that if you can do it by hand than it should probably be >>> achievable by annotation as well. The other route would be >>> deprecating the >>> MBeanConstructorInfo now and removing it in a subsequent release. >>> >>>> >>>>> - optional 'service' argument to @ManagedBean annotation which will be >>>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>>> guidance about the recommended service interface when using >>>>> JMX.newMXBeanProxy() >>>> >>>> >>>> If you have such an interface, why wouldn't you just use it to define >>>> the MBean and dispense with annotations? >>> >>> >>> Mainly because the long term goal (beyond the scope of this JEP, anyway) >>> would be to get users to slowly migrate to the annotation based >>> M(X)Beans. >>> Not giving them the chance to specify the service interface via >>> annotations >>> will mean keeping this dichotomy forever. >>> >>>> >>>> Some other comments: >>>> >>>> * @ManagedBean. >>>> >>>> We called this @MBean because we also had an @MXBean annotation. That >>>> annotation exists today, but JSR 255 allowed it to be applied to a >>>> class as well as to an interface. It appears that @ManagedBean only >>>> defines MXBeans, which is a legitimate choice but, first, it should be >>>> called out more explicitly, and, second, wouldn't it then make sense >>>> to extend the existing @MXBean annotation? >>> >>> >>> I thought about this and extending an existing annotation is pretty >>> sensitive from the compatibility PoV. Also, giving the annotation >>> different >>> meanings depending whether it is used on interface or class is rather >>> wobbly. I am still open to suggestions for better naming, though. >>> >>>> >>>> The specification is inconsistent as to whether the annotation is >>>> @ManagedBean or @MBean. >>>> >>>> I think it is a fair idea to have an objectName field, but the idea of >>>> randomly appending numbers to the name for disambiguation is broken. >>> >>> >>> Ok. Valid point. >>> >>>> Something like @ObjectNameTemplate from JSR 255 is more appropriate. >>> >>> >>> Yes, but it brings even more complexity. >>> >>>> >>>> The text for the notifications() member references @TypeMapping but >>>> does not say what that is. The declared type is Notification[] and the >>>> text defines an annotation @Notification, but there is already a class >>>> called Notification in javax.management. >>> >>> >>> The annotations should be placed in a sub-package of >>> "javax.management". The >>> "javax.management" is pretty crowded already. >>> >>>> >>>> I think that the simple "name=value" syntax used by JSR 255's >>>> @DescriptorFields is preferable to the unspecified and verbose type >>>> @Tag. I don't see an advantage to making people write @Tag(name = >>>> "foo", value = "bar") rather than just "foo=bar". This syntax is >>>> already present in the JMX spec, for example in the >>>> ImmutableDescriptor constructor. >>> >>> >>> IMO, having just plain text there will open door for spurious errors >>> due to >>> typos in delimiters. But that's just my experience. >>> >>>> >>>> * @Notification. >>>> >>>> As I mentioned, you can't use that name. >>>> >>>> The first paragraph of the description is indecipherable. >>>> >>>> The NotificationSender interface is unspecified. Based on the example, >>>> I think it could potentially be a major usability improvement but it's >>>> hard to be sure. >>> >>> >>> I can add this interface to the proposal. The reason for it not being >>> explicitly specified is that it is still very prototypical. >>> >>>> >>>> I think it's extremely ugly to propagate the misspelling clazz into an >>>> API where people will have to write it. Also, if it must extend >>>> Notification then it should be specified as Class>>> Notification>. >>> >>> >>> The problem is that using the rather obvious "type" creates confusion >>> with >>> the "types". I can't use "class", of course. I am not too happy about >>> this >>> name either but anything else will just be more verbose. >>> >>>> >>>> * @ManagedAttribute >>>> >>>> It's extremely strange for this to have getter and setter fields. Why >>>> wouldn't it just be applied to those methods? >>> >>> >>> Less boilerplate. One wouldn't need to retype the whole >>> @ManagedAttribute >>> definition twice. >>> >>>> >>>> Promoting units from a descriptor field to a separate annotation >>>> member seems like a good idea. The specified value would be copied >>>> into the Descriptor. >>> >>> >>> Exactly. >>> >>>> >>>> * @ManagedOperation >>>> >>>> I don't see any reason to allow the name to be different from the >>>> method name. It just complicates the spec. >>> >>> >>> Well, you can do it manually. But I am open here - it would be nice >>> to hear >>> from potential users whether this would make sense. >>> >>>> >>>> Instead of repeating a description member inside every annotation, JSR >>>> 255 defined a top-level @Description, which included elements for >>>> internationalization. Hardcoded strings are a step backwards. >>> >>> >>> Until we have support for providing the client locale to the JMX >>> server any >>> internationalization is rather illusionary. >>> >>>> >>>> Defining Impact inside this annotation is questionable. I'd expect >>>> user code and possible future API changes to want to reference it >>>> independently of the annotation. Also, the JSR 255 enum Impact had >>>> methods to convert to and from the integer codes used by >>>> MBeanOperationInfo. >>> >>> >>> Please, consider class packaging being transitional. The classes may >>> change >>> their locations during the draft review. >>> >>>> >>>> * @ManagedParameter >>>> >>>> The text repeatedly says operation name and method name when it means >>>> parameter name. I assume that if the name member is empty then the >>>> parameter name from reflection is used, which since Java 8 could be >>>> the actual name of the parameter if the class was compiled with >>>> -parameters. >>> >>> >>> Precisely. >>> >>>> >>>> * @RegistrationHandler >>>> >>>> It seems like an API smell for an annotation to say that it must be >>>> applied to methods with a certain signature. I think a much better >>>> approach would be to change the existing MBeanRegistration interface >>>> so that its methods have default implementations that do nothing. That >>>> removes the main reason that this interface is a pain: having to >>>> implement four methods when you're usually only interested in one. You >>>> could also add a preDeregister overload with MBeanServer and >>>> ObjectName parameters, again with a default implementation. >>> >>> >>> Well, @ManagedAttribute must be applied to methods of certain signatures >>> only, too. >>> >>> I wanted to avoid the necessity for the annotated M(X)Bean to >>> implement any >>> other JMX specific interfaces explicitly. Therefore I proposed this >>> annotation. >>> >>> -JB- >>> >>> >>> >>>> >>>> ?amonn >>>> >>>> >>>> 2015-03-04 0:47 GMT-08:00 Jaroslav Bachorik >>>> : >>>>> >>>>> On 4.3.2015 02:09, Eamonn McManus wrote: >>>>>> >>>>>> >>>>>> Could you explain what you mean by this, regarding the annotations >>>>>> that were already agreed on by the JSR 255 Expert Group: >>>>>> >>>>>> * Smaller scope compared to the proposed solution >>>>> >>>>> >>>>> >>>>> This is a leftover from the previous proposal which had wider scope >>>>> than >>>>> what is presented now. Still a few points remain. >>>>> >>>>> - ability to annotate fields turning them into attributes >>>>> - ability to provide metadata directly in the annotations, not relying >>>>> solely on inferring them from the annotated element >>>>> - missing @ManagedConstructor to expose a constructor >>>>> - optional 'service' argument to @ManagedBean annotation which will be >>>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>>> guidance about the recommended service interface when using >>>>> JMX.newMXBeanProxy() >>>>> >>>>>> * Conceptually in pre JDK7 era >>>>> >>>>> >>>>> >>>>> I am afraid this relates more to the implementation - or at least the >>>>> code I >>>>> was able to reconstruct from the repo history. Shouldn't be mentioned >>>>> here. >>>>> >>>>>> >>>>>> I have a number of other comments, but procedurally I'm not sure what >>>>>> the precedent is for summarily discarding work previously done in the >>>>>> JCP on the same subject. I'd certainly have expected this JEP to >>>>>> start >>>>>> from that work, rather than proposing a starting point that isn't >>>>>> even >>>>>> correct Java. >>>>> >>>>> >>>>> >>>>> Well, this is a draft review. The JSR 255 annotations work is not >>>>> discarded. >>>>> It is mentioned in the alternatives. The purpose of the open review >>>>> is to >>>>> find out whether it is ok to continue with proposed feature, modify >>>>> it to >>>>> use eg. JSR 255 work or abandon it completely. >>>>> >>>>> -JB- >>>>> >>>>> >>>>>> >>>>>> ?amonn McManus, former JSR 255 Spec Lead >>>>>> >>>>>> 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik >>>>>> : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this draft JEP for JMX Specific Annotations for >>>>>>> Registration of Managed Resources: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8044507 >>>>>>> >>>>>>> Background: >>>>>>> Current mechanism of defining an MBean requires to provide an MBean >>>>>>> interface and its implementation. The interface and the >>>>>>> implementation >>>>>>> must >>>>>>> conform to the strict naming and visibility rules in order for the >>>>>>> introspection to be able to bind them. >>>>>>> >>>>>>> At least the same level of verbosity is required when adding an >>>>>>> MBeanInfo >>>>>>> to generate MBean metadata. >>>>>>> >>>>>>> All this leads to a rather verbose code containing a lot of >>>>>>> repeating >>>>>>> boilerplate parts even for the most simple MBean registrations. >>>>>>> >>>>>>> This JEP proposes to add a set of annotations for registration and >>>>>>> configuration of manageable resources (in other word 'MBeans'). >>>>>>> These >>>>>>> annotations will be used to generate all the metadata necessary >>>>>>> for a >>>>>>> resources to be accepted by the current JMX system. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>> >>>>> >>>>> >>> > From lois.foltan at oracle.com Wed Mar 25 17:00:35 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 25 Mar 2015 13:00:35 -0400 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> Message-ID: <5512E9B3.6000509@oracle.com> On 3/25/2015 10:38 AM, Alexander Kulyakhtin wrote: > Hi > > Please, find the updated review for the bulk @modules change at the link below. > > We have fixed the copyrights and the files mentioned in the mail from Lois. > > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html Thank you very much for adding the copyrights in this edit. I have reviewed and it all looks good. Just a minor comment: test/gc/arguments/TestUseCompressedOopsErgo.java test/serviceability/jvmti/GetObjectSizeOverflow.java Both of these tests need a comma between "2015 Oracle". I don't need to see another webrev for this. Thanks, Lois > > Best regards, > Alex > > > > ----- Original Message ----- > From: lois.foltan at oracle.com > To: yekaterina.kantserova at oracle.com > Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com > Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests > > > This looks good, thank you for making these changes! A couple of > comments that I don't feel need another webrev but should be fixed > before pushing. > > - copyrights on all the tests need to be updated > - the following tests have a blank comment line before the new > "@modules" line that could be removed > test/gc/metaspace/TestMetaspacePerfCounters.java > test/runtime/contended/Basic.java > test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java > test/compiler/cpuflags/RestoreMXCSR.java > test/compiler/debug/VerifyAdapterSharing.java > > Thanks, > Lois > > On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >> Notifying hotspot-dev as well. >> >> // Katja >> >> >> >> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>> Could the reviewers, please, have a look at the proposed changes below? >>> >>> In addition, we are going to make a change to the TEST.ROOT file as >>> indicated by Staffan in the mail below. >>> >>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>> can be pushed into the jdk? >>> >>> Best regards, >>> Alex >>> >>> ----- Original Message ----- >>> From: staffan.larsen at oracle.com >>> To: alexander.kulyakhtin at oracle.com >>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>> hotspot tests >>> >>> I haven?t looked at the changes in detail, but please change the >>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>> >>> Thanks, >>> /Staffan >>> >>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>> wrote: >>>> >>>> Hi, >>>> >>>> Could you, please, review the fix below. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>> webrev: >>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>> >>>> The fix adds @modules keyword to the existing hotspot tests, as >>>> needed, so that the tests can access the required API when the new >>>> modular architecture is in place. >>>> >>>> Best regards, >>>> Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Mar 25 23:11:14 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Mar 2015 16:11:14 -0700 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> Message-ID: <55134092.801@oracle.com> Alexandar, Shura, The dependency analysis is not up-to-date that sun.tools.jar has been moved to jdk.jartool module in jdk9 b55. It has been in jdk9/dev since 3/6. I have pointed out multiple times previously that jdk.dev/sun.tools.jar is wrong in the jdk side of change. Below includes an example. Mandy --- old/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 16:24:41.462038538 +0300 +++ new/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 16:24:41.386038539 +0300 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -25,6 +25,9 @@ * @test * @library /testlibrary * @summary Test that type annotations are retained after a retransform + * @modules java.base/jdk.internal.org.objectweb.asm + * java.instrument + * jdk.dev/sun.tools.jar * @run main RedefineAnnotations buildagent * @run main/othervm -javaagent:redefineagent.jar RedefineAnnotations */ On 3/25/15 7:38 AM, Alexander Kulyakhtin wrote: > Hi > > Please, find the updated review for the bulk @modules change at the link below. > > We have fixed the copyrights and the files mentioned in the mail from Lois. > > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html > > Best regards, > Alex > > > > ----- Original Message ----- > From: lois.foltan at oracle.com > To: yekaterina.kantserova at oracle.com > Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com > Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests > > > This looks good, thank you for making these changes! A couple of > comments that I don't feel need another webrev but should be fixed > before pushing. > > - copyrights on all the tests need to be updated > - the following tests have a blank comment line before the new > "@modules" line that could be removed > test/gc/metaspace/TestMetaspacePerfCounters.java > test/runtime/contended/Basic.java > test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java > test/compiler/cpuflags/RestoreMXCSR.java > test/compiler/debug/VerifyAdapterSharing.java > > Thanks, > Lois > > On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >> Notifying hotspot-dev as well. >> >> // Katja >> >> >> >> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>> Could the reviewers, please, have a look at the proposed changes below? >>> >>> In addition, we are going to make a change to the TEST.ROOT file as >>> indicated by Staffan in the mail below. >>> >>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>> can be pushed into the jdk? >>> >>> Best regards, >>> Alex >>> >>> ----- Original Message ----- >>> From: staffan.larsen at oracle.com >>> To: alexander.kulyakhtin at oracle.com >>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>> hotspot tests >>> >>> I haven?t looked at the changes in detail, but please change the >>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>> >>> Thanks, >>> /Staffan >>> >>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>> wrote: >>>> >>>> Hi, >>>> >>>> Could you, please, review the fix below. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>> webrev: >>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>> >>>> The fix adds @modules keyword to the existing hotspot tests, as >>>> needed, so that the tests can access the required API when the new >>>> modular architecture is in place. >>>> >>>> Best regards, >>>> Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Mar 26 01:16:21 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 25 Mar 2015 18:16:21 -0700 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match Message-ID: <55135DE5.2010705@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8066679 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ Summary: There can be multiple concurrent RetransformClasses calls on different threads. So that, the assert "cache ptrs must match" is incorrect as it was based on wrong assumptions. The fix removes two related asserts and also frees the scratch_class cached_class_file_bytes if it is necessary to avoid leaking the memory. Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument Thanks, Serguei From eamonn at mcmanus.net Thu Mar 26 02:47:34 2015 From: eamonn at mcmanus.net (Eamonn McManus) Date: Wed, 25 Mar 2015 19:47:34 -0700 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: <5512E7FE.9090707@oracle.com> References: <54F5E108.3010902@oracle.com> <54F6C6B0.2040908@oracle.com> <54F75127.4060205@oracle.com> <5510033F.8030205@oracle.com> <5512E7FE.9090707@oracle.com> Message-ID: A couple more comments on the draft as it stands. I like the approach of @NotificationSupport on fields. However, the name is not great I think. Maybe nest an @Inject annotation inside NotificationSender, so you could write @NotificationSender.Inject private NotificationSender sender; ? I think you are right about MBeanRegistration not being a great alternative to annotating an explicit lifecycle method, even if MBeanRegistration acquires default implementations of its methods. Having classes implement callback interfaces is generally not very clean, unless that is all they do. @RegistrationHandler on a method with a RegisterEvent parameter is a good alternative. The RegisterEvent parameter would be required, I think; otherwise the MBean object would have to keep track of whether it is already registered in order to know that a second call means it has been unregistered. ?amonn 2015-03-25 9:53 GMT-07:00 Jaroslav Bachorik : > On 23.3.2015 13:12, Jaroslav Bachorik wrote: >> >> On 18.3.2015 23:28, Eamonn McManus wrote: >>>> >>>> Mainly because the long term goal (beyond the scope of this JEP, >>>> anyway) would be to get users to slowly migrate to the annotation >>>> based M(X)Beans. Not giving them the chance to specify the service >>>> interface via annotations will mean keeping this dichotomy forever. >>> >>> >>> I'm not sure that is a good goal. M(X)Bean interfaces allow clients to >>> make proxies, and there's no obvious equivalent with annotations. >> >> >> You still can create proxies for MXBeans defined through annotations - >> the 'service' attribute of '@ManagedBean' annotation serves exactly this >> purpose. The value of this attribute will be used in the associated >> Descriptor under the 'interfaceClassName' key. >> >> In fact, the resulting instance registered in the MBeanServer for an >> annotation based MXBean is undistinguishable from the one based on >> MXBean interface. >> >>> Though I suppose you could provide a standard annotation processor >>> that would generate the implied interface from the annotations. >> >> >> Yes, this might be an option. But probably beyond the scope of this JEP. >> I need to keep the change as simple as possible - otherwise it might not >> make it for JDK 9. >> >>> >>> Re @Notification: Please don't add types to the JMX API with the same >>> name as types that are already there. That will make the API very >>> unpleasant to use. >> >> >> Agreed. A nice, simple name for this annotation will have to be found. >> >>> >>> I don't understand what this text means: "It can also be used as a >>> parameter annotation for a field of type NotificationSender." Is it >> >> >> Should read '... for an argument of type NotificationSender' >> >>> applied to parameters or fields? The code example shows the former, >>> but that seems a bit limiting. What if the MBean wants to send a >>> notification at some point unrelated to method invocation? >> >> >> For the sakes of simplicity I opted for something that seemed to be the >> common case - sending notification from within the managed operations or >> attribute getters/setters. Could you come up with a use case when it is >> inevitable to send notification from a code not reachable either through >> a managed operation or attribute getter/setter? If it is something >> generally needed I might make the @Notification applicable to fields as >> well. > > > I was able to cleanup the notifications part a bit - moving the declaration > from the top level annotation and the per-parameter annotations to just one > place - an annotated field of type NotificationSender. This will also solve > the problem with emitting notifications from the methods associated with > neither the managed operations nor attributes. Basically a custom dependency > injection - but very simple one without all the bells-and-whistles. > Unfortunately, the @Resource annotation has been moved to jaxws in JDK 9 :( > > I also simplified the @RegistrationHandler - the solution you proposed, > extending the MBeanRegistration interface, is not something I would really > like to do now - mostly because a logical part of this interface is hidden > in DynamicMBean2 (preRegister2 method) and consolidating this will take a > major effort on its own. > > Hopefully I was able to come up with concise and simple naming for the > annotations - conveying their purpose and not being too chatty. > > Eamonn, thank you once again for taking your time to review this draft. I am > planning to submit this JEP in the next two days. Submitting the JEP does > not mean freezing the specification - just acknowledging that the JEP is > worth of pursuing. There will be at least one more additional JEP review in > the process and then the final code review before push. > > > -JB- > > >> >> Thanks, >> >> -JB- >> >>> >>> ?amonn >>> >>> >>> 2015-03-04 10:38 GMT-08:00 Jaroslav Bachorik >>> : >>>> >>>> Thanks for taking the time to review this. >>>> I apologize for the formatting mess - clearly the JIRA's markdown >>>> processor >>>> is rather confused with more extensive usage of the code blocks. >>>> >>>> On 4.3.2015 18:42, Eamonn McManus wrote: >>>>> >>>>> >>>>> Thank you for updating the JEP text referencing JSR 255. >>>>> >>>>> Perhaps unsurprisingly I disagree with many of the differences between >>>>> this proposal and the one we carefully thought out in JSR 255. Even >>>>> though a lot has changed in the meanwhile, I don't see anything that >>>>> invalidates our assumptions of the time. >>>>> >>>>> For reference, a snapshot of the JSR 255 javadoc is at >>>>> http://hg.openjdk.java.net/jmx2/jmx2/file/f417598a7b72/javadoc. >>>>> Unfortunately, it appears that the Mercurial server now serves these >>>>> files as application/binary, probably because of the change here: >>>>> >>>>> >>>>> http://mercurial.selenic.com/wiki/UpgradeNotes#A1.9.1:_guessmime.2C_revert_behavior_restored. >>>>> >>>>> >>>>> To address some specific points: >>>>>> >>>>>> >>>>>> would you care to elaborate what you find to be not "even correct >>>>>> Java"? >>>>> >>>>> >>>>> >>>>> As of Java 8, annotation elements cannot have null values so the >>>>> "default null" clauses are nonsense. I have not seen any proposal to >>>>> change this in Java 9. The @ManagedBean definition also has an obvious >>>>> syntax error. >>>> >>>> >>>> >>>> Agreed. They should not be there. During the updates JIRA failed to >>>> update >>>> the field and I failed to notice that my edits didn't apply. >>>> >>>>> >>>>>> - ability to annotate fields turning them into attributes >>>>> >>>>> >>>>> >>>>> This might be useful for read-only attributes. I'd question whether it >>>>> is useful for read/write attributes, because I think it will be very >>>>> unusual for you to want neither validation of the new value nor >>>>> behaviour to be triggered by the set. >>>> >>>> >>>> >>>> On the other hand it gives the possibility to expose those read-only >>>> fields >>>> (eg. metrics or settings being immutable via JMX) without the >>>> necessity to >>>> conjure the getter. >>>> >>>>> >>>>>> - ability to provide metadata directly in the annotations, not relying >>>>>> solely on inferring them from the annotated element >>>>> >>>>> >>>>> >>>>> I'm not sure what specifically this refers to. Do you mean for example >>>>> that it is possible to add @ManagedAttribute to a method that does not >>>>> look like getFoo() and nevertheless have the annotation say that the >>>>> attribute is called foo? I don't see any particular advantage to that >>>>> flexibility. The getFoo() pattern is already familiar, and having a >>>>> second, completely different way of specifying the name just >>>>> complicates the spec for not much benefit. >>>> >>>> >>>> >>>> And yet it can be done in DynamicMBeans. My starting point was the >>>> attempt >>>> to give the user the same flexibility she would have if she were >>>> hand-crafting the various MBean*Info classes. >>>> >>>>> >>>>>> - missing @ManagedConstructor to expose a constructor >>>>> >>>>> >>>>> >>>>> We deliberately omitted this. The fact that MBeanConstructorInfo >>>>> exists at all is in my opinion a mistake in the original JMX >>>>> specification. What does it mean for an MBean to tell you how to >>>>> construct another instance of itself? And if the purpose is to specify >>>>> which constructors from this class are available to the MBean Server, >>>>> there's no use for names and descriptions, and there's no particular >>>>> advantage over just saying that all public constructors are available. >>>> >>>> >>>> >>>> I don't know the meaning. I was not involved in the inception of this >>>> API. >>>> My reasoning is that if you can do it by hand than it should probably be >>>> achievable by annotation as well. The other route would be >>>> deprecating the >>>> MBeanConstructorInfo now and removing it in a subsequent release. >>>> >>>>> >>>>>> - optional 'service' argument to @ManagedBean annotation which will be >>>>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>>>> guidance about the recommended service interface when using >>>>>> JMX.newMXBeanProxy() >>>>> >>>>> >>>>> >>>>> If you have such an interface, why wouldn't you just use it to define >>>>> the MBean and dispense with annotations? >>>> >>>> >>>> >>>> Mainly because the long term goal (beyond the scope of this JEP, anyway) >>>> would be to get users to slowly migrate to the annotation based >>>> M(X)Beans. >>>> Not giving them the chance to specify the service interface via >>>> annotations >>>> will mean keeping this dichotomy forever. >>>> >>>>> >>>>> Some other comments: >>>>> >>>>> * @ManagedBean. >>>>> >>>>> We called this @MBean because we also had an @MXBean annotation. That >>>>> annotation exists today, but JSR 255 allowed it to be applied to a >>>>> class as well as to an interface. It appears that @ManagedBean only >>>>> defines MXBeans, which is a legitimate choice but, first, it should be >>>>> called out more explicitly, and, second, wouldn't it then make sense >>>>> to extend the existing @MXBean annotation? >>>> >>>> >>>> >>>> I thought about this and extending an existing annotation is pretty >>>> sensitive from the compatibility PoV. Also, giving the annotation >>>> different >>>> meanings depending whether it is used on interface or class is rather >>>> wobbly. I am still open to suggestions for better naming, though. >>>> >>>>> >>>>> The specification is inconsistent as to whether the annotation is >>>>> @ManagedBean or @MBean. >>>>> >>>>> I think it is a fair idea to have an objectName field, but the idea of >>>>> randomly appending numbers to the name for disambiguation is broken. >>>> >>>> >>>> >>>> Ok. Valid point. >>>> >>>>> Something like @ObjectNameTemplate from JSR 255 is more appropriate. >>>> >>>> >>>> >>>> Yes, but it brings even more complexity. >>>> >>>>> >>>>> The text for the notifications() member references @TypeMapping but >>>>> does not say what that is. The declared type is Notification[] and the >>>>> text defines an annotation @Notification, but there is already a class >>>>> called Notification in javax.management. >>>> >>>> >>>> >>>> The annotations should be placed in a sub-package of >>>> "javax.management". The >>>> "javax.management" is pretty crowded already. >>>> >>>>> >>>>> I think that the simple "name=value" syntax used by JSR 255's >>>>> @DescriptorFields is preferable to the unspecified and verbose type >>>>> @Tag. I don't see an advantage to making people write @Tag(name = >>>>> "foo", value = "bar") rather than just "foo=bar". This syntax is >>>>> already present in the JMX spec, for example in the >>>>> ImmutableDescriptor constructor. >>>> >>>> >>>> >>>> IMO, having just plain text there will open door for spurious errors >>>> due to >>>> typos in delimiters. But that's just my experience. >>>> >>>>> >>>>> * @Notification. >>>>> >>>>> As I mentioned, you can't use that name. >>>>> >>>>> The first paragraph of the description is indecipherable. >>>>> >>>>> The NotificationSender interface is unspecified. Based on the example, >>>>> I think it could potentially be a major usability improvement but it's >>>>> hard to be sure. >>>> >>>> >>>> >>>> I can add this interface to the proposal. The reason for it not being >>>> explicitly specified is that it is still very prototypical. >>>> >>>>> >>>>> I think it's extremely ugly to propagate the misspelling clazz into an >>>>> API where people will have to write it. Also, if it must extend >>>>> Notification then it should be specified as Class>>>> Notification>. >>>> >>>> >>>> >>>> The problem is that using the rather obvious "type" creates confusion >>>> with >>>> the "types". I can't use "class", of course. I am not too happy about >>>> this >>>> name either but anything else will just be more verbose. >>>> >>>>> >>>>> * @ManagedAttribute >>>>> >>>>> It's extremely strange for this to have getter and setter fields. Why >>>>> wouldn't it just be applied to those methods? >>>> >>>> >>>> >>>> Less boilerplate. One wouldn't need to retype the whole >>>> @ManagedAttribute >>>> definition twice. >>>> >>>>> >>>>> Promoting units from a descriptor field to a separate annotation >>>>> member seems like a good idea. The specified value would be copied >>>>> into the Descriptor. >>>> >>>> >>>> >>>> Exactly. >>>> >>>>> >>>>> * @ManagedOperation >>>>> >>>>> I don't see any reason to allow the name to be different from the >>>>> method name. It just complicates the spec. >>>> >>>> >>>> >>>> Well, you can do it manually. But I am open here - it would be nice >>>> to hear >>>> from potential users whether this would make sense. >>>> >>>>> >>>>> Instead of repeating a description member inside every annotation, JSR >>>>> 255 defined a top-level @Description, which included elements for >>>>> internationalization. Hardcoded strings are a step backwards. >>>> >>>> >>>> >>>> Until we have support for providing the client locale to the JMX >>>> server any >>>> internationalization is rather illusionary. >>>> >>>>> >>>>> Defining Impact inside this annotation is questionable. I'd expect >>>>> user code and possible future API changes to want to reference it >>>>> independently of the annotation. Also, the JSR 255 enum Impact had >>>>> methods to convert to and from the integer codes used by >>>>> MBeanOperationInfo. >>>> >>>> >>>> >>>> Please, consider class packaging being transitional. The classes may >>>> change >>>> their locations during the draft review. >>>> >>>>> >>>>> * @ManagedParameter >>>>> >>>>> The text repeatedly says operation name and method name when it means >>>>> parameter name. I assume that if the name member is empty then the >>>>> parameter name from reflection is used, which since Java 8 could be >>>>> the actual name of the parameter if the class was compiled with >>>>> -parameters. >>>> >>>> >>>> >>>> Precisely. >>>> >>>>> >>>>> * @RegistrationHandler >>>>> >>>>> It seems like an API smell for an annotation to say that it must be >>>>> applied to methods with a certain signature. I think a much better >>>>> approach would be to change the existing MBeanRegistration interface >>>>> so that its methods have default implementations that do nothing. That >>>>> removes the main reason that this interface is a pain: having to >>>>> implement four methods when you're usually only interested in one. You >>>>> could also add a preDeregister overload with MBeanServer and >>>>> ObjectName parameters, again with a default implementation. >>>> >>>> >>>> >>>> Well, @ManagedAttribute must be applied to methods of certain signatures >>>> only, too. >>>> >>>> I wanted to avoid the necessity for the annotated M(X)Bean to >>>> implement any >>>> other JMX specific interfaces explicitly. Therefore I proposed this >>>> annotation. >>>> >>>> -JB- >>>> >>>> >>>> >>>>> >>>>> ?amonn >>>>> >>>>> >>>>> 2015-03-04 0:47 GMT-08:00 Jaroslav Bachorik >>>>> : >>>>>> >>>>>> >>>>>> On 4.3.2015 02:09, Eamonn McManus wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Could you explain what you mean by this, regarding the annotations >>>>>>> that were already agreed on by the JSR 255 Expert Group: >>>>>>> >>>>>>> * Smaller scope compared to the proposed solution >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This is a leftover from the previous proposal which had wider scope >>>>>> than >>>>>> what is presented now. Still a few points remain. >>>>>> >>>>>> - ability to annotate fields turning them into attributes >>>>>> - ability to provide metadata directly in the annotations, not relying >>>>>> solely on inferring them from the annotated element >>>>>> - missing @ManagedConstructor to expose a constructor >>>>>> - optional 'service' argument to @ManagedBean annotation which will be >>>>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>>>> guidance about the recommended service interface when using >>>>>> JMX.newMXBeanProxy() >>>>>> >>>>>>> * Conceptually in pre JDK7 era >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I am afraid this relates more to the implementation - or at least the >>>>>> code I >>>>>> was able to reconstruct from the repo history. Shouldn't be mentioned >>>>>> here. >>>>>> >>>>>>> >>>>>>> I have a number of other comments, but procedurally I'm not sure what >>>>>>> the precedent is for summarily discarding work previously done in the >>>>>>> JCP on the same subject. I'd certainly have expected this JEP to >>>>>>> start >>>>>>> from that work, rather than proposing a starting point that isn't >>>>>>> even >>>>>>> correct Java. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Well, this is a draft review. The JSR 255 annotations work is not >>>>>> discarded. >>>>>> It is mentioned in the alternatives. The purpose of the open review >>>>>> is to >>>>>> find out whether it is ok to continue with proposed feature, modify >>>>>> it to >>>>>> use eg. JSR 255 work or abandon it completely. >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>>> >>>>>>> ?amonn McManus, former JSR 255 Spec Lead >>>>>>> >>>>>>> 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik >>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this draft JEP for JMX Specific Annotations for >>>>>>>> Registration of Managed Resources: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8044507 >>>>>>>> >>>>>>>> Background: >>>>>>>> Current mechanism of defining an MBean requires to provide an MBean >>>>>>>> interface and its implementation. The interface and the >>>>>>>> implementation >>>>>>>> must >>>>>>>> conform to the strict naming and visibility rules in order for the >>>>>>>> introspection to be able to bind them. >>>>>>>> >>>>>>>> At least the same level of verbosity is required when adding an >>>>>>>> MBeanInfo >>>>>>>> to generate MBean metadata. >>>>>>>> >>>>>>>> All this leads to a rather verbose code containing a lot of >>>>>>>> repeating >>>>>>>> boilerplate parts even for the most simple MBean registrations. >>>>>>>> >>>>>>>> This JEP proposes to add a set of annotations for registration and >>>>>>>> configuration of manageable resources (in other word 'MBeans'). >>>>>>>> These >>>>>>>> annotations will be used to generate all the metadata necessary >>>>>>>> for a >>>>>>>> resources to be accepted by the current JMX system. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> > From yekaterina.kantserova at oracle.com Thu Mar 26 12:38:14 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 26 Mar 2015 13:38:14 +0100 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <55134092.801@oracle.com> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> <55134092.801@oracle.com> Message-ID: <5513FDB6.6070606@oracle.com> Mandy, Thank you very much for the catch! The updated webrev can be found here: http://cr.openjdk.java.net/~ykantser/8075586/webrev.00/ Best regards, Katja On 03/26/2015 12:11 AM, Mandy Chung wrote: > Alexandar, Shura, > > The dependency analysis is not up-to-date that sun.tools.jar > has been moved to jdk.jartool module in jdk9 b55. It has been > in jdk9/dev since 3/6. > > I have pointed out multiple times previously that jdk.dev/sun.tools.jar > is wrong in the jdk side of change. > > Below includes an example. > Mandy > > --- old/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 > 16:24:41.462038538 +0300 > +++ new/test/runtime/RedefineTests/RedefineAnnotations.java 2015-03-25 > 16:24:41.386038539 +0300 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -25,6 +25,9 @@ > * @test > * @library /testlibrary > * @summary Test that type annotations are retained after a retransform > + * @modules java.base/jdk.internal.org.objectweb.asm > + * java.instrument > + * jdk.dev/sun.tools.jar > * @run main RedefineAnnotations buildagent > * @run main/othervm -javaagent:redefineagent.jar RedefineAnnotations > */ > > > On 3/25/15 7:38 AM, Alexander Kulyakhtin wrote: >> Hi >> >> Please, find the updated review for the bulk @modules change at the >> link below. >> >> We have fixed the copyrights and the files mentioned in the mail from >> Lois. >> >> http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html >> >> Best regards, >> Alex >> >> >> >> ----- Original Message ----- >> From: lois.foltan at oracle.com >> To: yekaterina.kantserova at oracle.com >> Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, >> hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, >> alexandre.iline at oracle.com >> Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >> hotspot tests >> >> >> This looks good, thank you for making these changes! A couple of >> comments that I don't feel need another webrev but should be fixed >> before pushing. >> >> - copyrights on all the tests need to be updated >> - the following tests have a blank comment line before the new >> "@modules" line that could be removed >> test/gc/metaspace/TestMetaspacePerfCounters.java >> test/runtime/contended/Basic.java >> test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java >> test/compiler/cpuflags/RestoreMXCSR.java >> test/compiler/debug/VerifyAdapterSharing.java >> >> Thanks, >> Lois >> >> On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >>> Notifying hotspot-dev as well. >>> >>> // Katja >>> >>> >>> >>> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>>> Could the reviewers, please, have a look at the proposed changes >>>> below? >>>> >>>> In addition, we are going to make a change to the TEST.ROOT file as >>>> indicated by Staffan in the mail below. >>>> >>>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>>> can be pushed into the jdk? >>>> >>>> Best regards, >>>> Alex >>>> >>>> ----- Original Message ----- >>>> From: staffan.larsen at oracle.com >>>> To: alexander.kulyakhtin at oracle.com >>>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>>> hotspot tests >>>> >>>> I haven?t looked at the changes in detail, but please change the >>>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could you, please, review the fix below. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>>> >>>>> The fix adds @modules keyword to the existing hotspot tests, as >>>>> needed, so that the tests can access the required API when the new >>>>> modular architecture is in place. >>>>> >>>>> Best regards, >>>>> Alex > From mandy.chung at oracle.com Thu Mar 26 20:18:05 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 Mar 2015 13:18:05 -0700 Subject: RFR: JDK-8075586: add @modules as needed to the open hotspot tests In-Reply-To: <5513FDB6.6070606@oracle.com> References: <57dd28b6-1a2a-4171-a5b3-d41711973ef2@default> <55134092.801@oracle.com> <5513FDB6.6070606@oracle.com> Message-ID: <5514697D.3020308@oracle.com> On 3/26/15 5:38 AM, Yekaterina Kantserova wrote: > Mandy, > > Thank you very much for the catch! The updated webrev can be found here: > > http://cr.openjdk.java.net/~ykantser/8075586/webrev.00/ > Thanks for fixing this. Lois and other have reviewed it. I only tried to spot anything stick out. This looks okay and good to push. + * @modules java.base/sun.misc + * java.management I don't have the cycle to find out where the dependencies for this patch. looks like they are mostly from the testlibrary. Per our offline discussion, it'd be desirable to update the testlibrary and tests to assist the dependency analysis process or eliminate the dependency. One more thing to mention is that the testlibrary depending java.management to get the process ID can soon be removed once the new Process API getting pid is integrated into JDK 9. thanks Mandy > Best regards, > Katja > > > On 03/26/2015 12:11 AM, Mandy Chung wrote: >> Alexandar, Shura, >> >> The dependency analysis is not up-to-date that sun.tools.jar >> has been moved to jdk.jartool module in jdk9 b55. It has been >> in jdk9/dev since 3/6. >> >> I have pointed out multiple times previously that jdk.dev/sun.tools.jar >> is wrong in the jdk side of change. >> >> Below includes an example. >> Mandy >> >> --- old/test/runtime/RedefineTests/RedefineAnnotations.java >> 2015-03-25 16:24:41.462038538 +0300 >> +++ new/test/runtime/RedefineTests/RedefineAnnotations.java >> 2015-03-25 16:24:41.386038539 +0300 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -25,6 +25,9 @@ >> * @test >> * @library /testlibrary >> * @summary Test that type annotations are retained after a retransform >> + * @modules java.base/jdk.internal.org.objectweb.asm >> + * java.instrument >> + * jdk.dev/sun.tools.jar >> * @run main RedefineAnnotations buildagent >> * @run main/othervm -javaagent:redefineagent.jar RedefineAnnotations >> */ >> >> >> On 3/25/15 7:38 AM, Alexander Kulyakhtin wrote: >>> Hi >>> >>> Please, find the updated review for the bulk @modules change at the >>> link below. >>> >>> We have fixed the copyrights and the files mentioned in the mail >>> from Lois. >>> >>> http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8075586/index.html >>> >>> Best regards, >>> Alex >>> >>> >>> >>> ----- Original Message ----- >>> From: lois.foltan at oracle.com >>> To: yekaterina.kantserova at oracle.com >>> Cc: serviceability-dev at openjdk.java.net, staffan.larsen at oracle.com, >>> hotspot-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com, >>> alexandre.iline at oracle.com >>> Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>> hotspot tests >>> >>> >>> This looks good, thank you for making these changes! A couple of >>> comments that I don't feel need another webrev but should be fixed >>> before pushing. >>> >>> - copyrights on all the tests need to be updated >>> - the following tests have a blank comment line before the new >>> "@modules" line that could be removed >>> test/gc/metaspace/TestMetaspacePerfCounters.java >>> test/runtime/contended/Basic.java >>> test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java >>> test/compiler/cpuflags/RestoreMXCSR.java >>> test/compiler/debug/VerifyAdapterSharing.java >>> >>> Thanks, >>> Lois >>> >>> On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote: >>>> Notifying hotspot-dev as well. >>>> >>>> // Katja >>>> >>>> >>>> >>>> On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote: >>>>> Could the reviewers, please, have a look at the proposed changes >>>>> below? >>>>> >>>>> In addition, we are going to make a change to the TEST.ROOT file as >>>>> indicated by Staffan in the mail below. >>>>> >>>>> Do you think the changes (plus the one-line change to the TEST.ROOT) >>>>> can be pushed into the jdk? >>>>> >>>>> Best regards, >>>>> Alex >>>>> >>>>> ----- Original Message ----- >>>>> From: staffan.larsen at oracle.com >>>>> To: alexander.kulyakhtin at oracle.com >>>>> Cc: serviceability-dev at openjdk.java.net, alexandre.iline at oracle.com >>>>> Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat >>>>> Subject: Re: RFR: JDK-8075586: add @modules as needed to the open >>>>> hotspot tests >>>>> >>>>> I haven?t looked at the changes in detail, but please change the >>>>> requiredVersion in TEST.ROOT to 4.1 b11 as part of this change. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> On 20 mar 2015, at 13:16, Alexander Kulyakhtin >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could you, please, review the fix below. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8075586 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/ >>>>>> >>>>>> The fix adds @modules keyword to the existing hotspot tests, as >>>>>> needed, so that the tests can access the required API when the new >>>>>> modular architecture is in place. >>>>>> >>>>>> Best regards, >>>>>> Alex >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Mar 27 00:50:01 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 26 Mar 2015 17:50:01 -0700 Subject: RFR (S) 8073705: jvmtiRedefineClasses.cpp assert cache ptrs must match Message-ID: <5514A939.1090200@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8073705 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ Summary: This is the 2-nd round of performance/calability fixes in class redefinition. This time, the two remaining issues that were left alone in the first round fix: - optimized ConstantPoolCache::adjust_method_entries() is used for previous versions - the MemberNameTable::adjust_method_entries() has been optimized too - some cleanup Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument, com/sun/jdi Thanks, Serguei From serguei.spitsyn at oracle.com Fri Mar 27 02:36:21 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 26 Mar 2015 19:36:21 -0700 Subject: RFR (S) 8073705: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <5514A939.1090200@oracle.com> References: <5514A939.1090200@oracle.com> Message-ID: <5514C225.1030701@oracle.com> Sorry, please, skip this email. The subject was copied from another bug. I'll re-post the RFR shortly. Thanks, Serguei On 3/26/15 5:50 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8073705 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ > > > > Summary: > > This is the 2-nd round of performance/calability fixes in class > redefinition. > This time, the two remaining issues that were left alone in the > first round fix: > - optimized ConstantPoolCache::adjust_method_entries() is used > for previous versions > - the MemberNameTable::adjust_method_entries() has been optimized > too > - some cleanup > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument, > com/sun/jdi > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Fri Mar 27 02:38:57 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 26 Mar 2015 19:38:57 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition Message-ID: <5514C2C1.9040302@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8073705 Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ Summary: This is the 2-nd round of performance/calability fixes in class redefinition. This time, the two remaining issues that were left alone in the first round fix: - optimized ConstantPoolCache::adjust_method_entries() is used for previous versions - the MemberNameTable::adjust_method_entries() has been optimized too - some cleanup Testing: In progress: nsk redefine classes tests, JTREG java/lang/instrument, com/sun/jdi Thanks, Serguei From fredrik.arvidsson at oracle.com Fri Mar 27 13:34:36 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 27 Mar 2015 14:34:36 +0100 Subject: RFR(XS): 8076154: com/sun/jdi/InstanceFilter.java failing due to missing MethodEntryRequest calls Message-ID: <55155C6C.3030901@oracle.com> Please review this small test fix for JDK- 8076154. Bug: https://bugs.openjdk.java.net/browse/JDK-8076154 Webrev: http://cr.openjdk.java.net/~farvidsson/8076154/webrev.00/ I am planning to backport this fix to 8u-dev as soon as it is reviewed and integrated in 9. Cheers /F -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Mar 27 14:03:32 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 27 Mar 2015 15:03:32 +0100 Subject: RFR(XS): 8076154: com/sun/jdi/InstanceFilter.java failing due to missing MethodEntryRequest calls In-Reply-To: <55155C6C.3030901@oracle.com> References: <55155C6C.3030901@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 27 mar 2015, at 14:34, Fredrik Arvidsson wrote: > > Please review this small test fix for JDK- 8076154. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076154 > Webrev: http://cr.openjdk.java.net/~farvidsson/8076154/webrev.00/ > > I am planning to backport this fix to 8u-dev as soon as it is reviewed and integrated in 9. > > Cheers > /F -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheleswer.sahu at oracle.com Fri Mar 27 07:36:11 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Fri, 27 Mar 2015 13:06:11 +0530 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <55141556.1070005@oracle.com> References: <55141556.1070005@oracle.com> Message-ID: <5515086B.7050907@oracle.com> Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 with fix successfully. As I do not have account for OpenJDK, David Buck will push the fix into jdk9/hs-rt/. Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ Regards, Cheleswer From yekaterina.kantserova at oracle.com Fri Mar 27 14:21:43 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 27 Mar 2015 15:21:43 +0100 Subject: RFR 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' In-Reply-To: <743A07B6-736B-43FE-8961-6F6FB218AF63@oracle.com> References: <550A9DFB.1070204@oracle.com> <8008CDA9-BCC1-41CB-8A1F-7BF1D3EBD1B7@oracle.com> <550FF107.5030504@oracle.com> <743A07B6-736B-43FE-8961-6F6FB218AF63@oracle.com> Message-ID: <55156777.9030203@oracle.com> The tests looks good! Thank you very much for fixing. // Katja On 03/23/2015 12:41 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 23 mar 2015, at 11:55, Jaroslav Bachorik wrote: >> >> On 23.3.2015 08:50, Staffan Larsen wrote: >>> diagnosticCommand.cpp: >>> - Should SetVMFlagDCmd really be inside "#if INCLUDE_SERVICES? ? >> Probably not. On the other hand, the JVMTIDataDumpDCmd registration should probably be guarded by #if INCLUDE_JVMTI >> >>> - L227-234: strange indentation >> Fixed. >> >> Updated webrev (+ removing the extraneous #include "services/attachListener.hpp" in diagnosticCommand.hpp) : http://cr.openjdk.java.net/~jbachorik/8054890/webrev.01 >> >> -JB- >> >> >>> >>> /Staffan >>> >>> >>>> On 19 mar 2015, at 10:59, Jaroslav Bachorik wrote: >>>> >>>> Please, review the following change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8054890 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8054890/webrev.00 >>>> >>>> This patch is about adding 2 new diagnostic commands - VM.set_flag and JVMTI.data_dump. >>>> >>>> VM.set_flag allows to set any writeable flag. It takes the flag name and the flag value in textual form. The mutability of the flag and the value format checks are forwarded to the shared vm management code. >>>> >>>> JVMTI.data_dump will send the data dump request to JVMTI. >>>> >>>> Both of these commands are covered by the corresponding tests. >>>> >>>> Thanks, >>>> >>>> -JB- From jaroslav.bachorik at oracle.com Fri Mar 27 16:05:03 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 27 Mar 2015 17:05:03 +0100 Subject: Please review draft JEP: JMX Specific Annotations for Registration of Managed Resources In-Reply-To: References: <54F5E108.3010902@oracle.com> <54F6C6B0.2040908@oracle.com> <54F75127.4060205@oracle.com> <5510033F.8030205@oracle.com> <5512E7FE.9090707@oracle.com> Message-ID: <55157FAF.6050101@oracle.com> On 26.3.2015 03:47, Eamonn McManus wrote: > A couple more comments on the draft as it stands. > > I like the approach of @NotificationSupport on fields. However, the > name is not great I think. Maybe nest an @Inject annotation inside > NotificationSender, so you could write > @NotificationSender.Inject private NotificationSender sender; > ? I agree that it is overcomplicated still to setup the notification support. I will let the idea ripen a bit and hopefully we will be able to come up with a nice and simple name. > > I think you are right about MBeanRegistration not being a great > alternative to annotating an explicit lifecycle method, even if > MBeanRegistration acquires default implementations of its methods. > Having classes implement callback interfaces is generally not very > clean, unless that is all they do. @RegistrationHandler on a method > with a RegisterEvent parameter is a good alternative. The > RegisterEvent parameter would be required, I think; otherwise the > MBean object would have to keep track of whether it is already > registered in order to know that a second call means it has been > unregistered. Yes, I've also realized that the parameter-less handler method would be close to useless. I did update the JEP to require the parameter of type RegisterEvent. Thanks, -JB- > > ?amonn > > > 2015-03-25 9:53 GMT-07:00 Jaroslav Bachorik : >> On 23.3.2015 13:12, Jaroslav Bachorik wrote: >>> >>> On 18.3.2015 23:28, Eamonn McManus wrote: >>>>> >>>>> Mainly because the long term goal (beyond the scope of this JEP, >>>>> anyway) would be to get users to slowly migrate to the annotation >>>>> based M(X)Beans. Not giving them the chance to specify the service >>>>> interface via annotations will mean keeping this dichotomy forever. >>>> >>>> >>>> I'm not sure that is a good goal. M(X)Bean interfaces allow clients to >>>> make proxies, and there's no obvious equivalent with annotations. >>> >>> >>> You still can create proxies for MXBeans defined through annotations - >>> the 'service' attribute of '@ManagedBean' annotation serves exactly this >>> purpose. The value of this attribute will be used in the associated >>> Descriptor under the 'interfaceClassName' key. >>> >>> In fact, the resulting instance registered in the MBeanServer for an >>> annotation based MXBean is undistinguishable from the one based on >>> MXBean interface. >>> >>>> Though I suppose you could provide a standard annotation processor >>>> that would generate the implied interface from the annotations. >>> >>> >>> Yes, this might be an option. But probably beyond the scope of this JEP. >>> I need to keep the change as simple as possible - otherwise it might not >>> make it for JDK 9. >>> >>>> >>>> Re @Notification: Please don't add types to the JMX API with the same >>>> name as types that are already there. That will make the API very >>>> unpleasant to use. >>> >>> >>> Agreed. A nice, simple name for this annotation will have to be found. >>> >>>> >>>> I don't understand what this text means: "It can also be used as a >>>> parameter annotation for a field of type NotificationSender." Is it >>> >>> >>> Should read '... for an argument of type NotificationSender' >>> >>>> applied to parameters or fields? The code example shows the former, >>>> but that seems a bit limiting. What if the MBean wants to send a >>>> notification at some point unrelated to method invocation? >>> >>> >>> For the sakes of simplicity I opted for something that seemed to be the >>> common case - sending notification from within the managed operations or >>> attribute getters/setters. Could you come up with a use case when it is >>> inevitable to send notification from a code not reachable either through >>> a managed operation or attribute getter/setter? If it is something >>> generally needed I might make the @Notification applicable to fields as >>> well. >> >> >> I was able to cleanup the notifications part a bit - moving the declaration >> from the top level annotation and the per-parameter annotations to just one >> place - an annotated field of type NotificationSender. This will also solve >> the problem with emitting notifications from the methods associated with >> neither the managed operations nor attributes. Basically a custom dependency >> injection - but very simple one without all the bells-and-whistles. >> Unfortunately, the @Resource annotation has been moved to jaxws in JDK 9 :( >> >> I also simplified the @RegistrationHandler - the solution you proposed, >> extending the MBeanRegistration interface, is not something I would really >> like to do now - mostly because a logical part of this interface is hidden >> in DynamicMBean2 (preRegister2 method) and consolidating this will take a >> major effort on its own. >> >> Hopefully I was able to come up with concise and simple naming for the >> annotations - conveying their purpose and not being too chatty. >> >> Eamonn, thank you once again for taking your time to review this draft. I am >> planning to submit this JEP in the next two days. Submitting the JEP does >> not mean freezing the specification - just acknowledging that the JEP is >> worth of pursuing. There will be at least one more additional JEP review in >> the process and then the final code review before push. >> >> >> -JB- >> >> >>> >>> Thanks, >>> >>> -JB- >>> >>>> >>>> ?amonn >>>> >>>> >>>> 2015-03-04 10:38 GMT-08:00 Jaroslav Bachorik >>>> : >>>>> >>>>> Thanks for taking the time to review this. >>>>> I apologize for the formatting mess - clearly the JIRA's markdown >>>>> processor >>>>> is rather confused with more extensive usage of the code blocks. >>>>> >>>>> On 4.3.2015 18:42, Eamonn McManus wrote: >>>>>> >>>>>> >>>>>> Thank you for updating the JEP text referencing JSR 255. >>>>>> >>>>>> Perhaps unsurprisingly I disagree with many of the differences between >>>>>> this proposal and the one we carefully thought out in JSR 255. Even >>>>>> though a lot has changed in the meanwhile, I don't see anything that >>>>>> invalidates our assumptions of the time. >>>>>> >>>>>> For reference, a snapshot of the JSR 255 javadoc is at >>>>>> http://hg.openjdk.java.net/jmx2/jmx2/file/f417598a7b72/javadoc. >>>>>> Unfortunately, it appears that the Mercurial server now serves these >>>>>> files as application/binary, probably because of the change here: >>>>>> >>>>>> >>>>>> http://mercurial.selenic.com/wiki/UpgradeNotes#A1.9.1:_guessmime.2C_revert_behavior_restored. >>>>>> >>>>>> >>>>>> To address some specific points: >>>>>>> >>>>>>> >>>>>>> would you care to elaborate what you find to be not "even correct >>>>>>> Java"? >>>>>> >>>>>> >>>>>> >>>>>> As of Java 8, annotation elements cannot have null values so the >>>>>> "default null" clauses are nonsense. I have not seen any proposal to >>>>>> change this in Java 9. The @ManagedBean definition also has an obvious >>>>>> syntax error. >>>>> >>>>> >>>>> >>>>> Agreed. They should not be there. During the updates JIRA failed to >>>>> update >>>>> the field and I failed to notice that my edits didn't apply. >>>>> >>>>>> >>>>>>> - ability to annotate fields turning them into attributes >>>>>> >>>>>> >>>>>> >>>>>> This might be useful for read-only attributes. I'd question whether it >>>>>> is useful for read/write attributes, because I think it will be very >>>>>> unusual for you to want neither validation of the new value nor >>>>>> behaviour to be triggered by the set. >>>>> >>>>> >>>>> >>>>> On the other hand it gives the possibility to expose those read-only >>>>> fields >>>>> (eg. metrics or settings being immutable via JMX) without the >>>>> necessity to >>>>> conjure the getter. >>>>> >>>>>> >>>>>>> - ability to provide metadata directly in the annotations, not relying >>>>>>> solely on inferring them from the annotated element >>>>>> >>>>>> >>>>>> >>>>>> I'm not sure what specifically this refers to. Do you mean for example >>>>>> that it is possible to add @ManagedAttribute to a method that does not >>>>>> look like getFoo() and nevertheless have the annotation say that the >>>>>> attribute is called foo? I don't see any particular advantage to that >>>>>> flexibility. The getFoo() pattern is already familiar, and having a >>>>>> second, completely different way of specifying the name just >>>>>> complicates the spec for not much benefit. >>>>> >>>>> >>>>> >>>>> And yet it can be done in DynamicMBeans. My starting point was the >>>>> attempt >>>>> to give the user the same flexibility she would have if she were >>>>> hand-crafting the various MBean*Info classes. >>>>> >>>>>> >>>>>>> - missing @ManagedConstructor to expose a constructor >>>>>> >>>>>> >>>>>> >>>>>> We deliberately omitted this. The fact that MBeanConstructorInfo >>>>>> exists at all is in my opinion a mistake in the original JMX >>>>>> specification. What does it mean for an MBean to tell you how to >>>>>> construct another instance of itself? And if the purpose is to specify >>>>>> which constructors from this class are available to the MBean Server, >>>>>> there's no use for names and descriptions, and there's no particular >>>>>> advantage over just saying that all public constructors are available. >>>>> >>>>> >>>>> >>>>> I don't know the meaning. I was not involved in the inception of this >>>>> API. >>>>> My reasoning is that if you can do it by hand than it should probably be >>>>> achievable by annotation as well. The other route would be >>>>> deprecating the >>>>> MBeanConstructorInfo now and removing it in a subsequent release. >>>>> >>>>>> >>>>>>> - optional 'service' argument to @ManagedBean annotation which will be >>>>>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>>>>> guidance about the recommended service interface when using >>>>>>> JMX.newMXBeanProxy() >>>>>> >>>>>> >>>>>> >>>>>> If you have such an interface, why wouldn't you just use it to define >>>>>> the MBean and dispense with annotations? >>>>> >>>>> >>>>> >>>>> Mainly because the long term goal (beyond the scope of this JEP, anyway) >>>>> would be to get users to slowly migrate to the annotation based >>>>> M(X)Beans. >>>>> Not giving them the chance to specify the service interface via >>>>> annotations >>>>> will mean keeping this dichotomy forever. >>>>> >>>>>> >>>>>> Some other comments: >>>>>> >>>>>> * @ManagedBean. >>>>>> >>>>>> We called this @MBean because we also had an @MXBean annotation. That >>>>>> annotation exists today, but JSR 255 allowed it to be applied to a >>>>>> class as well as to an interface. It appears that @ManagedBean only >>>>>> defines MXBeans, which is a legitimate choice but, first, it should be >>>>>> called out more explicitly, and, second, wouldn't it then make sense >>>>>> to extend the existing @MXBean annotation? >>>>> >>>>> >>>>> >>>>> I thought about this and extending an existing annotation is pretty >>>>> sensitive from the compatibility PoV. Also, giving the annotation >>>>> different >>>>> meanings depending whether it is used on interface or class is rather >>>>> wobbly. I am still open to suggestions for better naming, though. >>>>> >>>>>> >>>>>> The specification is inconsistent as to whether the annotation is >>>>>> @ManagedBean or @MBean. >>>>>> >>>>>> I think it is a fair idea to have an objectName field, but the idea of >>>>>> randomly appending numbers to the name for disambiguation is broken. >>>>> >>>>> >>>>> >>>>> Ok. Valid point. >>>>> >>>>>> Something like @ObjectNameTemplate from JSR 255 is more appropriate. >>>>> >>>>> >>>>> >>>>> Yes, but it brings even more complexity. >>>>> >>>>>> >>>>>> The text for the notifications() member references @TypeMapping but >>>>>> does not say what that is. The declared type is Notification[] and the >>>>>> text defines an annotation @Notification, but there is already a class >>>>>> called Notification in javax.management. >>>>> >>>>> >>>>> >>>>> The annotations should be placed in a sub-package of >>>>> "javax.management". The >>>>> "javax.management" is pretty crowded already. >>>>> >>>>>> >>>>>> I think that the simple "name=value" syntax used by JSR 255's >>>>>> @DescriptorFields is preferable to the unspecified and verbose type >>>>>> @Tag. I don't see an advantage to making people write @Tag(name = >>>>>> "foo", value = "bar") rather than just "foo=bar". This syntax is >>>>>> already present in the JMX spec, for example in the >>>>>> ImmutableDescriptor constructor. >>>>> >>>>> >>>>> >>>>> IMO, having just plain text there will open door for spurious errors >>>>> due to >>>>> typos in delimiters. But that's just my experience. >>>>> >>>>>> >>>>>> * @Notification. >>>>>> >>>>>> As I mentioned, you can't use that name. >>>>>> >>>>>> The first paragraph of the description is indecipherable. >>>>>> >>>>>> The NotificationSender interface is unspecified. Based on the example, >>>>>> I think it could potentially be a major usability improvement but it's >>>>>> hard to be sure. >>>>> >>>>> >>>>> >>>>> I can add this interface to the proposal. The reason for it not being >>>>> explicitly specified is that it is still very prototypical. >>>>> >>>>>> >>>>>> I think it's extremely ugly to propagate the misspelling clazz into an >>>>>> API where people will have to write it. Also, if it must extend >>>>>> Notification then it should be specified as Class>>>>> Notification>. >>>>> >>>>> >>>>> >>>>> The problem is that using the rather obvious "type" creates confusion >>>>> with >>>>> the "types". I can't use "class", of course. I am not too happy about >>>>> this >>>>> name either but anything else will just be more verbose. >>>>> >>>>>> >>>>>> * @ManagedAttribute >>>>>> >>>>>> It's extremely strange for this to have getter and setter fields. Why >>>>>> wouldn't it just be applied to those methods? >>>>> >>>>> >>>>> >>>>> Less boilerplate. One wouldn't need to retype the whole >>>>> @ManagedAttribute >>>>> definition twice. >>>>> >>>>>> >>>>>> Promoting units from a descriptor field to a separate annotation >>>>>> member seems like a good idea. The specified value would be copied >>>>>> into the Descriptor. >>>>> >>>>> >>>>> >>>>> Exactly. >>>>> >>>>>> >>>>>> * @ManagedOperation >>>>>> >>>>>> I don't see any reason to allow the name to be different from the >>>>>> method name. It just complicates the spec. >>>>> >>>>> >>>>> >>>>> Well, you can do it manually. But I am open here - it would be nice >>>>> to hear >>>>> from potential users whether this would make sense. >>>>> >>>>>> >>>>>> Instead of repeating a description member inside every annotation, JSR >>>>>> 255 defined a top-level @Description, which included elements for >>>>>> internationalization. Hardcoded strings are a step backwards. >>>>> >>>>> >>>>> >>>>> Until we have support for providing the client locale to the JMX >>>>> server any >>>>> internationalization is rather illusionary. >>>>> >>>>>> >>>>>> Defining Impact inside this annotation is questionable. I'd expect >>>>>> user code and possible future API changes to want to reference it >>>>>> independently of the annotation. Also, the JSR 255 enum Impact had >>>>>> methods to convert to and from the integer codes used by >>>>>> MBeanOperationInfo. >>>>> >>>>> >>>>> >>>>> Please, consider class packaging being transitional. The classes may >>>>> change >>>>> their locations during the draft review. >>>>> >>>>>> >>>>>> * @ManagedParameter >>>>>> >>>>>> The text repeatedly says operation name and method name when it means >>>>>> parameter name. I assume that if the name member is empty then the >>>>>> parameter name from reflection is used, which since Java 8 could be >>>>>> the actual name of the parameter if the class was compiled with >>>>>> -parameters. >>>>> >>>>> >>>>> >>>>> Precisely. >>>>> >>>>>> >>>>>> * @RegistrationHandler >>>>>> >>>>>> It seems like an API smell for an annotation to say that it must be >>>>>> applied to methods with a certain signature. I think a much better >>>>>> approach would be to change the existing MBeanRegistration interface >>>>>> so that its methods have default implementations that do nothing. That >>>>>> removes the main reason that this interface is a pain: having to >>>>>> implement four methods when you're usually only interested in one. You >>>>>> could also add a preDeregister overload with MBeanServer and >>>>>> ObjectName parameters, again with a default implementation. >>>>> >>>>> >>>>> >>>>> Well, @ManagedAttribute must be applied to methods of certain signatures >>>>> only, too. >>>>> >>>>> I wanted to avoid the necessity for the annotated M(X)Bean to >>>>> implement any >>>>> other JMX specific interfaces explicitly. Therefore I proposed this >>>>> annotation. >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>>> >>>>>> ?amonn >>>>>> >>>>>> >>>>>> 2015-03-04 0:47 GMT-08:00 Jaroslav Bachorik >>>>>> : >>>>>>> >>>>>>> >>>>>>> On 4.3.2015 02:09, Eamonn McManus wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Could you explain what you mean by this, regarding the annotations >>>>>>>> that were already agreed on by the JSR 255 Expert Group: >>>>>>>> >>>>>>>> * Smaller scope compared to the proposed solution >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is a leftover from the previous proposal which had wider scope >>>>>>> than >>>>>>> what is presented now. Still a few points remain. >>>>>>> >>>>>>> - ability to annotate fields turning them into attributes >>>>>>> - ability to provide metadata directly in the annotations, not relying >>>>>>> solely on inferring them from the annotated element >>>>>>> - missing @ManagedConstructor to expose a constructor >>>>>>> - optional 'service' argument to @ManagedBean annotation which will be >>>>>>> reflected in the descriptor's 'interfaceClassName' field to provide a >>>>>>> guidance about the recommended service interface when using >>>>>>> JMX.newMXBeanProxy() >>>>>>> >>>>>>>> * Conceptually in pre JDK7 era >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am afraid this relates more to the implementation - or at least the >>>>>>> code I >>>>>>> was able to reconstruct from the repo history. Shouldn't be mentioned >>>>>>> here. >>>>>>> >>>>>>>> >>>>>>>> I have a number of other comments, but procedurally I'm not sure what >>>>>>>> the precedent is for summarily discarding work previously done in the >>>>>>>> JCP on the same subject. I'd certainly have expected this JEP to >>>>>>>> start >>>>>>>> from that work, rather than proposing a starting point that isn't >>>>>>>> even >>>>>>>> correct Java. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Well, this is a draft review. The JSR 255 annotations work is not >>>>>>> discarded. >>>>>>> It is mentioned in the alternatives. The purpose of the open review >>>>>>> is to >>>>>>> find out whether it is ok to continue with proposed feature, modify >>>>>>> it to >>>>>>> use eg. JSR 255 work or abandon it completely. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> ?amonn McManus, former JSR 255 Spec Lead >>>>>>>> >>>>>>>> 2015-03-03 8:27 GMT-08:00 Jaroslav Bachorik >>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this draft JEP for JMX Specific Annotations for >>>>>>>>> Registration of Managed Resources: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8044507 >>>>>>>>> >>>>>>>>> Background: >>>>>>>>> Current mechanism of defining an MBean requires to provide an MBean >>>>>>>>> interface and its implementation. The interface and the >>>>>>>>> implementation >>>>>>>>> must >>>>>>>>> conform to the strict naming and visibility rules in order for the >>>>>>>>> introspection to be able to bind them. >>>>>>>>> >>>>>>>>> At least the same level of verbosity is required when adding an >>>>>>>>> MBeanInfo >>>>>>>>> to generate MBean metadata. >>>>>>>>> >>>>>>>>> All this leads to a rather verbose code containing a lot of >>>>>>>>> repeating >>>>>>>>> boilerplate parts even for the most simple MBean registrations. >>>>>>>>> >>>>>>>>> This JEP proposes to add a set of annotations for registration and >>>>>>>>> configuration of manageable resources (in other word 'MBeans'). >>>>>>>>> These >>>>>>>>> annotations will be used to generate all the metadata necessary >>>>>>>>> for a >>>>>>>>> resources to be accepted by the current JMX system. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> >> From jaroslav.bachorik at oracle.com Fri Mar 27 16:29:50 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 27 Mar 2015 17:29:50 +0100 Subject: RFR 8023093: Add ManagementAgent.status diagnostic command Message-ID: <5515857E.9080902@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8023093 Webrev: http://cr.openjdk.java.net/~jbachorik/8023093/webrev.00 (hotspot, jdk) This change adds a new 'ManagementAgent.status' diagnostic command. This command will output the current status of the management agent in the following format ``` Agent: ( ConnectionType: Protocol: Host: URL: ( Properties: ( = )+ )? )+ ``` Where: means an arbitrary value | means 'or' ( and ) denote a block + block repeats one or more times ? block appears at most once A new test is added exercising this diagnostic command. While adding the test I factored out the shared functionality from the JMXStartStopTest class and caused the changes in the test area to be a bit more extensive than just adding a new test class. Thanks, -JB- From jaroslav.bachorik at oracle.com Fri Mar 27 16:39:04 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 27 Mar 2015 17:39:04 +0100 Subject: RFR(XS): 8076154: com/sun/jdi/InstanceFilter.java failing due to missing MethodEntryRequest calls In-Reply-To: <55155C6C.3030901@oracle.com> References: <55155C6C.3030901@oracle.com> Message-ID: <551587A8.3010204@oracle.com> Looks good! -JB- On 27.3.2015 14:34, Fredrik Arvidsson wrote: > Please review this small test fix for JDK- 8076154. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076154 > Webrev: http://cr.openjdk.java.net/~farvidsson/8076154/webrev.00/ > > I am planning to backport this fix to 8u-dev as soon as it is reviewed > and integrated in 9. > > Cheers > /F From jaroslav.bachorik at oracle.com Fri Mar 27 16:39:37 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 27 Mar 2015 17:39:37 +0100 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <5515086B.7050907@oracle.com> References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com> Message-ID: <551587C9.4090404@oracle.com> This looks fine. -JB- On 27.3.2015 08:36, cheleswer sahu wrote: > Hi, > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 > with fix successfully. As I do not have account for OpenJDK, David Buck > will push > the fix into jdk9/hs-rt/. > > Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ > > Regards, > Cheleswer > > > > From coleen.phillimore at oracle.com Fri Mar 27 18:46:58 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Mar 2015 14:46:58 -0400 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <55135DE5.2010705@oracle.com> References: <55135DE5.2010705@oracle.com> Message-ID: <5515A5A2.5020908@oracle.com> This fix looks correct. Is there any way to write a test for this? thanks, Coleen On 3/25/15, 9:16 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8066679 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ > > > > Summary: > > There can be multiple concurrent RetransformClasses calls on > different threads. > So that, the assert "cache ptrs must match" is incorrect as it was > based on wrong assumptions. > The fix removes two related asserts and also frees the scratch_class > cached_class_file_bytes > if it is necessary to avoid leaking the memory. > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Fri Mar 27 18:57:08 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 27 Mar 2015 11:57:08 -0700 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <5515A5A2.5020908@oracle.com> References: <55135DE5.2010705@oracle.com> <5515A5A2.5020908@oracle.com> Message-ID: <5515A804.6030204@oracle.com> Thanks, Coleen! I'll check about test. Thanks, Serguei On 3/27/15 11:46 AM, Coleen Phillimore wrote: > > This fix looks correct. Is there any way to write a test for this? > thanks, > Coleen > > On 3/25/15, 9:16 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8066679 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ >> >> >> >> Summary: >> >> There can be multiple concurrent RetransformClasses calls on >> different threads. >> So that, the assert "cache ptrs must match" is incorrect as it was >> based on wrong assumptions. >> The fix removes two related asserts and also frees the >> scratch_class cached_class_file_bytes >> if it is necessary to avoid leaking the memory. >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei > From yasuenag at gmail.com Sat Mar 28 04:43:23 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 28 Mar 2015 13:43:23 +0900 Subject: inlining AllocateHeap() In-Reply-To: <5506277B.4000902@oracle.com> References: <5506277B.4000902@oracle.com> Message-ID: <5516316B.6000100@gmail.com> Sorry for the delay. I filed it to JBS and uploaded webrev: JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/ Could you review it? > Yasumasa you will need to file a CR and you will need a sponsor to push > your changeset through JPRT once you have created it. I can do the > latter, just email me the final changeset directly. Thanks, David. I'll send it to you after reviewing. Yasumasa On 2015?03?16? 09:44, David Holmes wrote: > On 14/03/2015 9:29 AM, Coleen Phillimore wrote: >> >> There are other inline and noinline directives in allocation.hpp. We >> always assume that AllocateHeap and others are inlined. NMT is touchy >> with respect to how it walks the stack and it took a bit of work and >> testing to get just the most useful frames saved. I don't really want >> to risk this breaking! >> >> I think the gcc directive is acceptable in this case. > > Okay I'll follow Coleen's guidance on this. The original patch is fine. > > Yasumasa you will need to file a CR and you will need a sponsor to push > your changeset through JPRT once you have created it. I can do the > latter, just email me the final changeset directly. > > Thanks, > David > >> Coleen >> >> >> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >>> Hi, >>> >>>> That would require more significant changes to NMT I think >>> >>> I think two changes: >>> >>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >>> >>> I think that caller of AllocateHeap() and ReallocateHeap() should >>> give >>> PC to them. >>> However, it is significant changes. >>> Thus I proposed to add always_inline . >>> >>> >>>> I don't see how it will help if you have to know a-priori whether >>>> inlining has occurred or not. ?? >>> >>> I think we can use SA. >>> In case of Linux, >>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >>> can lookup symbol from target process - we can check whether the >>> function has been >>> inlined (cannot lookup) or not (can lookup). >>> So I think that we can write jtreg testcase. >>> >>> BTW, should I file it to JBS? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/03/13 17:35, David Holmes wrote: >>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>>> Hi Yasumasa, David, >>>>> >>>>> Maybe it would make sense to make the >>>>> number-of-frames-to-skip-parameter >>>>> configurable? >>>> >>>> That would require more significant changes to NMT I think - plus I >>>> don't see how it will help if you have to know a-priori whether >>>> inlining has occurred or not. ?? >>>> >>>> Thanks, >>>> David >>>> >>>>> Because the direct caller of AllocateHeap or os::malloc may also >>>>> not be >>>>> interesting but still a generic wrapper. So, the user doing the >>>>> allocation trace could finetune this parameter to fit his needs. >>>>> >>>>> Thomas >>>>> >>>>> >>>>> >>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>> oracle.com >>>>> > wrote: >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I tried to use NMT with details option on OpenJDK7 on >>>>> RHEL6.6, >>>>> but I got >>>>> address at AllocateHeap() as malloc() caller. >>>>> >>>>> I checked symbol in libjvm.so in >>>>> OracleJDK8u40 Linux >>>>> x64, it has AllocateHeap() >>>>> symbol. >>>>> >>>>> AllocateHeap() is defined as inline function, and it gives >>>>> CURRENT_PC to >>>>> os::malloc(). I guess that implementation expects >>>>> AllocateHeap() >>>>> will be >>>>> inlined. >>>>> >>>>> >>>>> It seems so. >>>>> >>>>> It may occur with GCC (g++) optimization only, however I >>>>> want to >>>>> fix it to >>>>> analyze native memory with NMT on Linux. >>>>> >>>>> >>>>> According to the docs [1]: >>>>> >>>>> "GCC does not inline any functions when not optimizing unless >>>>> you >>>>> specify the ?always_inline? attribute for the function" >>>>> >>>>> I applied patch as below. This patch makes AllocateHeap() >>>>> as >>>>> inline >>>>> function. >>>>> -------------- >>>>> diff -r af3b0db91659 >>>>> src/share/vm/memory/__allocation.inline.hpp >>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar >>>>> 09 >>>>> 09:30:16 2015 >>>>> -0700 >>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar >>>>> 12 >>>>> 20:45:57 2015 >>>>> +0900 >>>>> @@ -62,11 +62,18 @@ >>>>> } >>>>> return p; >>>>> } >>>>> + >>>>> +#ifdef __GNUC__ >>>>> +__attribute__((always_inline)__) >>>>> +#endif >>>>> >>>>> >>>>> I dislike seeing the gcc specific directives in common code. >>>>> I'm >>>>> wondering whether we should perhaps only use CURRENT_PC in >>>>> product >>>>> (and optimized?) builds and use CALLER_PC otherwise. That would >>>>> be >>>>> imperfect of course It also makes me wonder whether the >>>>> inlining is >>>>> occurring as expected on other platforms. >>>>> >>>>> I'd like to get other people's views on this. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>>> >>>>> >>>>> >>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>>> AllocFailType alloc_failmode = >>>>> AllocFailStrategy::EXIT_OOM) { >>>>> return AllocateHeap(size, flags, CURRENT_PC, >>>>> alloc_failmode); >>>>> } >>>>> >>>>> +#ifdef __GNUC__ >>>>> +__attribute__((always_inline)__) >>>>> +#endif >>>>> inline char* ReallocateHeap(char *old, size_t size, >>>>> MEMFLAGS >>>>> flag, >>>>> AllocFailType alloc_failmode = >>>>> AllocFailStrategy::EXIT_OOM) { >>>>> char* p = (char*) os::realloc(old, size, flag, >>>>> CURRENT_PC); >>>>> -------------- >>>>> >>>>> If this patch is accepted, I will file it to JBS and will >>>>> upload >>>>> webrev. >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> From david.holmes at oracle.com Sun Mar 29 20:44:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Mar 2015 06:44:57 +1000 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <5515086B.7050907@oracle.com> References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com> Message-ID: <55186449.4050606@oracle.com> On 27/03/2015 5:36 PM, cheleswer sahu wrote: > Hi, > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 > with fix successfully. As I do not have account for OpenJDK, David Buck > will push > the fix into jdk9/hs-rt/. > > Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ Is it possible to include information about where the class was loaded from in the message that precedes the exit: 121 tty->print_cr("Invalid layout of %s at %s", ik->external_name(), name_symbol->as_C_string()); The main cause of this problem is android.jar on the bootclasspath. It would be good to make that explicit as well. Otherwise we will still get bug reports because noone will know what this error means. Thanks, David > Regards, > Cheleswer > > > > From david.holmes at oracle.com Mon Mar 30 02:17:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Mar 2015 12:17:34 +1000 Subject: RFR 8076212: AllocateHeap() and ReallocateHeap() should be inlined. In-Reply-To: <5516316B.6000100@gmail.com> References: <5506277B.4000902@oracle.com> <5516316B.6000100@gmail.com> Message-ID: <5518B23E.3020701@oracle.com> Changing subject to reflect proper RFR. This change looks good to me. Thanks, David On 28/03/2015 2:43 PM, Yasumasa Suenaga wrote: > Sorry for the delay. > > I filed it to JBS and uploaded webrev: > > JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. > http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/ > > Could you review it? > > >> Yasumasa you will need to file a CR and you will need a sponsor to push >> your changeset through JPRT once you have created it. I can do the >> latter, just email me the final changeset directly. > > Thanks, David. > I'll send it to you after reviewing. > > > Yasumasa > > > On 2015?03?16? 09:44, David Holmes wrote: >> On 14/03/2015 9:29 AM, Coleen Phillimore wrote: >>> >>> There are other inline and noinline directives in allocation.hpp. We >>> always assume that AllocateHeap and others are inlined. NMT is touchy >>> with respect to how it walks the stack and it took a bit of work and >>> testing to get just the most useful frames saved. I don't really want >>> to risk this breaking! >>> >>> I think the gcc directive is acceptable in this case. >> >> Okay I'll follow Coleen's guidance on this. The original patch is fine. >> >> Yasumasa you will need to file a CR and you will need a sponsor to push >> your changeset through JPRT once you have created it. I can do the >> latter, just email me the final changeset directly. >> >> Thanks, >> David >> >>> Coleen >>> >>> >>> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>>> That would require more significant changes to NMT I think >>>> >>>> I think two changes: >>>> >>>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >>>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >>>> >>>> I think that caller of AllocateHeap() and ReallocateHeap() should >>>> give >>>> PC to them. >>>> However, it is significant changes. >>>> Thus I proposed to add always_inline . >>>> >>>> >>>>> I don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>> >>>> I think we can use SA. >>>> In case of Linux, >>>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >>>> can lookup symbol from target process - we can check whether the >>>> function has been >>>> inlined (cannot lookup) or not (can lookup). >>>> So I think that we can write jtreg testcase. >>>> >>>> BTW, should I file it to JBS? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/03/13 17:35, David Holmes wrote: >>>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>>>> Hi Yasumasa, David, >>>>>> >>>>>> Maybe it would make sense to make the >>>>>> number-of-frames-to-skip-parameter >>>>>> configurable? >>>>> >>>>> That would require more significant changes to NMT I think - plus I >>>>> don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Because the direct caller of AllocateHeap or os::malloc may also >>>>>> not be >>>>>> interesting but still a generic wrapper. So, the user doing the >>>>>> allocation trace could finetune this parameter to fit his needs. >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>>> oracle.com >>>>>> > wrote: >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I tried to use NMT with details option on OpenJDK7 on >>>>>> RHEL6.6, >>>>>> but I got >>>>>> address at AllocateHeap() as malloc() caller. >>>>>> >>>>>> I checked symbol in libjvm.so in >>>>>> OracleJDK8u40 Linux >>>>>> x64, it has AllocateHeap() >>>>>> symbol. >>>>>> >>>>>> AllocateHeap() is defined as inline function, and it gives >>>>>> CURRENT_PC to >>>>>> os::malloc(). I guess that implementation expects >>>>>> AllocateHeap() >>>>>> will be >>>>>> inlined. >>>>>> >>>>>> >>>>>> It seems so. >>>>>> >>>>>> It may occur with GCC (g++) optimization only, however I >>>>>> want to >>>>>> fix it to >>>>>> analyze native memory with NMT on Linux. >>>>>> >>>>>> >>>>>> According to the docs [1]: >>>>>> >>>>>> "GCC does not inline any functions when not optimizing unless >>>>>> you >>>>>> specify the ?always_inline? attribute for the function" >>>>>> >>>>>> I applied patch as below. This patch makes AllocateHeap() >>>>>> as >>>>>> inline >>>>>> function. >>>>>> -------------- >>>>>> diff -r af3b0db91659 >>>>>> src/share/vm/memory/__allocation.inline.hpp >>>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar >>>>>> 09 >>>>>> 09:30:16 2015 >>>>>> -0700 >>>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar >>>>>> 12 >>>>>> 20:45:57 2015 >>>>>> +0900 >>>>>> @@ -62,11 +62,18 @@ >>>>>> } >>>>>> return p; >>>>>> } >>>>>> + >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> >>>>>> >>>>>> I dislike seeing the gcc specific directives in common code. >>>>>> I'm >>>>>> wondering whether we should perhaps only use CURRENT_PC in >>>>>> product >>>>>> (and optimized?) builds and use CALLER_PC otherwise. That would >>>>>> be >>>>>> imperfect of course It also makes me wonder whether the >>>>>> inlining is >>>>>> occurring as expected on other platforms. >>>>>> >>>>>> I'd like to get other people's views on this. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>>>> >>>>>> >>>>>> >>>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> return AllocateHeap(size, flags, CURRENT_PC, >>>>>> alloc_failmode); >>>>>> } >>>>>> >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> inline char* ReallocateHeap(char *old, size_t size, >>>>>> MEMFLAGS >>>>>> flag, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> char* p = (char*) os::realloc(old, size, flag, >>>>>> CURRENT_PC); >>>>>> -------------- >>>>>> >>>>>> If this patch is accepted, I will file it to JBS and will >>>>>> upload >>>>>> webrev. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> From staffan.larsen at oracle.com Mon Mar 30 08:34:58 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Mar 2015 10:34:58 +0200 Subject: RFR 8023093: Add ManagementAgent.status diagnostic command In-Reply-To: <5515857E.9080902@oracle.com> References: <5515857E.9080902@oracle.com> Message-ID: <8E71E422-8372-455F-93E0-27ED36BCBE3B@oracle.com> Looks good! Thanks for splitting up the test file. This test has been known to be unstable - what platforms have you verified the changes on? Thanks, /Staffan > On 27 mar 2015, at 17:29, Jaroslav Bachorik wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8023093 > Webrev: http://cr.openjdk.java.net/~jbachorik/8023093/webrev.00 (hotspot, jdk) > > This change adds a new 'ManagementAgent.status' diagnostic command. This command will output the current status of the management agent in the following format > > ``` > Agent: > > ( > ConnectionType: > Protocol: > Host: > URL: > > ( > Properties: > ( > = > )+ > )? > )+ > ``` > > Where: > means an arbitrary value > | means 'or' > ( and ) denote a block > + block repeats one or more times > ? block appears at most once > > A new test is added exercising this diagnostic command. While adding the test I factored out the shared functionality from the JMXStartStopTest class and caused the changes in the test area to be a bit more extensive than just adding a new test class. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Mar 30 10:47:49 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 30 Mar 2015 12:47:49 +0200 Subject: RFR 8023093: Add ManagementAgent.status diagnostic command In-Reply-To: <8E71E422-8372-455F-93E0-27ED36BCBE3B@oracle.com> References: <5515857E.9080902@oracle.com> <8E71E422-8372-455F-93E0-27ED36BCBE3B@oracle.com> Message-ID: <551929D5.2060509@oracle.com> On 30.3.2015 10:34, Staffan Larsen wrote: > Looks good! > > Thanks for splitting up the test file. This test has been known to be unstable - what platforms have you verified the changes on? I ran the tests on all the available platforms in JPRT. So far so good. -JB- > > Thanks, > /Staffan > >> On 27 mar 2015, at 17:29, Jaroslav Bachorik wrote: >> >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8023093 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8023093/webrev.00 (hotspot, jdk) >> >> This change adds a new 'ManagementAgent.status' diagnostic command. This command will output the current status of the management agent in the following format >> >> ``` >> Agent: >> >> ( >> ConnectionType: >> Protocol: >> Host: >> URL: >> >> ( >> Properties: >> ( >> = >> )+ >> )? >> )+ >> ``` >> >> Where: >> means an arbitrary value >> | means 'or' >> ( and ) denote a block >> + block repeats one or more times >> ? block appears at most once >> >> A new test is added exercising this diagnostic command. While adding the test I factored out the shared functionality from the JMXStartStopTest class and caused the changes in the test area to be a bit more extensive than just adding a new test class. >> >> Thanks, >> >> -JB- > From shanliang.jiang at oracle.com Tue Mar 31 16:39:25 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 31 Mar 2015 18:39:25 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management Message-ID: <551ACDBD.6000703@oracle.com> Please review this fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ Some code within the module java.management is separated and moved to the new module jdk.management, the new module takes the implementation code for Oracle Corporation's platform extension to the implementation of the java.lang.management API and also the management interface for some other components for the platform. Thanks, Shanliang