RFR 8144534: Refactor templateInterpreter and templateInterpreterGenerator functions

[Coleen Phillimore]

Hi Goetz,

Thank you again for testing and reviewing this.  This was my mismerge 
because I did it by hand.  Another reason why this class hierarchy is 
strange (which I'm trying to fix next).

Thanks,
Coleen


ps.  I hope someone from aarch64 (RedHat) can test out my patch. Please?

On 12/4/15 5:21 AM, Lindenmaier, Goetz wrote:
> 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
>>>>