1.1 --- a/src/share/vm/interpreter/bytecodeInterpreter.cpp Fri May 31 06:41:50 2013 +0200
1.2 +++ b/src/share/vm/interpreter/bytecodeInterpreter.cpp Wed Apr 24 11:49:38 2013 +0200
1.3 @@ -468,7 +468,25 @@
1.4
1.5 #ifdef ASSERT
1.6 if (istate->_msg != initialize) {
1.7 - assert(abs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + 1), "bad stack limit");
1.8 + // We have a problem here if we are running with a pre-hsx24 JDK (for example during bootstrap)
1.9 + // because in that case, EnableInvokeDynamic is true by default but will be later switched off
1.10 + // if java_lang_invoke_MethodHandle::compute_offsets() detects that the JDK only has the classes
1.11 + // for the old JSR292 implementation.
1.12 + // This leads to a situation where 'istate->_stack_limit' always accounts for
1.13 + // methodOopDesc::extra_stack_entries() because it is computed in
1.14 + // CppInterpreterGenerator::generate_compute_interpreter_state() which was generated while
1.15 + // EnableInvokeDynamic was still true. On the other hand, istate->_method->max_stack() doesn't
1.16 + // account for extra_stack_entries() anymore because at the time when it is called
1.17 + // EnableInvokeDynamic was already set to false.
1.18 + // So we have a second version of the assertion which handles the case where EnableInvokeDynamic was
1.19 + // switched off because of the wrong classes.
1.20 + if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) {
1.21 + assert(abs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + 1), "bad stack limit");
1.22 + } else {
1.23 + const int extra_stack_entries = Method::extra_stack_entries_for_indy;
1.24 + assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + extra_stack_entries
1.25 + + 1), "bad stack limit");
1.26 + }
1.27 #ifndef SHARK
1.28 IA32_ONLY(assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1, "wrong"));
1.29 #endif // !SHARK
