Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994

[Vitaly Davidovich]

Don't mean to speak on Vladimir's behalf but I think he's saying that if you
have read/write to mem instructions close to this code then you can create a
stall by occupying the memory unit of the CPU by using it to compute the
address.

As for trying this out, I was thinking you could write a small program in
C/C++ with inline assembly that would compare your suggestion with current
hotspot generated assembly.
On Oct 13, 2011 4:58 PM, "Ulf Zibis" <Ulf.Zibis at gmx.de> wrote:

>  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/345283d3/attachment-0001.html