JDK-8074457 : Remove the non-Zero CPP Interpreter
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-03-04
  • Updated: 2021-09-15
  • Resolved: 2015-12-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b103Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
There are 3 types of interpreters in hotspot currently. 

1. The "Template" interpreter, which uses platform specific code to set up frames, encode a dispatch table and encode actions for each bytecode.
2. The "Zero" interpreter, which uses no platforms specific code to set up frames and uses C++ dispatch to and execute each bytecode.
3. The "C++" interpreter, which uses platform specific code to set up frames and uses C++ code to dispatch to and execute each bytecode.

(cut/paste from Bertrand email)
Zero and the C++ interpreter use the same interpreter loop but the C++ interpreter relies on CPU dependent dynamically generated glue. It also depends on the stack walking code in our CPU directories, making that code even more complex than what it currently is (in addition to the fact that it has not been maintained for a long time). I tend to agree with Coleen when she said that the C++ interpreter is probably not worth resurrecting.

The third interpreter technology has been bit rotting in the code for a while and should be removed.   There is glue code for each cpu platform.

% wc -l cpp*
   38 cppInterpreterGenerator_x86.hpp
 2314 cppInterpreter_x86.cpp
   38 cppInterpreter_x86.hpp
 2390 total

In addition to this code there is also #ifdef CC_INTERP conditionals in the platform specific code.

% grep -r CC_INTERP | wc -l
96

Be careful though because CC_INTERP is also used for the Zero interpreter.

Also, the C++ interpreter brought with it an odd class hierarchy that could be cleaner (maybe follow-up RFE).
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d321ba06d890 User: lana Date: 2016-01-27 21:42:23 +0000
27-01-2016

URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d321ba06d890 User: coleenp Date: 2015-12-22 20:52:31 +0000
22-12-2015

Thanks Volker. I'm not sure of the timeline of doing this but your feedback is really helpful.
09-06-2015

@Coleen: I think that's OK. In case you're doing one big change which removes the CPP interpreter platform files please send around a webrev so I can do a control build on ppc64. Thanks, Volker
08-06-2015

To be clear, removing the CPP interpreter backend would be removing this code: philli% wc -l cpp* 44 cppInterpreterGenerator_ppc.hpp 3042 cppInterpreter_ppc.cpp 39 cppInterpreter_ppc.hpp 3125 total is this Okay? The complimentary code on the other platforms is broken and is essentially dead code. Thanks!
05-06-2015

Thanks for confirming, [~stuefe].
10-03-2015

At SAP we do not use the C++ Interpreter anymore. All our platforms use the template interpreter.
10-03-2015

Definitely. Someone can look into this in the 10 timeframe. There are some possibilities to use metacircularity in a smart way. Think iadd; it could be implemented as: int iadd(int a, int b) { return a + b; } Since the compiler is a Java compiler it knows about the semantics and produces the right code.
06-03-2015

Should we bring in SAP and RedHat?
05-03-2015