What are your settings for 'EnableInvokeDynamic'? If you use the
default which is EnableInvokeDynamic=true then verifier_max_stack()
doesn't account for extra_stack_entries() and this is wrong because
'istate->_stack_limit' does (see the comment in our code).
Your solution probably only seems to work because
'istate->_stack_limit' on x86 currently does not account for
extra_stack_entries() which is wrong (you probalby won't be able to
run any JSR292 code). I think you'll have to add something similar
like
// max_stack = method->max_stack();
// TODO: PPC port: assert(2 == methodOopDesc::sz_max_stack(),
"unexpected field size");
__ ppc_lhz(max_stack, method_(max_stack));
if (EnableInvokeDynamic) {
// Take into account 'extra_stack_entries' needed by method
handles (see method.hpp)
__ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries());
}
to CppInterpreterGenerator::generate_compute_interpreter_state() on
x86 to make JSR292 work with the CPP interpreter on that platform.
After you did that, you will probably see that the assertion will not
work anymore with verifier_max_stack() and you'll have to use
max_stack() as we did.
The two different versions of the assertion in our code are only
necessary, if you use a HotSpot 24 with a pre HS24 class library, in
which case EnableInvokeDynamic will be switched off after
CppInterpreterGenerator::generate_compute_interpreter_state was
called.
Regards,
Volker
On Fri, Oct 4, 2013 at 8:37 PM, Francis ANDRE
<francis.andre.kampb...@orange.fr> wrote:
> Hi Volker
>
> I had a look to the CPP-Interpreter you mention in your answer and found out
> a somewhat different implementation for verifying the stack size.
>
> here the snippet from the ppc-aix-potr/jdk7u
> #ifdef ASSERT
> if (istate->_msg != initialize) {
> // We have a problem here if we are running with a pre-hsx24 JDK (for
> example during bootstrap)
> // because in that case, EnableInvokeDynamic is true by default but will
> be later switched off
> // if java_lang_invoke_MethodHandle::compute_offsets() detects that the
> JDK only has the classes
> // for the old JSR292 implementation.
> // This leads to a situation where 'istate->_stack_limit' always
> accounts for
> // methodOopDesc::extra_stack_entries() because it is computed in
> // CppInterpreterGenerator::generate_compute_interpreter_state() which
> was generated while
> // EnableInvokeDynamic was still true. On the other hand,
> istate->_method->max_stack() doesn't
> // account for extra_stack_entries() anymore because at the time when it
> is called
> // EnableInvokeDynamic was already set to false.
> // So we have a second version of the assertion which handles the case
> where EnableInvokeDynamic was
> // switched off because of the wrong classes.
> if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) {
> assert(labs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->max_stack() + 1), "bad stack limit");
> }
> else {
> const int extra_stack_entries = 2; // MUST match the value in
> methodOopDesc::extra_stack_entries()
> assert(labs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->max_stack() + extra_stack_entries
> + 1), "bad stack limit");
> }
>
>
> On my x86 build, I used this and it seems to work fine also
> #ifdef ASSERT
> if (istate->_msg != initialize) {
> assert(abs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->verifier_max_stack() + 1), "bad stack limit");
> #ifndef SHARK
> IA32_ONLY(assert(istate->_stack_limit == istate->_thread->last_Java_sp()
> + 1, "wrong"));
> #endif // !SHARK
> }
>
> so I am wondering if it is ok to use the verifier_max_stack() function which
> seems lighter from the lisibility perspective?
>
>
>
> Francis
>
> Le 30/09/2013 17:37, Volker Simonis a écrit :
>>
>> Just for reference: we have a running CPP-Interpreter on Linux/PPC64
>>
>> with some enhancements like profiling, compressed oops, OSR, JSR292
>> and Biased Locking. So in the case you want to fix it on x86, you may
>> take the PPC64 implementation as a boiler plate:
>>
>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u
>> http://hg.openjdk.java.net/ppc-aix-port/jdk8
>>
>> Regards,
>> Volker
>>
>>
>>
>> On Wed, Sep 25, 2013 at 7:52 PM, Francis ANDRE
>> <francis.andre.kampb...@orange.fr> wrote:
>>>
>>> Hi
>>>
>>> On WXP with VS2010 and the
>>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/
>>> repository, I successfully build and ran the debug version of hotspot in
>>> compiler1 directory. fine
>>>
>>> Next, I tried to get working the bytecode cppInterpreter instead of the
>>> template based interpreter adding the CC_INTERP=true preprocessor define,
>>> but I got several compile errors -- see below --
>>>
>>> By looking at the Wiki and the OpenJDK website, I discovered that the
>>> cppInterpreter was no more maintained.
>>>
>>> So I am wondering why the cppInterpreter is not anymore maintained and
>>> would
>>> like to understand if this decision is definitive or not, because it
>>> seems
>>> to me that there are very few errors. (see above) and that, IMHO, a
>>> somewhat
>>> small effort should be made to fix the cppInterpreter (but it could be
>>> totally wrong).
>>>
>>> I need the cppInterpreter to make a proposal to the MLVM project to
>>> slightly
>>> change the JVM spec for all xALOAD and xASTORE bytecodes for a specific
>>> class version number for an efficient support of a _COBOL __runtime_.
>>>
>>> Regards
>>>
>>> Francis
>>>
>>>
>>> cppInterpreter_x86.cpp
>>> 1> frame_x86.cpp
>>> 1> interpreter_x86_32.cpp
>>> 1> interp_masm_x86_32.cpp
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039:
>>> 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065:
>>> 'interpreter_frame_sender_sp_offset' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039:
>>> 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065:
>>> 'interpreter_frame_last_sp_offset' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039:
>>> 'interpreter_frame_method_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065:
>>> 'interpreter_frame_method_offset' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039:
>>> 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065:
>>> 'interpreter_frame_mdx_offset' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039:
>>> 'interpreter_frame_cache_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065:
>>> 'interpreter_frame_cache_offset' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039:
>>> 'interpreter_frame_locals_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065:
>>> 'interpreter_frame_locals_offset' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039:
>>> 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065:
>>> 'interpreter_frame_bcx_offset' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039:
>>> 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> déclaration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065:
>>> 'interpreter_frame_initial_sp_offset' : identificateur non déclaré
>>> 1> sharedRuntime_x86_32.cpp
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220:
>>> avertissement considéré comme une erreur - aucun fichier 'object' généré
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146:
>>> opérateur
>>> moins unaire appliqué à un type non signé, le résultat sera non signé
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039:
>>> 'increment_mask_and_jump' : n'est pas membre de
>>> 'InterpreterMacroAssembler'
>>> 1> z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
>>> voir
>>> la déclaration de 'InterpreterMacroAssembler'
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur
>>> de
>>> syntaxe : identificateur 'Condition'
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl'
>>> :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): error C3861:
>>> 'incrementl' : identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1422): error C3861: 'movl'
>>> :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1423): error C3861: 'andl'
>>> :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'cond'
>>> :
>>> identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'where'
>>> :
>>> identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C3861: 'jcc' :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(233): error C2039:
>>> 'empty_expression_stack' : n'est pas membre de
>>> 'InterpreterMacroAssembler'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
>>> voir
>>> la déclaration de 'InterpreterMacroAssembler'
>>> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(235): error C2039:
>>> 'restore_locals' : n'est pas membre de 'InterpreterMacroAssembler'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
>>> voir
>>> la déclaration de 'InterpreterMacroAssembler'
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039:
>>> 'method_handle' : n'est pas membre de 'Interpreter'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreter.hpp(143)
>>> :
>>> voir la déclaration de 'Interpreter'
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2065:
>>> 'method_handle' : identificateur non déclaré
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2051:
>>> l'expression associée à case n'est pas une constante
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039:
>>> 'generate_method_handle_entry' : n'est pas membre de
>>> 'InterpreterGenerator'
>>> 1>
>>>
>>> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreterGenerator.hpp(37)
>>> : voir la déclaration de 'InterpreterGenerator'
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2255): error C2064: le
>>> terme
>>> ne correspond pas à une fonction qui prend 0 arguments
>>> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): error C2220:
>>> avertissement considéré comme une erreur - aucun fichier 'object' généré
>>> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): warning C4146:
>>> opérateur moins unaire appliqué à un type non signé, le résultat sera non
>>> signé
>>> ========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été
>>> ignoré
>>> ==========
>>>
>>>
>>>
>>>
>>>
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
