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

Roland Westrelin roland.westrelin at oracle.com
Fri Jan 10 04:44:32 PST 2014

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 ba_short 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?

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