RFR (XS) 8202360: [TESTBUG] runtime/LoadClass/TestResize.java needs to print output when it fails

[David Holmes]

Hi Gerard,

This has really become far too much work for what the intent of the bug 
report was. Sorry.

On 24/05/2018 5:29 AM, Gerard Ziemski wrote:
> hi David,
> 
>> On May 21, 2018, at 5:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Gerard,
>>
>> <trimming>
>>
>> On 22/05/2018 6:57 AM, Gerard Ziemski wrote:
>>>> On May 20, 2018, at 8:38 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> Okay - that helps with the immediate problem I had. I also now realize that the failure in this test is showing is that the SD did not in fact re-size as expected!
>>> Can you elaborate? Is there a reproducible case I can try to run?
>>
>> The test's purpose is to check that the SD resizes, so if it finds a load factor too high (which indicates it didn't resize) then the SD resizing logic has either not worked as expected, or the test is not doing what it thinks!
> 
> The resizing is called during a safe point, which we try to trigger by issuing a System.gc() call (in TriggerResize.java). If no safe point takes place, then no resize had chance to occur, and we have test failure, which is probably what you experienced.
> 
> I changed the test to look for safe points in the output and check the load factor only when resizing had the chance to occur.

I'm losing confidence in what this test actually tests. For GC's that 
ignore explicit GC requests via System.gc() this test is never going to 
test anything e.g. using default G1 GC.

> 
>>> I have re-done the main logic a bit to simplify it, and not have to do either String and “+” nor StringBuffer, by taking advantage of the fact that the info we need to parse is on the 2nd output line.
>>
>> I was under the impression that we could see multiple lines of the form:
>>
>> Java dictionary (table_size=40423, classes=50002)
>>
>> as the table resized. If that is not the case then none of the output seems relevant to me except for this one line. ??
> 
> That print out comes from PrintSystemDictionaryAtExit, which happens only once at the exit, but there is more then one system dictionary, and all of them are checked.

But now I understand all that, the dumping of all the output really 
doesn't help in establishing why the test failed. My original request 
was for more information to see why the load factor was too high. I 
thought, incorrectly, that we would see a series of changing 
size+classes reports until we suddenly hit a bad load factor. But that 
isn't the case. All that was missing in the end were the actual 
table_size and classes values that caused the error. Nothing more, 
nothing less.

> https://bugs.openjdk.java.net/browse/JDK-8202360
> http://cr.openjdk.java.net/~gziemski/8202360_rev4

String already has a contains method you don't need to write your own 
helper.

I don't see why you stopped using BufferedReader to read each line, and 
replaced with Scanner. With the scanner the split into lines:

String[] lines = output.split("\n");

should be:

String[] lines = output.split("\\\R");

to ensure no issues with platform-specific line terminators.

  83       if (line.startsWith("[")) {

You presumably only need to know one resize has occurred so this can be 
guarded with !resize.

  99           // We've hit an error, so print all of the output.
  100           System.out.println(output);

No need to do this. And I'm not even sure what output contains any more.

  107         }

Once you get here the test is over, one way or another - you saw it 
resized and you found the Java Dictionary line. So at this point you 
should terminate the loop and then (if needed) finish processing the 
output so the target can terminate.

Finally if no resize occurred you should print a message that the test 
trivially passed without any resizing occurring eg:

if (!resized) {
   System.out.println("Test considered PASSED - but no resizing occurred.");
}

Again I'm sorry this has turned into such an issue.

Thanks,
David

> 
> cheers
>