RFR: 8025692: Add trace to find out what methods are used at runtime.

Yumin Qi yumin.qi at oracle.com
Fri Jul 10 20:37:50 UTC 2015


Thanks, Misha

The failure of the failed 4 jobs, some of dependency error, which I 
think is dtrace, some are agent download encountered 'check sum' which I 
think is configuration problem. Still, the 4 running jobs just hang 
there and no progress --- may as you said, it is Windows problem.

Yumin

On 7/10/2015 9:33 AM, Mikhailo Seledtsov wrote:
> It is a known issue with Aurora; the RBT jobs get stuck on Win-x64.
> The fix's ETA is on 13-July during next Aurora patch deployemnt.
>
> You could still check status of testing on jobs that complete:
> - go to your main RBT status for your job (e.g. 
> http://sla03.se.oracle.com:3000/rbt/rbt-mikhailo.seledtsov-hs-rt-20150709-1543-2147)
>
> For overall status, just see the summary under "Test Failures" tab
>
> For details on particular failures, do:
>   - Under "Test Progress"-> x of Y jobs succeeded, click the "wheel" 
> symbol -> Main
>   - this will lead you to your Aurora main jobs page
>   - there, you could click "Go to batch results", see a table of new 
> failures, and look into them in detail
>
> Hope this helps,
> Misha
>
>
> On 7/9/2015 9:34 PM, Yumin Qi wrote:
>> Hi, Karen
>>
>>   Just informed you that RBT testing for quick testing seems will not 
>> get back a completed result(I have tried several times those days).
>>   After 11 hours, there still 4 jobs running:
>>
>>   26 of 34 succeeded, 4 failed, 4 still running.
>>
>>   Those running jobs already run at least 6+ hours.
>>   The 4 failed jobs are dtrace on linux-x64  which are OK, since 
>> dtrace is disabled on it.
>>
>>   Also, I added -Xint to test case, and tested with jtreg on 
>> test/runtime showed no new failures found.
>>   I am going to push the changes if you are OK with current result. 
>> Seems the testing with RBT will never come back. Updated webrev:
>>
>>   http://cr.openjdk.java.net/~minqi/8025692/webrev02/
>>
>> Thanks
>> Yumin
>>
>> On 6/18/2015 1:01 PM, Karen Kinnear wrote:
>>> Yumin,
>>>
>>> Thank you very much for the updates.And the PERM_REFCOUNT rather 
>>> than -1 :-)
>>> Looks good.
>>>
>>> Thank you for testing this -Xint. If there is an easy way to add an 
>>> -Xint line
>>> to the test that would be useful - but not critical.
>>>
>>> So I presume that the "aurora default test suites" includes:
>>> jcks, jtreg hotspot and Christian's new "quick" tests.
>>>
>>> thanks,
>>> Karen
>>>
>>> On Jun 4, 2015, at 11:12 PM, Yumin Qi wrote:
>>>
>>>> HI, All
>>>>
>>>>   After several round of codereviews and discussion, now the second 
>>>> version is at:
>>>>   http://cr.openjdk.java.net/~minqi/8025692/webrev02/
>>>>
>>>>   The flag names changed:
>>>>
>>>>   TraceMethodUsge => LogTouchedMethods
>>>>   PrintMethodUsageAtExit => PrintTouchedMethodsAtExit
>>>>
>>>>   The two flags now are diagnostic flags.
>>>>
>>>>    Also similar, there changed in related variable names.
>>>>    Also fixed a flaw which is not found during last round of 
>>>> review: append new TouchedMethodRecord to end of hash bucket list.
>>>>
>>>>   Make change to interpreter method entry  generation(for both 
>>>> native and normal) to enable build_method_counter called. This is 
>>>> necessary since if run -Xint, the call will be skipped so our code 
>>>> will be skipped so no logging for touched methods.
>>>>
>>>>   Added test case for jcmd: jcmd <pid> VM.print_touched_methods.
>>>>
>>>>   Tests: JPRT, aurora default test suites (in progress).
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> On 3/26/2015 7:34 PM, Yumin Qi wrote:
>>>>> Please review:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025692
>>>>> webrev: http://cr.openjdk.java.net/~minqi/8025692/webrev01/
>>>>>
>>>>> Summary: Add two flags to help list all java methods called in 
>>>>> runtime, this is also in product and can help CDS to rearrange 
>>>>> methods in shared archive to avoid loading infrequent methods into 
>>>>> memory.
>>>>>
>>>>> Tests: vm.runtime.quick.testlist, JPRT
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>
>



More information about the hotspot-runtime-dev mailing list