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?
- 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 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) - 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. 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
