Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994

[Ulf Zibis]

Am 11.10.2011 18:54, schrieb Vladimir Kozlov:
> These bugs have evaluations in Comments section which unfortunately is not visible outside. I 
> moved my comments to Evaluation section and included them below.
Much thanks, + for your fast answer!

>>     6914095 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6914095> - HotSpot should reuse
>>     invariant loop parameter
>>
>>
> It would be nice if 32bit x86 had more registers. Unfortunately we have to reuse registers 
> otherwise we will get more spills on stack which will cause more performance regression then 
> keeping value in register. And x*c+c  is very fast (few cycles) on modern cpus.
> *** (#3 of 3): 2010-11-09 15:31:21 PST vladimir.kozlov at oracle.com
Yes, this would hold, if x is held in register while looping.
But in my code, even for the inner loop, x is spilled to stack, here: 0xc(%esp)
So I still think, it would be better to alternatively spill x*c+c to the stack in the inner loop, 
and access x only in the outer loop.
Or do I miss something?

>>     6914113 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6914113> - Copy int to byte[] in
>>     1 step
>>
> Will not do this. C2 type system will not allow store int into byte array. Other platforms require 
> address alignment to 4 bytes for int store. Also on platforms with different endian the result 
> will be different.
> *** (#2 of 2): 2010-08-25 14:51:13 PDT vladimir.kozlov at oracle.com
In java.nio.Bits I see code like:
     static void putIntB(ByteBuffer bb, int bi, int x) {
         bb._put(bi + 0, int3(x));
         bb._put(bi + 1, int2(x));
         bb._put(bi + 2, int1(x));
         bb._put(bi + 3, int0(x));
     }
AFAIK, this code becomes intrinsified to native "Copy int to byte[] in 1 step" by the VM. Correct 
me, if I'm wrong.
What I want is, that if Hotspot detects such pattern (compiled in the bytecode), preferably in a 
loop, it would (1) use an aligned byte array, if necessary, and (2) then inline the existing 
intrinsification. Endianess should be no problem, as I already see different endian versions.

>>     6933327 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6933327> - Use shifted addressing
>>     modes instead of shift instuctions
>>
> Will not fix. Using  addressing mode involves addess unit which may have negative effect if you 
> have memory access instructions near this code.
> *** (#2 of 2): 2010-08-25 14:29:34 PDT vladimir.kozlov at oracle.com
What is "memory access instructions _near this code_" ?

>>     6935994 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935994> - Use as less bits as
>>     necessary
>>
> Should not do this since the other part of register will not be initialized to 0.
> *** (#2 of 2): 2010-08-25 14:39:10 PDT vladimir.kozlov at oracle.com
But what in case of java type byte only 8 bits come to usage?


Much thanks,

-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111013/7e749af3/attachment.html