JDK-8166295 : [TESTBUG] nsk/regression/b4318701 b4324656 b4330134 fail with exit code 97
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2016-09-19
  • Updated: 2016-09-23
  • Resolved: 2016-09-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
PIT
they happened on Linux-x86/x64

output's tail

.......................
 999:   0:  0.04%:  811863588: java.lang.Cloneable, loader NULL class_loader
1000:
1001:   0:  0.01%:  196567318: java.lang.invoke.MethodType$ConcurrentWeakInternSet, loader NULL class_loader
1002:
1003:
1004:
1005:   0:  0.01%:  213403496: java.lang.module.ModuleDescriptor$Version, loader NULL class_loader
1006:   0:  0.01%:  997595270: java.security.CodeSource, loader NULL class_loader
1007:
1008:   0:  0.01%:  134024460: java.util.concurrent.ConcurrentHashMap$EntryIterator, loader NULL class_loader

Top 16 buckets:
 781: hits  0.22%
 729: hits  0.28%
 338: hits  0.23%
 836: hits 29.88%
 490: hits  6.10%
 910: hits  6.71%
 635: hits  0.23%
 959: hits 43.44%
 986: hits  0.48%
 458: hits  0.62%
 686: hits  0.21%
  99: hits  0.72%
 141: hits  0.80%
 979: hits  0.19%
  14: hits  0.17%
  14: hits  0.17%

Protection domain cache table (table_size=137, classes=1)
entry 0xca9e9d50 value 0xd227fae0 strongly_reachable 0 next 0x00000000
Test failed: encountered substring "error" in java output

It seems like the test find string 'error' in output strings such
[2016-09-17T16:22:03.66]  130:   0:  0.02%:  740605121: java.lang.Error, loader NULL class_loader
[2016-09-17T16:22:03.66]  188:   0:  0.01%: 1026112828: java.lang.NoClassDefFoundError, loader NULL class_loader
[2016-09-17T16:22:03.66]  323:   0:  0.01%:  958953923: java.lang.OutOfMemoryError, loader NULL class_loader
etc.
Comments
Closing again as a duplicate of JDK-8166145
23-09-2016

If we make the warning print out only for "product" builds, we will loose most (all?) coverage, so that's not doable. If we hide the warning behind UL tag, it will be hidden, unless explicitly turned on, so again we lose all coverage, so that's not doable.
21-09-2016

Debug builds are the only builds where we find these instances, including JDK-8138760 (ex. Kitchensink (bigapps)). The entire code for this warning is wrapped in DEBUG_ONLY macro: DEBUG_ONLY(if (!verify_lookup_length((double)number_of_entries() / table_size())) this->print(true)); The hash table load factor issue, is technically equally applicable to debug and product builds, but I do see the point, however, that the debug builds should not care about performance issues.
21-09-2016

Yes but whenever it happens we should just update the test to disable the warning IMO. Or to aid testing we could have the warning on by default in product mode, but off by default in debug mode. Then any true performance testing in product mode will still show up the warning.
21-09-2016

I don't think it is just this test. The warning that looks like this: Java HotSpot(TM) Server VM warning: Performance bug: SystemDictionary lookup_count=40506 lookup_length=48649 average=1.201032 load=0.573835 has happened to quite a few tests over the years.
21-09-2016

As we don't care about the performance of a test we should be able to disable the performance related warning when running the test.
21-09-2016

It was suggested that we should use UL to log the SystemDictionary performance issue, but I'm not sure how it would fix things. In order to be useful, SystemDictionary performance issue needs to print out the warning. If we hide it behind some level of UL debugging, then it will not print out and will not be doing anything anymore. If we modify the test to print out that UL level showing the warning, then we are back again to square one. We have a few options on how to fix it: - leave SystemDictionary performance warning as is, and modify the test to be smarter about what it looks for in the output (how many such tests are there though?) - remove/modify the extra debug info - fix the performance issue, so that we no longer get the warning - print the detailed debug info into a file, instead of stdout/stderr
20-09-2016

Re-opening to track the regression caused, and leaving JDK-8166145 to track the performance issue.
20-09-2016