RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files

[Lindenmaier, Goetz]

Hi Coleen, 

I think they belong together because can_be_compiled() just returns
false for functions that have a math entry which is generated by
generate_math_entry().  So if you add a new math_entry, you
also have to fix can_be_compiled.  We wired this dependency into
math_entry_available(kind), so that both functions are guaranteed
to behave similar.

The name of the function is kind of misleading to me.

But I won't insist...

Best regards,
  Goetz.



> -----Original Message-----
> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
> Sent: Tuesday, January 05, 2016 7:17 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
> developers <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined
> in the wrong files
> 
> 
> 
> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote:
> > Hi Coleen,
> >
> > Could you please also move
> > AbstractInterpreter::can_be_compiled(methodHandle m)
> > to above
> >
> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter::
> MethodKind kind)?
> > I think these belong together.
> 
> Really?  They're in different classes (hence the motivation for the
> change) and generate_math_entry doesn't call can_be_compiled.
> CompilationPolicy does but it calls it from
> AbstractInterpreter::can_be_compiled() so I really can't move this
> function into TemplateInterpreterGenerator.  It doesn't make sense to me.
> 
> >
> > We seem to have different BIND macros on ppc. The '__' is also in the
> > macro. Could you please fix this small issue? It breaks the ppc build.
> >
> > diff -r 743aa331fc90
> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp
> > --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp	Tue
> Jan 05 07:47:21 2016 +0100
> > +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp	Tue
> Jan 05 08:06:12 2016 +0100
> > @@ -416,7 +416,7 @@
> >     default: ShouldNotReachHere();
> >     }
> >
> > -  __ BIND(done);
> > +  BIND(done);
> >     __ blr();
> >
> 
> Fixed.  Thanks!!
> >     return entry;
> >
> > Besides this, the change looks good.
> 
> Thanks,
> Coleen
> 
> > Thanks and best regards,
> >    Goetz.
> >
> > PS: is it possible to share your Copyright script?
> >
> >> -----Original Message-----
> >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> >> Behalf Of Coleen Phillimore
> >> Sent: Monday, January 04, 2016 11:43 PM
> >> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> >> Subject: RFR (M) 8146410: Interpreter functions are declared and defined
> in
> >> the wrong files
> >>
> >> Summary: Moved functions to the correct files.
> >>
> >> See bug for more details.
> >>
> >> I basically did an hg mv templateInterpreter_<cpu>.cpp
> >> abstractInterpreter_<cpu>.cpp and moved the interpreter_<cpu>.cpp
> >> functions there.
> >>
> >> Also moved generate_slow_signature_handler to
> >> TemplateInterpreterGenerator/CppInterpreterGenerator because it's
> not
> >> shared.
> >>
> >> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/
> >> bug link https://bugs.openjdk.java.net/browse/JDK-8146410
> >>
> >> Tested with JPRT on Oracle supported platforms and built zero on linux
> >> x86.  Also fixed change that broke zero in stack_zero.inline.hpp.  I
> >> think this should work on PPC and AARCH64, but please let me know.
> >>
> >> One question for AARCH64 platform in file:
> >>
> >>
> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat
> >> eInterpreterGenerator_aarch64.cpp.udiff.html
> >>
> >> thanks,
> >> Coleen