RFR(M): 8168083: PPC64: Cleanup template interpreter after 8154580 and 8154867
Coleen Phillimore
coleen.phillimore at oracle.com
Wed Oct 26 19:32:13 UTC 2016
On 10/20/16 4:58 AM, Doerr, Martin wrote:
> Hi Coleen,
>
> thank you very much for reviewing my PPC change.
>
> We had originally spent a lot of effort to get the template interpreter fast. I think startup performance is still important.
> A large amount of less optimized changes will make it slower over time.
> That's why we have reduced reloading constMethod in the PPC implementation. I think this would be good for other platforms as well.
> Maybe we should improve them in 10.
I don't know. I though load_mirror() made for a nice API. Does the
extra indirect matter? I filed RFE
https://bugs.openjdk.java.net/browse/JDK-8168795 so we can investigate
further in 10.
This is approved and I think reviewed so you can check it in anytime. I
put a due date of Friday on your bug. Feel free to change it if that's
not good.
Thanks,
Coleen
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore
> Sent: Dienstag, 18. Oktober 2016 23:56
> To: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(M): 8168083: PPC64: Cleanup template interpreter after 8154580 and 8154867
>
>
> This seems good. I think it's a shame to change load_mirror() to
> load_mirror_from_const_method() though because there's load_mirror()
> with the same parameters on all the other platforms and it makes
> platform development a little easier. But that's up to you to because
> you can generate shorter sequences.
>
> Coleen
>
>
> On 10/17/16 12:38 PM, Doerr, Martin wrote:
>> Hi,
>>
>> I'd like to clean up the template interpreter on PPC64 a little bit after changes which were pushed into jdk9:
>>
>> 8154580 introduced copying the java mirror into the interpreter frame. Some code can be implemented shorter. Before this change, the size of the ijava state was designed to be a multiple of 16. We should remove the comment as this is no longer true. I have checked that this is not really required (generate_fixed_frame inserts frame padding if needed).
>>
>> 8154867 is the PPC64 port of "better byte behavior". The shorter TOS states are not treated appropriately (which is not critical because the template interpreter also uses itos for shorter types). This part of the change was requested by Coleen, but it didn't make it into the original webrev.
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~mdoerr/8168083_PPC64_interp_cleanup/webrev.00/
>>
>> Please review.
>>
>> Thanks and best regards,
>> Martin
>>
More information about the hotspot-runtime-dev
mailing list