8154867: PPC64: Better byte behavior

Doerr, Martin martin.doerr at sap.com
Fri Apr 22 14:48:40 UTC 2016


Hi Coleen,

thanks for taking a look. Unfortunately, I've seen your email a little too late.
 
I agree with that btos/ztos/stos/ctos are unused for the return entry and should better get removed. So we could do a cleanup change.

I think the removal of those entry points makes sense which is what you have proposed:
https://bugs.openjdk.java.net/browse/JDK-8139788

Maybe we will be able to do some more PPC cleanup.

Best regards,
Martin


-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore
Sent: Freitag, 22. April 2016 15:12
To: hotspot-runtime-dev at openjdk.java.net
Subject: Re: 8154867: PPC64: Better byte behavior


Hi Martin,

http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/src/cpu/ppc/vm/templateTable_ppc_64.cpp.udiff.html

This change looks good except the code in ireturn looks strange because 
state is never btos/ztos/stos/ctos.  OR if it was btos,stos and ctos and 
you're trying to return a boolean, there would have to be additional 
narrowing for those cases too.  It think it would be more accurate to 
have the small int tos states above itos in your switch statement.

The only reason we added ztos was to make the backports easier for these 
bugs.  I think these unused tos optimization cases should be removed.  
Do you agree?
https://bugs.openjdk.java.net/browse/JDK-8139788


Also, I guess it doesn't matter for ppc, but the April cpu code is in 
http://hg.openjdk.java.net/jdk9/hs and I was going to push the zero 
change from Severin there.  Should you make these changes for that 
repository instead?

thanks,
Coleen


On 4/22/16 4:55 AM, Doerr, Martin wrote:
> Hi,
>
> the PPC64 part of "Better byte behavior" (8148487) was done in jdk8u but is also needed in 9.
>
> Here's the port for 9/dev:
> http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/
>
> Please review.
>
> Best regards,
> Martin
>



More information about the hotspot-runtime-dev mailing list