On Marcus' request I also replaced hardcoded instances of 0xffff_ffffL
with JSType.MAX_UINT throughout the code base. Already got +1 from
Marcus, I need one more review please.
http://cr.openjdk.java.net/~hannesw/8012334/webrev.02/
Hannes
Am 2013-04-24 06:33, schrieb Marcus Lagergren:
OK. We are introducing method specialization based on call sites and we ARE
introducing strength reduction based on rage analysis, so I guess this is +1
for me.
On Apr 24, 2013, at 12:26 AM, Hannes Wallnoefer <[email protected]>
wrote:
The microbenchmark goes from about 250 millis to about 380 for most numbers.
But I guess we'll have to bite the bullet. Also V8 takes around 380
milliseconds when it actually converts from double (much faster when it's able
to optimize to ints) so I guess it's just the time it takes.
I also did a few octane runs and couldn't detect any regression there.
Hannes
Am 2013-04-23 20:51, schrieb Marcus Lagergren:
How much is a bit and what did you measure?
On Apr 23, 2013, at 8:33 PM, Hannes Wallnoefer <[email protected]>
wrote:
Please review webrev for JDK-8012334: ToUint32, ToInt32, and ToUint16 don't
conform to spec:
http://cr.openjdk.java.net/~hannesw/8012334/
The code path for small numbers is now a little bit slower but not much. The
code path for large numbers that don't fit in 32 bits is quite a bit slower,
but it should be correct now. The patch also contains a microbenchmark for
ToInt32 (signed right shift) and ToUint32 (unsigned right shift).
Hannes
