RFR(M): 8026253: New type profiling points: sparc support (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Jan 10 08:26:27 PST 2014

On 1/10/14 4:44 AM, Roland Westrelin wrote:

Hi Vladimir,

Thanks for reviewing this.

c1LIRAssemblersparc.cpp: consider using not short branch instruction because the distance could be big (stop() generates a lot of code):

3135 _ bashort(next); I did a specjvm98 run on a T4 with VerifyOops on and the code as it is runs fine. The interpreter code is ok unless TypeProfileArgsLimit is set to something unreasonable (10). The bashort that you mention above is the most likely to cause problem on the compiler side. I could convert it to a non short branch just to be safe. What do you think?

Yes, I was only concern about that particular branch which is most far from destination. Even if it is fine now, later change to the code can tip it over. So, please, change it to far branch.

Thanks, Vladimir

Roland.

Otherwise it seems good.

Thanks, Vladimir On 1/9/14 12:35 AM, Roland Westrelin wrote: http://cr.openjdk.java.net/~roland/8026253/webrev.00/

The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. Roland.

More information about the hotspot-compiler-dev mailing list