571625 - JM: Revive box-after-unbox optimization for tracing with fat values

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

TM has an optimization for the box-after-unbox pattern (which together form a no-op) on numbers, which appears especially for statements like this:

  a[i] = b[j]

When boxing up the value to call the setelem builtin, the tracer used the original 32-bit value, instead of the boxed value (the result of js_UnboxDouble). 

This can't be done in the same way with fat values on 32-bit ISAs. This is because a LIns can represent only 32 bits in general, so we represent the *address* of the Value (e.g., of b[j] above) with a LIns. Passing that LIns to setelem would be wrong, because the contents of that address may be overwritten. As a result, in the first version of tracing for fat values, I disabled that optimization.

I experimented with a few ways of bringing it back, and what seems to work best is this:

  - To unbox a number, read the mask and payload into 2 LInss and call js_UnboxDouble (which now takes 2 arguments).
  - To box a number that came from js_UnboxDouble for d2i or setelem, store the 2LInss in an 8-byte insAlloc'd space. The LIns for the alloc'd space then represents the address of the boxed Value.

This gets us back about 2.7% on SunSpider or 15 ms. For some reason, it also slows down access-nbody so that it runs at the same speed as the tracer. In the original version, we ran access-nbody 5 ms faster (1.5x) than TM.

Comment 1

[David Mandelin [:dmandelin]]

Attachment: WIP 6

Comment 2

[David Mandelin [:dmandelin]]

http://hg.mozilla.org/users/lwagner_mozilla.com/fatval/rev/48e711f9f07a