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
collection.

Florin