Fwd: Re: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
Max Ockner
max.ockner at oracle.com
Thu Jan 28 19:29:02 UTC 2016
Forwarded private discussion with Ioi about changing the test to use
ClassUnloadCommon.
Hopefully nearing the end:
Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
-------- Original Message --------
Subject: Re: RFR: 8079408: Reimplement TraceClassLoading,
TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
Date: Thu, 28 Jan 2016 10:57:15 -0800
From: Ioi Lam <ioi.lam at oracle.com>
To: Max Ockner <max.ockner at oracle.com>
Hi Max,
Thanks for doing this. Also, I sent the e-mail to you personally, so you
may want to post the new version in the open list for record purpose.
Thanks
- Ioi
On 1/28/16 8:11 AM, Max Ockner wrote:
> Ioi,
> I have replaced my test with this test that you have given me (thank
> you!)
> I also have removed the commented out section which used to test for
> "making nmethod ...", and I have added the comment that you suggested
> at the top of ClassUnloadCommon.java
> Thanks,
> Max
> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>
>>
>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>> 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.
>>>
>>
>> Hi Max,
>>
>> I've written a version of ClassLoadUnloadTest.java using
>> ClassUnloadCommon. The main trick is here:
>>
>> Collections.addAll(argsList, "-Dtest.classes=" +
>> System.getProperty("test.classes","."));
>>
>> That's because of this line in ClassUnloadCommon:
>>
>> return new URLClassLoader(new URL[] {
>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar
>> + "classes").toUri().toURL(),
>> }, null);
>>
>> When Jtreg launches a sub-process, it strips off all the Java system
>> properties, so you need to add the "-D" in the command-line.
>>
>> I also disabled the test related to "making nmethod ... unloadable".
>> As Rachel found out in JDK-8146137, the compiler is unpredictable.
>> Even if you invoke a method 10001 times, there's no guaranteed that
>> it will always be compiled. Since this is not an 'easy-to-test'
>> feature, we should just skip it.
>>
>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>
>> /*
>> * To use ClassUnloadCommon from a sub-process, see
>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>> * for an example.
>> */
>>
>> What do you think?
>> - Ioi
>
More information about the hotspot-runtime-dev
mailing list