- reposted without picture -
Hi Francis,
I think the test you used is good (it generates invokedynamic bytecodes
with the ASM library. If you want a better test coverage you could use the
regression tests under jdk/test/java/lang/invoke/.
Regards,
Volker
On Tue, Oct 8, 2013 at 7:17 PM, Francis ANDRE <
francis.andre.kampb...@orange.fr> wrote:
> Hi Volker
>
> I wanted to test my changes on a simple test that involves InvokeDynamic
> using JDK7. I joined the test I found on the internet and also the output
> of running this test. I run the same way as before where the assert was
> failing before I made the changes.
>
> Can you have a look to this test and tell me if you consider it as a real
> test for the invokedynamic opcode and environment EnableInvokeDynamic as
> true which is the default?
>
> If this ReflectTest.java is not a proper test for testing the
> invokedynamic, could you provide me a test you are considering as a test
> that the interpreter is running fine?
>
>
> Francis
>
>
> Francis
> Le 07/10/2013 10:59, Volker Simonis a écrit :
>
> 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> <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/jdk7uhttp://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> <francis.andre.kampb...@orange.fr>
> wrote:
>
> Hi
>
> On WXP with VS2010 and thehttp://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
