Pls (re)review 6173675/7003271: per-thread memory allocation measurement
Paul Hohensee
paul.hohensee at oracle.com
Wed Jan 12 00:55:09 PST 2011
I filed 7011788 for this.
Paul
On 1/10/11 2:29 AM, Paul Hohensee wrote:
> I'll file a CR.
>
> Thanks for your review!
>
> Pul
>
> On 1/10/11 2:01 AM, David Holmes wrote:
>> Paul Hohensee said the following on 01/10/11 16:42:
>>> My bad on the 7003271 webrev. It's already pushed. The only one to
>>> review is 6173675.
>>>
>>> I replaced initialLongArray with java.util.Arrays.fill.
>>>
>>> I took the code for ThreadCpuTimeArray.java from
>> test/java/lang/management/
>>> ThreadCpuTime.java. The check for DELTA was in that code, so I kept
>>> it. Same with the argument of 200 to goSleep(). I'm assuming that the
>>> same logic works, and it appears to do so. I can, though, change it
>>> to be like the code in ThreadAllocatedMemoryArray.java.
>>
>> I'd say both tests using the DELTA are equally dubious, but I'd need
>> to know what the intent of that check was. If it was to see if the
>> cpu time advanced by an expected amount then a better test would be
>> for each thread to measure elapsed time around doit() and then have
>> the main thread check that the elapsed CPU time is <= the measured
>> elapsed time. (Some of the JVMTI test do similar comparisons).
>>
>> That said, given you are emulating existing tests that appear to work
>> I won't push for you to re-write them :) But we should have a CR to
>> either change them or at least make the DELTA a configurable value. I
>> can easily imagine that these tests will fail on some of our internal
>> platforms.
>>
>> Cheers,
>> David
>>
>>>
>>> Paul
>>>
>>> On 1/9/11 9:17 PM, David Holmes wrote:
>>>> Hi Paul,
>>>>
>>>> Partial re-review :)
>>>>
>>>> Paul Hohensee said the following on 01/10/11 11:10:
>>>>> Thanks to all who reviewed the previous webrev. Revised versions
>>>>> are here
>>>>>
>>>>> http://cr.openjdk.java.net/~phh/6173675/webrev.02/
>>>>
>>>> In ThreadImpl.java you could replace:
>>>>
>>>> long[] times = initialLongArray(length, -1);
>>>>
>>>> with
>>>>
>>>> long[] times = java.util.Arrays.fill(new long[length], -1);
>>>>
>>>> and delete initialLongArray.
>>>>
>>>>
>>>> In test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java
>>>>
>>>> I don't understand the test logic. Your tests threads all do:
>>>>
>>>> doit();
>>>> while (!done) wait
>>>> doit();
>>>>
>>>> but the main thread doesn't check any times etc after setting
>>>> done=true, so why have the test threads do the second call to doit?
>>>> For that matter why even bother with doit()? It only delays the
>>>> threads in getting to the wait(), which is what the main thread
>>>> itself waits for.
>>>>
>>>> 111 goSleep(200);
>>>>
>>>> What does 200 represent? What is it that you are actually waiting
>>>> for? Is 200 long enough on a slow uniprocessor?
>>>>
>>>> 141 if ((times[i] + DELTA) < newTime) {
>>>> 142 throw new RuntimeException("TEST FAILED: " +
>>>>
>>>> Again what does DELTA represent, how can you be sure the times for
>>>> all threads will have advanced this much?
>>>>
>>>>
>>>>> http://cr.openjdk.java.net/~phh/7003271/webrev.02/
>>>>
>>>> All files listed have zero changes ???
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>> The interesting changes are in the library side for 6173675. In
>>>>> particular,
>>>>> I've added 3 unit tests.
>>>>>
>>>>> Thanks for any review,
>>>>>
>>>>> Paul
>>>>>
More information about the serviceability-dev
mailing list