[squeak-dev] Can we extract type information from the VM?

Florin Mateoc florin.mateoc at gmail.com
Sun Sep 15 17:58:19 UTC 2013

On 9/15/2013 1:06 PM, Frank Shearar wrote:
> On 15 September 2013 17:38, Florin Mateoc <florin.mateoc at gmail.com> wrote:
>> On 9/15/2013 11:47 AM, Frank Shearar wrote:
>>> On 15 Sep 2013, at 14:57, Florin Mateoc <florin.mateoc at gmail.com> wrote:
>>>> On 9/15/2013 5:54 AM, Frank Shearar wrote:
>>>>> I was rereading Phlip's "what's wrong with our IDEs" post -
>>>>> http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html
>>>>> - and realised that he's just verbalised something I've only
>>>>> half-thought.
>>>>> When we run our tests (because of course we're using TDD) we know the
>>>>> precise types/expected classes of everything, because the VM
>>>>> automatically collects (or can collect) this information.
>>>>> But how do we get that information out of the VM?
>>>>> frank
>>>> You don't need to extract it from the VM, you can have a type profiler that collects it for you in the image.
>>> Doesn't that just mean twice as much work? The VM of necessity has already typed the call sites (even if the typing is only eventually correct). Why could a mirror not expose the typing thus far?
>>> frank
>>>> Florin
>> Doing it in the image means you do it in Smalltalk. Extracting it from the VM means you are doing it in C/assembly.
>> And I definitely do not understand the argument with twice as much work. Work for whom? For the computer? Well, that's
>> its job. As the developer, you only do it once, regardless which option you chose. I prefer doing it in Smalltalk
> Well, someone  has to write the code to collect and extract the information.
> Unless I've completely misunderstood you, you're saying I should build
> an interpreter within which to run my tests, and that collects this
> type information. I'm saying that the VM has to do this _already_ and
> exposing this information to the image (through a mirror or similar)
> means that (a) you get accurate type information and (b) you don't
> have to write an interpreter.
> How would a type profiler collect information at least as accurately
> as the VM already does?
> frank

No, I did  not mean an interpreter, but using the existing sampling profiler infrastructure, to which an additional kind
of profiler can easily be added (in addition to timing and allocation profilers). I did such an exercise in VW.
As for accuracy, how can a profiler collect less accurate type information for the same run of the same code? (Well, of
course, you have to take care of proxies and such). Worst case, for short-running methods and if you don't want to wait
for multiple runs (therefore the type information could be incomplete), you can use method wrappers and do an exact


More information about the Squeak-dev mailing list