Status: New
Owner: ----
New issue 2306 by [email protected]: Unexpected bounds-check bailout
accesing Int8Array
http://code.google.com/p/v8/issues/detail?id=2306
I've been looking for performance issues in one of my projects
(http://hulkholden.github.com/n64js/), and noticed that a function is
repeatedly causing a deopt through a bounds-check bailout in Chrome
23.0.1245.0 canary and 23.0.1243.2 dev (on OSX 10.8.1). The issue does not
seem to occur in the current production version of Chrome (21.0.1180.82).
This is the function:
function lhu(ram,a) { return (ram[a+0] << 8) | (ram[a+1] ); }
ram is a Uint8Array(8*1024*1024). I explicitly check 'a' is in range before
calling this function, so I'd never expect an out-of-bounds access.
I ran:
<chrome> --js-flags="--log_code --trace_opt --trace_bailout --trace_deopt
--code_comments --trace_inlining --trace_opt_stats" | grep -C10 "DEOPT: lhu"
I see numerous results like this:
**** DEOPT: lhu at bailout #3, address 0x0, frame size 4
;;; @24: bounds-check.
[deoptimizing: begin 0x3aae9f49 lhu @3]
translating lhu => node=3, height=0
0xbffb4364: [top + 24] <- 0x2bd08091 ; [sp + 28] 0x2bd08091 <undefined>
0xbffb4360: [top + 20] <- 0x3aac5949 ; eax 0x3aac5949 <an Uint8Array>
0xbffb435c: [top + 16] <- 0x49e3b77d ; ebx 0x49e3b77d <Number: 1799618>
0xbffb4358: [top + 12] <- 0x4e5ee921 ; caller's pc
0xbffb4354: [top + 8] <- 0xbffb437c ; caller's fp
0xbffb4350: [top + 4] <- 0x3aae7a0d ; context
0xbffb434c: [top + 0] <- 0x3aae9f49 ; function
[deoptimizing: end 0x3aae9f49 lhu => node=3, pc=0x4e5ef9a7,
state=NO_REGISTERS, alignment=no padding, took 0.027 ms]
[removing optimized code for: lhu]
I explicitly bounds-check 'a' before calling lhu(), but to be certain, I
added an assert to the function body to verify that 'a' is in bounds:
function lhu(ram,a) { a >= 0 && (a+1)<ram.length, 'out of bounds');
return (ram[a] << 8) | (ram[a+1] ); }
But it never fires.
I tested this minimal repro in d8 built from head (r12377), and it runs
without issue.
------------
function lhu(ram,a) { return (ram[a+0] << 8) | (ram[a+1] ); }
var regs = new Int32Array(32);
regs[0] = 0x80000010; // RAM access on n64 is in the range
0x8000000..0x80800000
var arr = new Int8Array(8*1024*1024);
function readU16() {
var sum = 0;
var addr = regs[0] - 8;
var value;
if (addr >= -2147483648 && addr < -2139095040) {
value = lhu(arr, addr + 0x80000000);
} else {
value = -1;
}
return value;
}
print(readU16());
%OptimizeFunctionOnNextCall(lhu);
%OptimizeFunctionOnNextCall(readU16);
print(readU16());
------------
So I'm unsure whether:
a) There's a bug in v8 in Chrome 23.0.1243.2+ that's already been fixed in
v8 (possibly related to
http://code.google.com/p/v8/source/detail?r=12025 ?).
b) My minimal repro is insufficient to reproduce the issue, and the bug is
still present
If it's b), then I can spend some time trying to isolate the issue further.
If it's a), then apologies for the redundant bug report, and I'll wait for
the latest v8 changes to make their way into Chrome.
Regards,
Paul
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
