RFR(L): 8036976: PPC64: implement the template interpreter
coleen.phillimore at oracle.com
Tue Mar 11 18:03:03 UTC 2014
On 3/11/14 11:47 AM, Lindenmaier, Goetz wrote:
> Hi Coleen,
> thanks for looking at this! It's really not that small ;)
> We put functions to interpreter_ppc.cpp if we can use the same
> implementation for both interpreters. I didn't check all of them,
> but at least for generate_accessor_entry this is the case.
> We implemented the UseFast* support for experiments, but we didn't
> switch it on, either, as it didn't show sufficient benefit. We also figured
> then that methods are miscounted and other insufficiencies.
Yes, I think that's exactly what happens. They aren't considered run
and not inlined, iirc.
So you won't mind if these options go away then? Should we preserve
the PPC code when they do? I'm optimistic that we'll get to this code
(since it's essentially dead code for our port) pretty soon.
> Best regards,
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore
> Sent: Dienstag, 11. März 2014 15:55
> To: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(L): 8036976: PPC64: implement the template interpreter
> This is a lot of code to review but I have a couple of comments anyway.
> It doesn't seem like the functions are in the same place as they are for
> the other platforms, eg. generate_accessor_entry is in
> interpreter_ppc.cpp and not in templateInterpreter_ppc.cpp.
> Also, it appears that you ported the code for UseFastAccessorEntries and
> UseFastEmptyMethods. We have that turned off and it's been bit rotting
> (maybe not currently rotten but nobody knows) for years because it made
> performance worse rather than better. We had hoped to remove this code,
> so that there was less assembly code. Did you find any performance
> benefits to this code?
> On 3/11/14 5:13 AM, Lindenmaier, Goetz wrote:
>> This time I have a really nice one: the template interpreter for ppc64!
>> Great thanks to my colleagues, especially Axel and Martin, who ported
>> With this change, both interpreters can be used on linux_ppc64 and aix_ppc64.
>> This change almost only touches ppc platform files.
>> I shared files, I needed to add a special case for PPC64 in make/linux/Makefile, as I found no way to set FORCE_TIERED=0 in any ppc file that's included above the use of FORCE_TIERED. As we don't have C1, the current scheme does not work for ppc64.
>> Actually, one should have lines as
>> supports_cppInterpreter = 1
>> supports_c2 = 1
>> supports_c1 = 0
>> in platform_<cpu>. But that's out of scope of this change.
>> Further I add a #include in src/share/vm/interpreter/templateTable.hpp. That's all for shared changes.
>> Please review and test this change.
>> Best regards,
More information about the hotspot-dev