RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.

[Coleen Phillimore]

Okay, thanks!

On 1/28/16 12:23 PM, Max Ockner wrote:
>
> On 1/27/2016 9:08 PM, Coleen Phillimore wrote:
>> Hi Max,
>>
>> Overall looks good.
>>
>> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/classfile/classLoader.cpp.udiff.html 
>>
>>
>> Looks like you changed the copyright date from 2016 to 2015.
>>
> All copyright dates (in all patches) have been fixed.
>> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/memory/filemap.cpp.udiff.html 
>>
>>
>> What was the answer to this?  Why is there no logging for classload 
>> here?
> This logging is part of TraceClassPaths, and not really part of 
> TraceClassLoading. Sorry I missed this.

Okay, that's fine.

thanks,
Coleen
>>
>> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>
>>
>> You still have bool ret; declared, should be removed.
>>
> This is gone now.
>> I don't need to see another webrev if you fix, answer and fix these 
>> minor issues.
>>
>> thanks,
>> Coleen
>>
>> On 1/27/16 3:51 PM, Max Ockner wrote:
>>> Hello again,
>>> I have responded to the last round of feedback.
>>>
>>> Some of the tests affected by the new logging output have been 
>>> changed to look for the appropriate messages.
>>> Webrevs:
>>> [hotspot] http://cr.openjdk.java.net/~mockner/classload.06
>>> [jdk] http://cr.openjdk.java.net/~mockner/8079408.jdk/
>>>
>>> I have made all of the recommended changes to the source, and I have 
>>> fixed all affected tests from Dan's list. I have also fixed any test 
>>> which uses "-verbose:class" and looks for the old output from 
>>> TraceClassLoading or TraceClassUnloading.
>>>
>>> Though Ioi suggested I change my new test, I have not done that. I 
>>> was recommended to copy from runtime/ClassUnload/UnloadTest.java 
>>> instead of rolling my own test for class unloading. I mentioned that 
>>> it was tricky to make the new test work, but it was tricky because I 
>>> was trying to copy from UnloadTest.java. This test refers to a class 
>>> "test.Empty" from a "classes" library, but the new test has a 
>>> processBuilder which I think does not play nicely with the class 
>>> path for  "test.Empty". In the end it was much easier to hardcode 
>>> the entire test into one place than to follow UnloadTest.java and 
>>> refer to extra libraries.
>>>
>>> Thanks,
>>> Max
>>
>