RFR: 8260341: CDS dump VM init code does not check exceptions

[Harold Seigel]

On Wed, 10 Feb 2021 05:00:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When CDS dumping is enabled, special initialization happens during VM init. However, many of these calls do not properly check for exception. Instead, they rely on the implicit knowledge that `metaspace::allocate()` will exit the VM when allocation fails during CDS dumping. This makes the code hard to understand and tightly coupled to `metaspace::allocate()`.
> 
> The fix is: all code that makes allocation should be using CHECK macros, so each block of code can be individually understood without considering the behavior of `metaspace::allocate()`.
> 
> I added `TRAPS` to a bunch of CDS-related functions that are called during VM init. In some cases, I changed `Thread* THREAD` to `TRAPS`. This also eliminated a few `Thread* THREAD = Thread::current()` calls.
> 
> The "root" of these calls, such as `MetaspaceShared::prepare_for_dumping()`, now follows this pattern:
> 
>   EXCEPTION_MARK;
>   ClassLoader::initialize_shared_path(THREAD);
>   if (HAS_PENDING_EXCEPTION) {
>     java_lang_Throwable::print(PENDING_EXCEPTION, tty);
>     vm_exit_during_initialization("ClassLoader::initialize_shared_path() failed unexpectedly");
>   }

Hi Ioi,
Do you avoid using CHECK if it's the last line of a function?  For example, why is THREAD used instead of CHECK at line 1506?
Thanks, Harold

1503 void ClassLoader::initialize_module_path(TRAPS) {
1504   if (Arguments::is_dumping_archive()) {
1505     ClassLoaderExt::setup_module_paths(CHECK);
1506     FileMapInfo::allocate_shared_path_table(THREAD);
1507   }
1508 }

-------------

PR: https://git.openjdk.java.net/jdk/pull/2494