JDK-6829195 : JSR 292 needs to support the C++ interpreter
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2009-04-11
  • Updated: 2016-04-22
  • Resolved: 2016-04-22
Related Reports
Relates :  
JDK-6655638 - dynamic languages need method handles
Relates :  
JDK-8074457 - Remove the non-Zero CPP Interpreter
Relates :  
JDK-7035870 - JSR 292: Zero support
Relates :  
JDK-6655646 - dynamic languages need dynamically linked call sites
Description
There are unimplemented portions of the hotspot code for method handles and invokedynamic specific to the C++ interpreter.  They need to be filled in.
Comments
I'm not exactly sure what this bug is about. All I can say is that Zero is the only C++ interpreter user these days and it has basic JSR292 support. I suppose this can be closed?
22-04-2016
@Coleen: Yes, Zero got JSR292 support with 7 (JDK-7035870). With a recent JDK 8 Zero I can run simple ruby scripts with -Xcompile.invokedynamic=true. I see some JSR292 test failures on 9, but basic JSR292 support should be there too.
22-04-2016
Yes, this can be closed as JSR292 is supported in all current interpreters. The Cpp interpreter has been removed.
22-04-2016
Does the Zero interpreter have JSR292 support?
20-04-2016
Assigning to RH to review and close it if it is not problem anymore.
19-04-2016
Meanwhile we (i.e. we like SAP and the PPC/AIX Port) indeed have the Template interpreter on all our platforms. Until recently (i.e. like several month ago) we still built the C++ Interpreter on PPC just to make sure it won't break and until then it still worked. But we are not doing that any more. I think the last remaining users of the C++ Interpreter are the RedHat guys with their Zero port. We should probably ask Andrew Hughs or Andrew Haly.
21-10-2014
[~simonis], didn't you say SAP ported the template interpreter too all platforms you support?
20-10-2014
I thought the C++ interpreter was also being used by the PPC64 port?
13-10-2014
Or we remove the C++ interpreter if it's performance isn't very much better than Zero.
10-10-2014
The C++ interpreter (supposedly) also helps prototyping changes to Klass layout (specifically Klass::_layout_helper) which the normal interpreter and the compilers directly access/inline, requiring lots of work for testing changes that are not concerned with java performance (but GC performance which is independent)
06-11-2013
Not sure if these things broke in the C++ interpreter with JSR292 changes, but when compiling with CC_INTERP=1 there are at least the following compile errors - ByteCodeInterpreter::_last_Java_fp does not exist any more but referenced by ByteCodeInterpreter::print() - the x86 implementation of ByteCodeInterpreter::VMintUShr has a wrong signature: inline jint BytecodeInterpreter::VMintUshr(jint op1, jint op2) instead of inline juint BytecodeInterpreter::VMintUshr(jint op1, jint op2); - cppInterpreter_x86.cpp:2224:10: error: 'method_handle' is not a member of 'Interpreter' - cppInterpreter_x86.cpp:2224:93: error: 'class InterpreterGenerator' has no member named 'generate_method_handle_entry' (gave up at this point)
06-11-2013
EVALUATION Marking this low priority until we understand customer need. It may need to be part of Project Zero: http://openjdk.java.net/projects/zero/ Or, it may be that the LLVM-based Shark back end will do invokedynamic in a different way.
30-03-2011