See bug 572029 for background. Even after the fix for that bug, we can still get another 15-20ms win on crypto and fannkuch if we are smart about doing specialized unboxing from getelem. The key is being able to predict when specializing for int or double is a good idea. Ideas we've come up with: 1. Start by fully specializing. Keep a bit per trace tree (or maybe script) that indicates if we've misspeculated after a getelem. Once it is set, use the common number path instead. This limits the damage to 1 per tree (or script). 2. Try to predict by looking ahead in the bytecode stream. If we can find the consumer of the result of the getelem, we can make a good guess. If the consumer is a setelem, we should use the common path, because that enables the box-after-unbox optimization. If the consumer is a bitop and the value is an int, we can guess that that is stable. Further empirical observation would tell us what to do for other cases. 3. Wait for type-specialized arrays, which may just make this problem go away.
(In reply to comment #0) > > 3. Wait for type-specialized arrays, which may just make this problem go away. Yeah, I was about to pipe up and suggest that... :)
Obsolete with the removal of tracejit.