Subject: Re: queries concerning PIC Stats
From: Craig Chambers (chambers@cs.washington.edu)
Date: Wed Mar 29 2000 - 11:19:05 PST
Mayur Naik wrote:
>
> Hello
>
> I have 2 queries concerning PIC Stats:
>
> 1. Consider:
>
> 275: "<"[0](2) "0#<(@indexed[A],@indexed[A])" # 1 buckets, 1 methods
> 275 sequence:1 sequence:1 # 0x339b898
> }
>
> I have been assuming that sequence:1 is the run-time class of each argument of the < message. But sequence:1 happens to be an abstract class:
>
> abstract object sequence [`T] isa ordered_collection [T];
>
> Can you please tell me what exactly it represents?
In looking at the source code, this < message is a resend from within the
indexed version of < to the sequence version. The implementation uses the
directee objects (in this case sequence) as the objects to dispatch upon in the
implementation of the resend. This PIC isn't a normal dynamically dispatched
message, as only one target method is possible, and it's statically known when
compiling the program as a unit. Vortex with optimization will never generate
such PIC sites, as the resend will get compiled into a direct call, but it does
in unoptimized compilation. Unfortunately, there's no easy way to filter such
resend PICs out of the profile log, as it's generated currently. Fortunately,
resend sites are much less frequent than regular send sites, both statically and
dynamically.
>
> 2. Consider:
>
> 23: "="[0](2) "1#is_even(@int)" # 1 buckets, 1 methods
> 23 anon_int:0 anon_int:0 # 0x356f758 B
> }
>
> I have been assuming that the run-time class of each argument of the = message is 'int'. I hope that is fine.
It's actually an anonymous concrete child of the int template object. That's
what the anon_ prefix means, for this and all other cases (you see a lot of
anon_ prefixes in the profile log).
>
> Further, is it safe to consider such a message send (i.e., a message send for which a *single* target method is specified in the list of methods invoked for that message send in the profile data) in the experimental assessment of message dispatch implementations or is it better to ignore it since it might be inlined by some optimization? I have observed that such message sends significantly affect the frequency distribution of Class IDs. So, I need to know whether I should consider / ignore all of them or examine each and determine whether it can be inlined or not and accordingly ignore / consider it.
It depends on what you are trying to do. It's not the case that a message site
that had only a single receiver class (or tuple of classes) dynamically in a
particular profile run can be statically optimized via inlining. It may be that
the static analysis isn't smart enough to prove this, or that some other run of
the program would have different characteristics at that call site. Even
profile-guided receiver class prediction might not be applied, if the target
method isn't amenable to inlining.
>
> Thanks a lot for your time.
>
> -- Mayur
>
> HotBot - Search smarter.
> http://www.hotbot.com
-- Craig Chambers
This archive was generated by hypermail 2b25 : Tue Oct 03 2000 - 15:21:27 PDT