RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions

[Lindenmaier, Goetz]

Hi Coleen, 

thanks for incorporating my changes!
I missed one detail in my patch yesterday -- no clue why it compiled:

diff -r 4a05b14492dc src/cpu/ppc/vm/templateInterpreter_ppc.cpp
--- a/src/cpu/ppc/vm/templateInterpreter_ppc.cpp        Fri Dec 04 08:27:28 2015 +0100
+++ b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp        Fri Dec 04 11:18:50 2015 +0100
@@ -55,7 +55,7 @@
 // These should never be compiled since the interpreter will prefer
 // the compiled version to the intrinsic version.
 bool AbstractInterpreter::can_be_compiled(methodHandle m) {
-  return !math_entry_available(method_kind(m));
+  return !TemplateInterpreter::math_entry_available(method_kind(m));
 }

 // How much stack a method activation needs in stack slots.

Could you please fix this?  Sorry for the trouble.

Besides that it now works fine.

Best regards,
  Goetz.





> -----Original Message-----
> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
> Sent: Freitag, 4. Dezember 2015 00:51
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
> developers <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR 8144534: Refactor templateInterpreter and
> templateInterpreterGenerator functions
> 
> 
> Hi Goetz,
> 
> Thank you for looking at my change.  I made the ppc changes and hg added
> templateInterpreter_ppc/aarch64.cpp back, so they should be in the patch.
> 
> Now webrev thinks I've deleted 7785 lines, but I didn't really.
> 
> http://cr.openjdk.java.net/~coleenp/8144534.02/
> 
> The most interesting part of this change is in the x86 code:
> 
> http://cr.openjdk.java.net/~coleenp/8144534.02/src/cpu/x86/vm/templateI
> nterpreterGenerator_x86.cpp.udiff.html
> 
> This is where the 32 and 64 bit template interpreter code is merged.
> 
> Thanks,
> Coleen
> 
> On 12/3/15 8:14 AM, Lindenmaier, Goetz wrote:
> > Hi Coleen,
> >
> > I've been looking at this change. A cleanup in this area is really
> > useful.
> > I missed templateInterpreter_ppc.cpp in your patch, I guess you forgot
> > "hg add" for it.
> > In addition, I had to fix some code around math_entry_available(), see this
> patch:
> > http://cr.openjdk.java.net/~goetz/webrevs/8144534-interp/8144534-
> fixes_for_ppc.patch
> >
> > In general, I think it's strange that AbstractInterpreterGenerator
> > implementations are in interpreter_<cpu>.cpp, as mentioned In the bug.
> > Why not move them to templateInterpreterGenerator_<cpu>.cpp? Or will
> > this be subject to a later change that removes the funny common
> > subclasses Interpreter/InterpreterGenerator?
> >
> > Should I make a change removing the CC_INTERP support from ppc?
> >
> > Best regards,
> >    Goetz.
> >
> >> -----Original Message-----
> >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> >> Behalf Of Coleen Phillimore
> >> Sent: Donnerstag, 3. Dezember 2015 02:58
> >> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> >> Subject: RFR 8144534: Refactor templateInterpreter and
> >> templateInterpreterGenerator functions
> >>
> >> Summary: merged templateInterpreter_x86_32/64 into
> >> templateInterpreterGenerator_x86.cpp (some 32/64 functions remain for
> >> the hand coded crc functions).
> >>
> >> open webrev at http://cr.openjdk.java.net/~coleenp/8144534.01/
> >> bug link https://bugs.openjdk.java.net/browse/JDK-8144534
> >>
> >> I tried to make this reviewable by hg renaming files.   I basically
> >> renamed templateInterpreter_ppc.cpp and removed the
> >> AbstractInterpreter
> >> functions and put them back into templateInterpreter_ppc.cpp.  I didn't
> >> really delete 4000 lines of code, more like 1500.
> >>
> >> Also, can someone with the PPC and AARCH port look at and test out
> these
> >> changes? I tried to reduce the #includes in the new
> >> templateInterpreter_ppc/aarch64.cpp files which worked for sparc.
> >>
> >> Tested with JPRT on all platforms, also ran jtreg and
> >> collocated/non-collocated tonga tests for linux x64 and i386 since
> >> that's were the real changes are.
> >>
> >> See the bug for more details and my partial vision of how these
> >> functions will be reorganized when I remove the broken c++ interpreter.
> >>
> >> Also tested that Zero still builds.
> >>
> >> Thanks!
> >> Coleen
> >>