[10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor
Yasumasa Suenaga
yasuenag at gmail.com
Mon Aug 7 04:02:27 UTC 2017
Hi David,
I uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8185164/webrev.04/
2017-08-07 11:23 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> On 7/08/2017 10:33 AM, Yasumasa Suenaga wrote:
>>
>> Hi Dan,
>>
>>>> * GetOwnedMonitorInfoTest.java
>>>> - I use Thread#yield() to wait until MonitorContendedEnter event
>>>> is
>>>> fired.
>>>
>>>
>>> Please switch back to a small Thread.sleep(). Thread.yield()
>>> can be a no-op on some platforms which will make the wait
>>> loop very hot.
>>
>>
>> I fixed it in new webrev:
>>
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185164/webrev.03/
>
>
> I have one concern with the test. Are you certain that the only possible
> contended-enter event can come from the attempt to lock the
> GetOwnedMonitorInfoTest.class object? Something from -Xcomp perhaps? The
> test would likely still pass, but it would be checking the "wrong" event.
I guess you mean other place (e.g. in class library) might generate
MonitorContendedEnter event.
So I check the class of monitor object in JNI test module.
> A few nits in the test
>
> GetOwnedMonitorInfoTest.java:
>
> Should have @bug 8185164
Added.
> --
>
> 27 * @summary Verifies the JVMTI GetOwnedMonitorInfo API
>
> That's a bit of an overstatement - this only verifies that a contended
> monitor does not show up in the set of owned monitors. (Even that is
> somewhat inaccurate)
I modified the summary, but I'm not good at English.
So please tell me if it is incorrect :-)
> --
>
> Style-nit:
>
> 35 public class GetOwnedMonitorInfoTest implements Runnable {
>
> There is no need to implement Runnable and provide the run() method as an
> instance method of the class because there is no state. The simpler
> construct would be to define an anonymous inner class when creating the
> thread:
>
> Thread t1 = new Thread() {
> public void run() {
> synchronized (GetOwnedMonitorInfoTest.class) {
> System.out.println("Thread in sync section: " + name);
> }
> }
> };
Fixed (I use lambda expression in new webrev.)
> --
>
> Style-nit:
>
> 42 System.err.println("java.library.path: "
> 43 + System.getProperty("java.library.path"));
>
> line continuation should indent to align after ( i.e.
>
> System.err.println("java.library.path: "
> + System.getProperty("java.library.path"));
Fixed.
> --
>
> Style-nit:
>
> 48 native static int check();
> 49 native static boolean hasEventPosted();
>
> modifier order should be "static native". They could/should also be private.
Fixed.
> --
>
> Style-nit:
>
> 53 try {
> 54 synchronized (GetOwnedMonitorInfoTest.class) {
> 55 System.out.println("Thread in sync section: " + name);
> 56 }
> 57 } catch (Exception e) {
> 58 e.printStackTrace();
> 59 }
>
> There is no need for a try-catch here as no Exceptions (other than
> RuntimeExceptions) are possible, and the default exception handler will take
> care of printing the stacktrace regardless.
Fixed.
> --
>
> Style-nit:
>
> 79 int status = check();
> 80 if (status != 0) {
>
> No need for local variable as it's only used once.
Fixed.
> ---
>
> libGetOwnedMonitorInfoTest.c
>
> Style-nit:
>
> 50 static volatile jboolean event_has_posted = JNI_FALSE;
>
> double-space after jboolean
Fixed.
> --
>
> Query:
>
> 64 fprintf(stderr, "MonitorContendedEnter: error in JVMTI
> GetThreadInfo: %d\n", err);
>
> do we not have anything to print out a more meaningful error message that
> the integer value of the JVMTI error code?
I added ShowErrorMessage() to show JVMTI error message.
It uses GetErrorName() JVMTI function.
> --
>
> Style query: do we do indent of 2 or 4 in hotspot C code tests ?
Fixed in C code.
Thanks,
Yasumasa
> Thanks,
> David
> ------
>
>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> 2017-08-06 23:54 GMT+09:00 Daniel D. Daugherty
>> <daniel.daugherty at oracle.com>:
>>>
>>> On 8/6/17 1:28 AM, Yasumasa Suenaga wrote:
>>>>
>>>>
>>>> Hi Dan, Serguei,
>>>>
>>>> Thanks Serguei! I can run new testcase on my environment.
>>>>
>>>> Dan, I modified your patch and uploaded as webrev:
>>>>
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185164/webrev.02/
>>>>
>>>>
>>>> * GetOwnedMonitorInfoTest.java
>>>> - I use Thread#yield() to wait until MonitorContendedEnter event
>>>> is
>>>> fired.
>>>
>>>
>>>
>>> Please switch back to a small Thread.sleep(). Thread.yield()
>>> can be a no-op on some platforms which will make the wait
>>> loop very hot.
>>>
>>>
>>>> * libGetOwnedMonitorInfoTest.c
>>>> - I added "volatile" to "status" variable.
>>>
>>>
>>>
>>> Sorry I missed that one.
>>>
>>>
>>>> - I moved "event_has_posted = JNI_TRUE" to each before return
>>>> statement.
>>>
>>>
>>>
>>> Good catch. My original setting of event_has_posted had
>>> a narrow race.
>>>
>>> I'm good on the changes. I'll have test results later today.
>>>
>>> Dan
>>>
>>>
>>>
>>>>
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2017/08/06 11:33, Daniel D. Daugherty wrote:
>>>>>
>>>>>
>>>>> Hi Yasumasa and Serguei,
>>>>>
>>>>> I've made some tweaks to the test and attached an updated patch:
>>>>>
>>>>> GetOwnedMonitorInfoTest.java changes:
>>>>>
>>>>> - deleted thread 't2'
>>>>> - made changes to make monitor contention not racy:
>>>>> - added 'hasEventPosted()' native function
>>>>> - changed Main to grab the GetOwnedMonitorInfoTest.class monitor
>>>>> before launching 't1'
>>>>> - added loop to check hasEventPosted() function while holding
>>>>> the GetOwnedMonitorInfoTest.class monitor
>>>>> - moved the delay to this new loop
>>>>>
>>>>> libGetOwnedMonitorInfoTest.c changes:
>>>>>
>>>>> - added event_has_posted flag to know when MonitorContendedEnter
>>>>> event has been posted
>>>>> - added missing error checks to JVM/TI functions
>>>>> - print an error message when MonitorContendedEnter or
>>>>> MonitorContendedEntered gets an incorrect monitor count
>>>>> - print error and warnings to 'stderr'
>>>>> - add Java_GetOwnedMonitorInfoTest_hasEventPosted function
>>>>>
>>>>> I've tested the latest version of test in a repo without the fix
>>>>> and it fails (as expected). Here's some sample output:
>>>>>
>>>>> ----------System.out:(7/231)----------
>>>>> Agent_OnLoad started
>>>>> Agent_OnLoad finished
>>>>> Main starting worker thread.
>>>>> Main waiting for event.
>>>>> Thread in sync section: Thread-1
>>>>> MonitorContendedEnter: Thread-1 owns 1 monitor(s)
>>>>> MonitorContendedEntered: Thread-1 owns 1 monitor(s)
>>>>> ----------System.err:(14/931)----------
>>>>> MonitorContendedEnter: FAIL: monitorCount should be zero.
>>>>> java.lang.RuntimeException: FAILED status returned from the agent
>>>>> at
>>>>> GetOwnedMonitorInfoTest.main(GetOwnedMonitorInfoTest.java:81)
>>>>> at
>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>> Method)
>>>>> at
>>>>>
>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>> at
>>>>>
>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>>>>> at
>>>>>
>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
>>>>> at java.base/java.lang.Thread.run(Thread.java:844)
>>>>>
>>>>> JavaTest Message: Test threw exception: java.lang.RuntimeException:
>>>>> FAILED status returned from the agent
>>>>> JavaTest Message: shutting down test
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 8/5/17 12:37 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>
>>>>>>
>>>>>> Hi Yasumasa,
>>>>>>
>>>>>> I use the following script to run the test on linux:
>>>>>>
>>>>>> % cat run.sh
>>>>>> #!/bin/sh
>>>>>> REPO=<my_repo>
>>>>>> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images
>>>>>> export JAVA_HOME=${IMAGES}/jdk
>>>>>> export LD_LIBRARY_PATH=${IMAGES}/test/hotspot/jtreg/native
>>>>>>
>>>>>> jtreg -J-Dtest.java.opts='-server' \
>>>>>> -jdk ${JAVA_HOME} \
>>>>>> -nativepath:${LD_LIBRARY_PATH} \
>>>>>> $REPO/hotspot/test/serviceability/jvmti/GetOwnedMonitorInfo
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>>
>>>>>> On 8/5/17 06:31, Yasumasa Suenaga wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Serguei,
>>>>>>>
>>>>>>> I uploaded new webrev:
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185164/webrev.01/
>>>>>>>
>>>>>>> I tried to run serviceability/jvmti/GetOwnedMonitorInfo but it is
>>>>>>> failed because jtreg needs -nativepath option.
>>>>>>> But I didn't know what path should I set to -nativepath.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>> On 2017/08/05 20:20, serguei.spitsyn at oracle.com wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Yasumasa,
>>>>>>>>
>>>>>>>> Please, merge the converted testcase.
>>>>>>>> It still might need more tweaks though.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/5/17 03:18, Yasumasa Suenaga wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Serguei,
>>>>>>>>>
>>>>>>>>> Thank you so much!
>>>>>>>>> Should I merge your testcase? Or can you push this change?
>>>>>>>>>
>>>>>>>>> I agree to your change as a reviewer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yasumasa
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2017/08/05 11:34, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The updated patch attached.
>>>>>>>>>> Now the test is passed with the suggested fix and failed without
>>>>>>>>>> it.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Serguei
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 8/4/17 15:45, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 8/4/17 14:26, Daniel D. Daugherty wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/4/17 3:17 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The patch is attached.
>>>>>>>>>>>>> It may need some tweaks though.
>>>>>>>>>>>>> I was not able to make it fail yet.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think the original test had "failure" detection.
>>>>>>>>>>>> You were just supposed to notice that a pending monitor
>>>>>>>>>>>> was listed under the wrong list.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nothing is listed.
>>>>>>>>>>> Strange thing is I do not see the monitor events fired.
>>>>>>>>>>> I'm using 10 for testing.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Serguei
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/4/17 12:45, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks Serguei!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I happen to be doing a test run this weekend that includes
>>>>>>>>>>>>>> most
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> JPDA stack of tests so I'll include the following in my
>>>>>>>>>>>>>> experiment:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> $ hg log -v -r tip
>>>>>>>>>>>>>> changeset: 12872:bb66cd7c61b1
>>>>>>>>>>>>>> tag: 8185164.patch
>>>>>>>>>>>>>> tag: qtip
>>>>>>>>>>>>>> tag: tip
>>>>>>>>>>>>>> user: dcubed
>>>>>>>>>>>>>> date: Fri Aug 04 13:41:29 2017 -0600
>>>>>>>>>>>>>> files: src/share/vm/runtime/objectMonitor.cpp
>>>>>>>>>>>>>> description:
>>>>>>>>>>>>>> imported patch 8185164.patch
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That will get the product code changes a complete round of
>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>> on Solaris X64 at least... :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Great!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Serguei
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/4/17 1:31 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you for letting me know about this discussion.
>>>>>>>>>>>>>>> I'll try to convert the attached test case to the JTreg
>>>>>>>>>>>>>>> format.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Serguei
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 8/4/17 11:16, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Adding Serguei to this thread directly since he's back from
>>>>>>>>>>>>>>>> vacation!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/31/17 10:14 PM, David Holmes wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 26/07/2017 11:52 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/26/17 12:11 AM, David Holmes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 26/07/2017 10:27 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've added some analysis to the bug report
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>> I tried to fix this issue in
>>>>>>>>>>>>>>>>>>>> JvmtiEnvBase::get_owned_monitors() at first.
>>>>>>>>>>>>>>>>>>>> But it is difficult because we cannot know pending
>>>>>>>>>>>>>>>>>>>> monitor
>>>>>>>>>>>>>>>>>>>> if thread state is MONITOR_CONTENDED_ENTER when
>>>>>>>>>>>>>>>>>>>> get_owned_monitor() is
>>>>>>>>>>>>>>>>>>>> called.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I need to look closer at this when I get back from
>>>>>>>>>>>>>>>>>>> vacation
>>>>>>>>>>>>>>>>>>> next week.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Seems like you're back already. :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A pending monitor should not be reported as owned (unless
>>>>>>>>>>>>>>>>>>> the spec says otherwise) and it seems odd to me to fix
>>>>>>>>>>>>>>>>>>> the current problem
>>>>>>>>>>>>>>>>>>> by marking the monitor as pending earlier.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It's the updating of the _current_pending_monitor field
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> allows JvmtiEnvBase::get_locked_objects_in_frame() to
>>>>>>>>>>>>>>>>>> recognize
>>>>>>>>>>>>>>>>>> that the monitor observed in the frame is only pending and
>>>>>>>>>>>>>>>>>> is not owned.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I put a fairly detailed note in the bug yesterday, but you
>>>>>>>>>>>>>>>>>> should look at that when you're officially back!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for clarifying things. I also added a comment to the
>>>>>>>>>>>>>>>>> bug report.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think the fix is sound and prevents anyone from observing
>>>>>>>>>>>>>>>>> the case where the monitor will be seen in the stack-frame,
>>>>>>>>>>>>>>>>> but has not yet
>>>>>>>>>>>>>>>>> been set as the "pending monitor". As far as I can tell it
>>>>>>>>>>>>>>>>> is only this case
>>>>>>>>>>>>>>>>> (GetOwnedMonitorInfo from the contended-monitor event
>>>>>>>>>>>>>>>>> callback in the
>>>>>>>>>>>>>>>>> current thread) that will be able to observe the change.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One scenario that I worry about here is that a
>>>>>>>>>>>>>>>> GetCurrentContendedMonitor()
>>>>>>>>>>>>>>>> call on a target thread will now be able to return a
>>>>>>>>>>>>>>>> non-NULL
>>>>>>>>>>>>>>>> value for the
>>>>>>>>>>>>>>>> object, when GetThreadState() will be able to return
>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>> other than
>>>>>>>>>>>>>>>> blocked (on monitor enter) for the thread.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't see anything in the JVM/TI spec that says such a
>>>>>>>>>>>>>>>> scenario is
>>>>>>>>>>>>>>>> wrong; I'm only worried about whether we have any tests that
>>>>>>>>>>>>>>>> would catch
>>>>>>>>>>>>>>>> this slight change in behavior. In any case, one of these
>>>>>>>>>>>>>>>> operations has
>>>>>>>>>>>>>>>> to "happen first":
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - thread is marked as blocked
>>>>>>>>>>>>>>>> - monitor is flagged as contended
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Currently, they happen in the above order and the fix
>>>>>>>>>>>>>>>> proposes
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> change the order and I see no reason not to do it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would like the test attached to the bug to be converted
>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>> a native
>>>>>>>>>>>>>>>> JTREG test that lives in hotspot/test/serviceability/jvmti.
>>>>>>>>>>>>>>>> See the
>>>>>>>>>>>>>>>> following test as a possible example:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hotspot/test/serviceability/jvmti/GetNamedModule
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> for how to do this... I haven't done one of these new native
>>>>>>>>>>>>>>>> JTREG
>>>>>>>>>>>>>>>> tests myself, but I believe Serguei has...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Did you run the jdk repo's com/sun/jdi tests with your
>>>>>>>>>>>>>>>>>>>>> fix?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I have not done yet.
>>>>>>>>>>>>>>>>>>>> I have a trip until 28 July JST. So I will run it after
>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 2017/07/26 7:05, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 7/24/17 8:40 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I tried to get owned monitors in MonitorContendedEnter
>>>>>>>>>>>>>>>>>>>>>> JVMTI event handler.
>>>>>>>>>>>>>>>>>>>>>> However GetOwnedMonitorInfo JVMTI function returns a
>>>>>>>>>>>>>>>>>>>>>> monitor which is
>>>>>>>>>>>>>>>>>>>>>> not yet owned.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I attached reproducer to JBS. Please read README.md.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I think GetOwnedMonitorInfo() should not return a
>>>>>>>>>>>>>>>>>>>>>> pending monitor.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I uploaded webrev. Could you review?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185164/webrev.00/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I hope this fix is applied to 8u or later release.
>>>>>>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks for the bug report. It's nice to have a test
>>>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>>>> and a proposed
>>>>>>>>>>>>>>>>>>>>> fix all in the bug report! I've added some analysis to
>>>>>>>>>>>>>>>>>>>>> the bug report
>>>>>>>>>>>>>>>>>>>>> and we'll need to run this fix through Oracle's JPDA
>>>>>>>>>>>>>>>>>>>>> test
>>>>>>>>>>>>>>>>>>>>> stack which
>>>>>>>>>>>>>>>>>>>>> is not (yet) open.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Did you run the jdk repo's com/sun/jdi tests with your
>>>>>>>>>>>>>>>>>>>>> fix?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>
More information about the serviceability-dev
mailing list