RFR(S): 8209598: Use log_error for error message in CDS code (original) (raw)
Jiangli Zhou jiangli.zhou at oracle.com
Wed Oct 24 23:39:34 UTC 2018
- Previous message: RFR(S): 8209598: Use log_error for error message in CDS code
- Next message: RFR(S): 8209598: Use log_error for error message in CDS code
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Calvin,
- src/hotspot/share/classfile/classLoader.cpp
1474 if (!get_canonical_path(path, canonical_class_src_path, JVM_MAXPATHLEN)) { 1475 log_error(cds)("Bad pathname %s. CDS dump aborted.", path); 1476 vm_exit(1); 1477 }
1480 if (!get_canonical_path(ent->name(), canonical_path_table_entry, JVM_MAXPATHLEN)) { 1481 log_error(cds)("Bad pathname %s. CDS dump aborted.", ent->name()); 1482 vm_exit(1); 1483 }
By the time ClassLoader::record_result() is called, it should be guaranteed that the paths from the class stream source and the recorded path table are valid. Both of the above log_error & vm_exit should be replaced by asserting the return value of get_canonical_path() is true.
- src/hotspot/share/memory/metaspaceShared.cpp
1648 if (IgnoreUnverifiableClassesDuringDump) { 1649 // This is useful when running JCK or SQE tests. You should not 1650 // enable this when running real apps. 1651 SystemDictionary::remove_classes_in_error_state(); 1652 } else { 1653 log_error(cds)("Please remove the unverifiable classes from your class list and try again"); 1654 exit(1); 1655 }
IgnoreUnverifiableClassesDuringDump is enabled by default and we don't include unverifiable classes in the archive. The above comment is outdated. We probably can remove the diagnostic option, IgnoreUnverifiableClassesDuringDump altogether now. We used to quit dumping process when encountering unverifiable classes (we didn't have the class removal part), then IgnoreUnverifiableClassesDuringDump was added but set to false initially (to keep the old behavior). IgnoreUnverifiableClassesDuringDump was turned on by default later. The current behavior is the proper behavior and we can clean up the code.
Thanks,
Jiangli
On 10/23/18 9:36 PM, Calvin Cheung wrote:
Ioi, David,
Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8209598/webrev.01/ I've run those 2 tests locally on linux-x64. thanks, Calvin On 10/23/18, 8:50 PM, Ioi Lam wrote:
On 10/23/18 7:27 PM, Calvin Cheung wrote:
On 10/23/18, 5:18 PM, Ioi Lam wrote: Hi Calvin, if (PrintSharedArchiveAndExit) { if (PrintSharedDictionary) { - tty->printcr("\nShared classes:\n"); + loginfo(cds)("\nShared classes:\n"); SystemDictionary::printshared(tty); } if (archiveloadingfailed) { - tty->printcr("archive is invalid"); + logerror(cds)("archive is invalid"); vmexit(1); } else { - tty->printcr("archive is valid"); + loginfo(cds)("archive is valid"); vmexit(0); } } I think this part should use printcr, because the option says "Print ...". It shouldn't be necessary to explicitly set -Xlog:cds in order to get the printed message. Should I just revert loginfo changes and leave the logerror there? I think the logerror should be reverted as well, because it would look out of place with the rest of the output. Thanks - Ioi If you revert this, I think the two test cases also can be reverted. Yes, the changes to the two tests were due to the loginfo changes. The rest of the changes look OK. Thanks for your review. Calvin Thanks - Ioi
On 10/23/18 2:45 PM, Calvin Cheung wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8209598 webrev: http://cr.openjdk.java.net/~ccheung/8209598/webrev.00/ Use logerror(cds) instead of tty->printcr for CDS error messages. Also converted 2 CDS info messages to loginfo(cds). Testing: mach5 hs-tier{1,2,3} thanks, Calvin
- Previous message: RFR(S): 8209598: Use log_error for error message in CDS code
- Next message: RFR(S): 8209598: Use log_error for error message in CDS code
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]