RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall

David Holmes david.holmes at oracle.com
Mon Mar 21 05:12:54 UTC 2016


Hi Coleen,

On 19/03/2016 10:57 PM, Coleen Phillimore wrote:
> Summary: Deferred code review cleanups
>
> This was a review comment I had when the StackWalk API was integrated.
> There were too many of this same code pattern in the middle of
> universe_post_init.  The only real change here is that if the method
> isn't found and doesn't have the right linkage because of a mismatch in
> JDK version, we can vm_exit_during_initialization() rather than try to
> return JNI_ERR.  This avoids ugly code to check
> initialize_known_method's boolean result for each call.  We can't throw
> an exception here.  Because of the EXCEPTION_MARK in universe_post_init,
> any exception gets turned into vm_exit_during_initialization anyway. But
> this wouldn't be a user error, so vm_exit_during_initialization seemed
> like the cleanest choice.

Our initialization code is truly awful. Until the VM is initialized 
any/all exceptions have to convert back to a different form of error 
because there will be no thread (or JVM for that matter) on which the 
user code could ask if an exception occurred. It then comes down to 
whether an error should be reported to the caller of JNI_CreateJavaVM so 
the host program doesn't get terminated, or we abort everything with 
vm_exit_during_initialization. And we're sliding further and further 
into always doing the latter.

So in an absolute sense the new code is incompatible with the old 
because it will terminate host applications that wouldn't previously 
have been terminated - but in a practical sense this is unlikely to make 
any real difference to anything.

That said something about all this is really bugging me. If we can do:

!   SystemDictionary::Finalizer_klass()->link_class(CHECK_false);

which purports to allow an exception to have been posted then how is it 
the immediately following code:

!   Method* m = SystemDictionary::Finalizer_klass()->find_method(
!                                   vmSymbols::register_method_name(),
!                                   vmSymbols::register_method_signature());
!   if (m == NULL || !m->is_static()) {
!     tty->print_cr("Unable to link/verify Finalizer.register method");
!     return false; // initialization failed (cannot throw exception yet)
!   }

can not throw an exception yet? Either both can throw or neither can 
throw AFAICS. So maybe the refactored link() call should not be using 
CHECK_ but also exit immediately?

> Also, I want to get the code to not have to include method names (and
> field names) in vmSymbols.cpp.
>
> I verified that this code won't merge conflict with jigsaw.  There are
> many additional cleanups that can be done here. universe_post_init
> should really be a method belonging to Universe since it sets many
> static fields in Universe, but to avoid merge conflicts, I didn't do that.

If you do that cleanup some time there are some very inaccurate comments 
in relation to the initialization code in init.cpp that could do with 
correcting. And I also spotted two paths to Interpreter::initialize.

Thanks,
David
-----

>
> Tested with JPRT and colocated tests.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8143269
>
> Thanks,
> Coleen


More information about the hotspot-runtime-dev mailing list