Den 14. jun. 2010 20.08 skrev zaheer ahmad <[email protected]>: > Thank you for the reply. I have few followup questions > > - what is the overhead/drawbacks of going from init to monomorphic > state (i.e not having pre-monomorphic state). Is it extra memory for > the stubs or something else? >
On a web page there is a lot of code that gets run only once. This saves us the overhead of generating an IC for these cases. > > - megamorphic stubs does a hash lookup to find the matching receiver, > isn't this as costly as the normal lookup in the object? Also, there > I don't think so. You can try disabling the hash lookup and seeing how it performs. > is one global stub cache for megamorphic stub lookup, wouldnt it be > better to have one per object and faster branching based on map > comparision than lookup (possibly a simpler implementation for a less > common case) > Having a cache per object would cost a lot of memory and the hit rate would be lower since newly created objects would not be able to get hits in the cache. > - Full GC clears all the stubs. It would be useful for megamorphic > since they can promote to a monomorphic, but why to clear other stubs. > Not sure. Perhaps we should only clear the megamorphic stubs. > > please correct me on any of the above. > > Thank you, > Zaheer > > 2010/6/11 Søren Gjesse <[email protected]>: > > Monomorphic stubs will only be inserted in the code by patching generated > > code. When code for a property store (which is the case here) is > generated a > > miss call will initially be inserted thereby entering the runtime system. > > The second miss call will make the runtime system replace the miss call > with > > a call to the monomorphic stubs for the receiver and property name > actually > > present. This is object in the C++ code. The check in the generated code > for > > the monomorphic stubs ensures that the receiver has not changed and the > str > > instruction is still valid. If the receiver is changed the runtime system > > will be entered and the stub changed to a megamorphic one. > > Regards, > > Søren > > When a monomorphic stub is inserted somewhere in the generated code > > (monomorphic stub will only > > > > On Fri, Jun 11, 2010 at 13:37, zaheer ahmad <[email protected]> > wrote: > >> > >> Thanks. The first str seems to be doing that :). > >> > >> One more question, i couldnt quite follow how the below checks if the > >> map check fails, dont receiver_reg and object represent same object? > >> (or is it that they represent same when code is initially generated > >> but receiver reg object can change) > >> > >> __ ldr(scratch, FieldMemOperand(receiver_reg, HeapObject::kMapOffset)); > >> __ cmp(scratch, Operand(Handle<Map>(object->map()))); > >> > >> Thank You > >> Zaheer > >> > >> > >> 2010/6/11 Søren Gjesse <[email protected]>: > >> > The code generating this code is in stub-cache-arm.cc, > >> > method StubCompiler::GenerateStoreField(). In there there are comments > >> > on > >> > what is generated. The map is the hidden class, and you are right a > >> > separate > >> > stub is generated for each property/receiver combination. These > >> > monomorphic > >> > stubs are shared in the sense that they are stored in a cache where a > >> > lookup > >> > is done when a specific one is needed. Also the > megamorphic stubs (used > >> > in > >> > places where different names/receivers are seen) probes this cache for > a > >> > monomorphic stub to call before entering the runtime system. > >> > Regards, > >> > Søren > >> > > >> > On Fri, Jun 11, 2010 at 10:39, zaheer ahmad <[email protected]> > >> > wrote: > >> >> > >> >> hi, > >> >> > >> >> Iam looking at the arm assembly for a storeic monomorphic stub. its > >> >> not clear to me which step does direct access to the property and > also > >> >> where the hidden class is accessed (i assume the map somehow > >> >> represents the hidden class). could you pls give some pointers. > >> >> > >> >> Also assuming unique stub is generated for each property, much of the > >> >> code seems common checks, isnt it possible to share or am i wrong. > >> >> > >> >> thanks, > >> >> Zaheer > >> >> > >> >> kind = STORE_IC > >> >> ic_state = MONOMORPHIC > >> >> ic_in_loop = 0 > >> >> type = FIELD > >> >> name = c > >> >> Instructions (size = 116) > >> >> 0xf5ac5a00 0 e3110001 tst r1, #1 > >> >> 0xf5ac5a04 4 0a000014 beq +88 -> 92 (0xf5ac5a5c) > >> >> 0xf5ac5a08 8 e5113001 ldr r3, [r1, #-1] > >> >> 0xf5ac5a0c 12 e59fc054 ldr ip, [pc, #+84] ;; > >> >> object: 0xf5b26ae1 <Map> > >> >> 0xf5ac5a10 16 e153000c cmp r3, ip > >> >> 0xf5ac5a14 20 1a000010 bne +72 -> 92 (0xf5ac5a5c) > >> >> 0xf5ac5a18 24 e5810013 str r0, [r1, #+19] > >> >> 0xf5ac5a1c 28 e3100001 tst r0, #1 > >> >> 0xf5ac5a20 32 0a00000c beq +56 -> 88 (0xf5ac5a58) > >> >> 0xf5ac5a24 36 e3a02014 mov r2, #20 > >> >> 0xf5ac5a28 40 e20134ff and r3, r1, #-16777216 > >> >> 0xf5ac5a2c 44 e35304f6 cmp r3, #-167772160 > >> >> 0xf5ac5a30 48 0a000008 beq +40 -> 88 (0xf5ac5a58) > >> >> 0xf5ac5a34 52 e59fc030 ldr ip, [pc, #+48] > >> >> 0xf5ac5a38 56 e0812002 add r2, r1, r2 > >> >> 0xf5ac5a3c 60 e002200c and r2, r2, ip > >> >> 0xf5ac5a40 64 e1a02422 mov r2, r2, lsr #8 > >> >> 0xf5ac5a44 68 e1c1100c bic r1, r1, ip > >> >> 0xf5ac5a48 72 e5913008 ldr r3, [r1, #+8] > >> >> 0xf5ac5a4c 76 e3a0c001 mov ip, #1 > >> >> 0xf5ac5a50 80 e183321c orr r3, r3, ip, lsl r2 > >> >> 0xf5ac5a54 84 e5813008 str r3, [r1, #+8] > >> >> 0xf5ac5a58 88 e12fff1e bx lr > >> >> 0xf5ac5a5c 92 e59fc00c ldr ip, [pc, #+12] ;; code: > >> >> BUILTIN, StoreIC_Miss > >> >> 0xf5ac5a60 96 e12fff1c bx ip > >> >> 0xf5ac5a64 100 03000003 constant pool begin > >> >> 0xf5ac5a68 104 f5b26ae1 constant > >> >> 0xf5ac5a6c 108 00001fff constant > >> >> 0xf5ac5a70 112 f5b45280 constant > >> >> > >> >> > >> >> thanks, > >> >> Zaheer > >> >> > >> >> -- > >> >> v8-users mailing list > >> >> [email protected] > >> >> http://groups.google.com/group/v8-users > >> > > >> > -- > >> > v8-users mailing list > >> > [email protected] > >> > http://groups.google.com/group/v8-users > >> > >> -- > >> v8-users mailing list > >> [email protected] > >> http://groups.google.com/group/v8-users > > > > -- > > v8-users mailing list > > [email protected] > > http://groups.google.com/group/v8-users > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
