Am 17.01.2013 05:27, schrieb Vladimir Kozlov:
On 1/12/13 12:37 AM, Ulf Zibis wrote:
3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is
not available.
I opened it, should show up in few days.
Thanks!
4) What specific operation should be done by the intrinsic, i.e. is
there a fixed API for that method ???
When C2 (server JIT compiler in JVM) compiles encode methods it will replace new method
encodeArray() (matched by signature) with hand optimized assembler code which uses latest
processor instructions. I will send Hotspot changes soon. So it is nothing to do with interpreter
or bytecode sequence.
5) Can an intrinsic write back more than 1 value (see my hack via int[]
p) ?
6) Vladimir's webrev shows an integer as return type for that method,
I've added a variant with boolean return type, and the code from my last
approach could be transformed to a method with Object return type.
I wanted to say, there would maybe different results for the surrounding code depending on the API
we choose for the intrinsic method call. If the surrounding code is *as short as possible*, there is
a better chance, it will be JIT-compiled too after fewer invocations of encodeArrayLoop(). I guess,
the fastest would be:
// while inlinig, JIT will erase the surrounding int[] p
private static CoderResult copyISOs(CoderResult cr,
char[] sa, byte[] da, final int[] p, int sl) {
for (int sp = p[0], dp = p[1]; sp < sl; sp++) {
char c = sa[sp];
// if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be
fastest
if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length
operation on x86
return null;
da[dp++] = (byte)c;
}
return cr;
}
// No more needs try...finally block
private CoderResult encodeArrayLoop(
CharBuffer src, ByteBuffer dst) {
char[] sa = src.array();
int soff = src.arrayOffset();
int sp = soff + src.position();
int sr = src.remaining();
byte[] da = dst.array();
int doff = dst.arrayOffset();
int dp = doff + dst.position();
int dr = dst.remaining();
CoderResult cr;
if (dr < sr) {
sr = dr;
cr = CoderResult.OVERFLOW;
} else
cr = CoderResult.UNDERFLOW;
int sl = sp + sr;
final int[] p = { sp, dp };
cr = copyISOs(cr, sa, da, p, sl);
src.position(p[0] - soff);
dst.position(p[1] - doff);
return result(cr, sa, p[0], sl);
}
// if adapted, maybe could also be reused in encodeBufferLoop()
private static CoderResult result(CoderResult cr, byte[] sa, int sp, int sl) {
return cr != null ? cr :
sgp.parse(sa[sp], sa, sp, sl) < 0
? sgp.error();
: sgp.unmappableResult();
}
... so waiting for Vladimir's feedback :-[
(especially on performance/hsdis results)
Performance on x86 tested with next code (whole test will be in Hotspot
changes) :
ba = CharBuffer.wrap(a);
bb = ByteBuffer.wrap(b);
long start = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
ba.clear(); bb.clear();
enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow();
}
long end = System.currentTimeMillis();
1.) Wouldn't System.nanoTime() give more accurate results?
2.) I want to point out that it is not real world scenario, encoding the same data 1.000.000 times.
If same data is used, it is likely, that the data itself becomes cached in the inner CPU cache so
should have very fast access times, which would be not the case on real world data.
3.) It would also be interesting to see the results for less than 1.000.000 iterations in
considering, the surrounding code would be JIT-compiled or not. Also performance on C1 should be tested.
I also worry about the naming of method encodeArray(...). I think, it should reflect the fact, that
it only encodes ISO-8859-1 charset characters.
Please add a comment on the fact, that method encodeArray(...) is intended to
be intrinsified.
-Ulf
