Changes

'''Description.''' A ''kernel''. A 400 x 267 image is represented as an array where each pixel gets four valuesconsecutive elements, representing the (its R, /G, /B, /Alpha) values. All values are in the range 0..255. The program transforms the contents of the array.

It iterates through each pixel, setting the (R, /G, /B) values all to the the same value, which is a function of the prior R/G/B values. This desaturation loop is repeated 200 times. '''Mozilla-specific things.''' The first time the desaturation loop runs, the (R, G, B) valuesare converted from integers to doubles. The remaining 199 times, the values are doubles to begin with. The trace code generated assumes the array elements are integers, because that's what is seen at record-time, but in the end 99.5% of the time it's not, so we end up taking a particular side-exit every time to a second trace fragment. The program is kind of stupid for (a) not truncating the desaturated R/G/B values and (b) desaturating the image 200 times in a row. Indeed, the benchmarks admits as much for (b):  //XXX improve dataset rather than loop for (var pixcounter = 0; pixcounter < 200; pixcounter++) Pixastic.Actions.desaturate.process(params); But we have to deal with it as is... it would be good if we could somehow (using the oracle?) detect that the side-exit is hot and recompile the fragment.