On Wed, Feb 11, 2015 at 12:54 AM, Malek Musleh <malek.mus...@gmail.com> wrote:
> Could you pinpoint the location (highest level routine) where the IC > is accessed, and thus determined if its a hit/miss. There is no such location. That's kind of the point of having ICs. C++ code is only called when the generated handler that's been installed previously can't handle something. This event is called an "IC miss". > That way, I can > create my own flag/statistic to determine the miss ratio. > > Looking at the code, I see that an IC_Miss from ic/ic.cc is invoked > from is-<arch>.cc > from the ::GenerateMiss routine, one for each IC. Not quite. GenerateMiss doesn't *invoke* IC_Miss. It generates code that *will *invoke the miss handler (hence the name *Generate*Miss). > However, its not > clear to me from where GenerateMiss is called, that I can determine > hit/miss. In other words, I am looking for something like > > if(hit) { > return; > } else { > GenerateMiss() > } > > Rather, what I see is something like the following code snippet where > GenerateMiss() is called after __bind() and after a ret(). In this > case, I presume it would be a hit if it did actually call Ret() and > not continue down to __bind() & GenerateMiss() > > > void StoreIC::GenerateNormal(MacroAssembler* masm) { > Label miss; > Register receiver = StoreDescriptor::ReceiverRegister(); > Register name = StoreDescriptor::NameRegister(); > Register value = StoreDescriptor::ValueRegister(); > Register dictionary = r3; > DCHECK(receiver.is(r1)); > DCHECK(name.is(r2)); > DCHECK(value.is(r0)); > > __ ldr(dictionary, FieldMemOperand(receiver, > JSObject::kPropertiesOffset)); > > GenerateDictionaryStore(masm, &miss, dictionary, name, value, r4, r5); > Counters* counters = masm->isolate()->counters(); > __ IncrementCounter(counters->store_normal_hit(), 1, r4, r5); > __ Ret(); > > __ bind(&miss); > __ IncrementCounter(counters->store_normal_miss(), 1, r4, r5); > GenerateMiss(masm); > } > > On Tue, Feb 10, 2015 at 5:27 PM, Jakob Kummerow <jkumme...@chromium.org> > wrote: > > There is no tracing for IC hits. > > > > With a few exceptions, every line of --trace-ic output indicates one IC > > miss. > > > > With a few exceptions, every IC that misses will be patched. > > > > More specifically: > > > > On Tue, Feb 10, 2015 at 6:02 PM, Malek Musleh <malek.mus...@gmail.com> > > wrote: > >> > >> 1) > >> So I presume where it prints "patching.." indicates an IC miss: > >> > >> [CompareIC in ~ConfigureTemplateInstance+1367 at native apinatives.js:68 > >> ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(SMI+SMI=SMI))#LT @ > >> 0x28b1cf730d01] > > > > > > This line means that a CompareIC missed and was patched (from > UNINITIALIZED > > to SMI state). > > > >> > >> [ patching ic at 0x28b1cf762ff3, test=0x28b1cf762ff7, delta=21 > > > > > > "[ patching ic at ...]" is the line that's printed when an "inline smi > > case" is patched. That's a special performance improvement for some > kinds of > > ICs. > > > >> 2) > >> And to see a IC hit would be something like a CompareIC followed > directly > >> by a LoadIC? > >> > >> [CompareIC in ~Instantiate+171 at native apinatives.js:14 > >> ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(SMI+SMI=SMI))#EQ_STRICT @ > >> 0x28b1cf7611c1] > > > > > > This is a CompareIC miss + patch. > > > >> > >> [LoadIC in ~Instantiate+291 at native apinatives.js:15 (0->.) > >> 0x1b54a19209c9 <String[19]: InstantiateFunction>] > > > > > > This is a LoadIC miss + patch. > > > >> > >> [LoadIC in ~InstantiateFunction+53 at native apinatives.js:32 (0->.) > >> 0x1b54a1922131 <String[17]: kApiFunctionCache>] > > > > > > This is another LoadIC miss + patch. > > > >> 3) > >> > >> Are there cases where there is an IC miss, but the IC does not get > >> patched? > > > > > > Not in the snippet below. When you see an "N->N" transition, the IC > wasn't > > actually patched, there was only a new handler getting compiled and > added to > > the stub cache (which has the same effect as patching insofar as it will > > avoid future misses for the same situation). > > > >> short snippit below: > >> > >> [ToBooleanStub: (None)=>(Bool)] > >> [CompareIC in ~Instantiate+171 at native apinatives.js:14 > >> ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(SMI+SMI=SMI))#EQ_STRICT @ > >> 0x28b1cf7611c1] > >> [LoadIC in ~Instantiate+291 at native apinatives.js:15 (0->.) > >> 0x1b54a19209c9 <String[19]: InstantiateFunction>] > >> [LoadIC in ~InstantiateFunction+53 at native apinatives.js:32 (0->.) > >> 0x1b54a1922131 <String[17]: kApiFunctionCache>] > >> [ToBooleanStub: (None)=>(Bool)] > >> [ToBooleanStub: (None)=>(Bool)] > >> [BinaryOpIC(BIT_AND:None*None->None) => (BIT_AND:Smi*Smi->Smi) @ > >> 0x28b1cf708941 <- ~InstantiateFunction+453 at native apinatives.js:40] > >> [ToBooleanStub: (None)=>(Smi)] > >> [LoadIC in ~InstantiateFunction+607 at native apinatives.js:43 (0->.) > >> 0x1b54a1922679 <String[11]: Instantiate>] > >> [CompareIC in ~Instantiate+223 at native apinatives.js:16 > >> ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(SMI+SMI=SMI))#EQ_STRICT @ > >> 0x28b1cf7611c1] > >> [LoadIC in ~Instantiate+542 at native apinatives.js:23 (0->.) > >> 0x1b54a1922679 <String[11]: Instantiate>] > >> [LoadIC in ~Instantiate+291 at native apinatives.js:15 (.->1) > >> 0x1b54a19209c9 <String[19]: InstantiateFunction>] > >> [LoadIC in ~InstantiateFunction+53 at native apinatives.js:32 (.->1) > >> 0x1b54a1922131 <String[17]: kApiFunctionCache>] > >> [BinaryOpIC(BIT_AND:None*None->None) => (BIT_AND:Smi*Smi->Smi) @ > >> 0x28b1cf708941 <- ~InstantiateFunction+978 at native apinatives.js:52] > >> [ToBooleanStub: (None)=>(Smi)] > >> [KeyedStoreIC in ~InstantiateFunction+1018 at native apinatives.js:53 > >> (0->1.GROW) 6] > >> [LoadIC in ~InstantiateFunction+1037 at native apinatives.js:54 (0->.) > >> 0x1b54a1928339 <String[25]: ConfigureTemplateInstance>] > >> [ToBooleanStub: (None)=>(Undefined)] > >> [ToBooleanStub: (None)=>(Smi)] > >> [KeyedLoadIC in ~InstantiateFunction+1198 at native apinatives.js:61 > >> (0->1) 6] > >> [ToBooleanStub: (Undefined)=>(Undefined,SpecObject)] > >> [KeyedLoadIC in ~ConfigureTemplateInstance+1336 at native > apinatives.js:68 > >> (0->1) 0] > >> [CompareIC in ~ConfigureTemplateInstance+1367 at native apinatives.js:68 > >> ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(SMI+SMI=SMI))#LT @ > >> 0x28b1cf730d01] > >> [ patching ic at 0x28b1cf762ff3, test=0x28b1cf762ff7, delta=21 > >> > >> On Tuesday, February 10, 2015 at 4:12:06 AM UTC-5, Jakob Kummerow wrote: > >>> > >>> --trace-ic is the only IC tracing flag that I'm aware of. I've never > had > >>> the impression that it lacks coverage. Is there a specific kind of IC > miss > >>> events that you think it's not covering? > >>> > >>> > >>> On Tue, Feb 10, 2015 at 12:55 AM, Malek Musleh <malek....@gmail.com> > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I was wondering if there is a way to trace, or count Inline Cache > Misses > >>>> when running a benchmark using v8 standalone. > >>>> I know there exists the --trace-ic flag, but I want to determine what > is > >>>> the IC miss rate, and specifically what is getting hit/missed. > >>>> > >>>> That traceflag does tell me when a IC entry is patched (due to an IC > >>>> miss) but that doesn't cover all instances of IC misses. > >>>> > >>>> Any help would be appreciated. > >>>> > >>>> Thanks, > >>>> > >>>> Malek > >>>> > >>>> -- > >>>> -- > >>>> v8-users mailing list > >>>> v8-u...@googlegroups.com > >>>> http://groups.google.com/group/v8-users > >>>> --- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "v8-users" group. > >>>> To unsubscribe from this group and stop receiving emails from it, send > >>>> an email to v8-users+u...@googlegroups.com. > >>>> For more options, visit https://groups.google.com/d/optout. > >>> > >>> > >> -- > >> -- > >> v8-users mailing list > >> v8-users@googlegroups.com > >> http://groups.google.com/group/v8-users > >> --- > >> You received this message because you are subscribed to the Google > Groups > >> "v8-users" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to v8-users+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > -- > > v8-users mailing list > > v8-users@googlegroups.com > > http://groups.google.com/group/v8-users > > --- > > You received this message because you are subscribed to a topic in the > > Google Groups "v8-users" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/v8-users/754yrynh8so/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > v8-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.