Request for reviews (XXL): 6961690: load oops from constant table on SPARC

Igor Veresov igor.veresov at
Mon Nov 15 12:14:55 PST 2010

On 11/15/10 8:41 AM, Paul Hohensee wrote:
> Depends on the platform whether it's a win or not. When we did the original
> sparc64 port, it was faster to materialize 64-bit constants inline than
> to do
> a load. This was on U3s. Ditto U4s and U4+s when we tried them. Faster to
> do multi-issue (3 clocks max) than to tolerate a potential L1 miss.

Also, consider the edge case: a method that does only one load of a 
constant. In this case it is a full-blown cache miss with a high 
probability (the first time for sure). Whereas if a constant is embedded 
in the instruction stream it never is.

It would be interesting to compare cache-miss statistics (as well as the 
overall performance) for different styles of constant loading on 
T-series and M-series.


> Paul
> On 11/15/10 8:45 AM, Christian Thalinger wrote:
>> On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote:
>>> Most important is why it is not under flag?
>> Hmm, I never thought about putting it under a flag since in theory
>> materializing the constant table base address only once instead of
>> every time it's required should always be a win.
>> -- Christian

More information about the hotspot-compiler-dev mailing list