Drive by: since write barrier is conservative it's OK to mark smis. We've obviously considered checking for them here, and it makes no real difference (the disadvantage of extra check and branch in the non-smi case + increased write barrier size balances out skipping some memory reads on the next scavenge). What we have now is pretty carefully tuned.
You're welcome to reconsider, but I would say that scavenge times right now are pretty manageable and not something to worry about too much. Code size, on the other hand, is something to worry about a bit. On Mon, Nov 9, 2009 at 9:02 AM, <[email protected]> wrote: > > > http://codereview.chromium.org/360054/diff/5005/4009 > File src/arm/fast-codegen-arm.cc (right): > > http://codereview.chromium.org/360054/diff/5005/4009#newcode828 > Line 828: __ tst(r0, Operand(kSmiTagMask)); > On 2009/11/09 09:27:17, fschneider wrote: > > Do we have to test for SMI before the write barrier here? We don't do > this in > > all cases where we emit the write barrier. > > Maybe this is an optimization we may want to add later? > > Added comment explaining this. We should add the smi check to > RecordWrite. > > http://codereview.chromium.org/360054 > > > > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
