On 03.03.2010 22:21, Alexandre Bergel wrote:
>> The paper talks about using stack pointer and program counter as
>> identifiers, I doubt stack depth as returned by such a method will
>> provide a good enough granularity to do proper disambiguation.
>> (not to mention the main reason for using the
> The paper talks about using stack pointer and program counter as
> identifiers, I doubt stack depth as returned by such a method will
> provide a good enough granularity to do proper disambiguation.
> (not to mention the main reason for using them is that they can be
> gotten with virtually no ov
On 03.03.2010 21:35, Alexandre Bergel wrote:
> Indeed. Thanks!
>
>
>> This is more than twice as fast, though it may be still too slow for
>> your
>> needs:
>>
>> | depth running |
>> running := thisContext.
>> depth := 1.
>> [ (running := running instVarAt: 1) == nil ]
>>
Indeed. Thanks!
> This is more than twice as fast, though it may be still too slow for
> your
> needs:
>
> | depth running |
> running := thisContext.
> depth := 1.
> [ (running := running instVarAt: 1) == nil ]
> whileFalse: [ depth := depth + 1 ].
>
On Tue, 2 Mar 2010, Alexandre Bergel wrote:
>> Well it seems rather special purpose. What are you using it for?
>> Why is the cost impacting your work?
>
> There is an excellent paper at oopsla'09 that shows the method call
> graph can be effectively inferred using the method call stack depth:
>
On Mar 3, 2010, at 1:34 AM, Alexandre Bergel wrote:
>> Well it seems rather special purpose. What are you using it for?
>> Why is the cost impacting your work?
>
> There is an excellent paper at oopsla'09 that shows the method call
> graph can be effectively inferred using the method call stac
On Tue, Mar 2, 2010 at 4:34 PM, Alexandre Bergel wrote:
> > Well it seems rather special purpose. What are you using it for?
> > Why is the cost impacting your work?
>
> There is an excellent paper at oopsla'09 that shows the method call
> graph can be effectively inferred using the method call st
Ah, well if you can build your own VM, then it would be easy to add as a named
primitive.
On 2010-03-02, at 4:34 PM, Alexandre Bergel wrote:
>> Well it seems rather special purpose. What are you using it for?
>> Why is the cost impacting your work?
>
> There is an excellent paper at oopsla'09
> Well it seems rather special purpose. What are you using it for?
> Why is the cost impacting your work?
There is an excellent paper at oopsla'09 that shows the method call
graph can be effectively inferred using the method call stack depth:
http://www-plan.cs.colorado.edu/klipto/mytkowicz-oop
Well it seems rather special purpose. What are you using it for?
Why is the cost impacting your work?
On 2010-03-02, at 4:06 PM, Alexandre Bergel wrote:
> Will it be of any use for you? If yes, then I will do it.
>
> Alexandre
>
>
> On 2 Mar 2010, at 21:00, John M McIntosh wrote:
>
>> Maybe
Will it be of any use for you? If yes, then I will do it.
Alexandre
On 2 Mar 2010, at 21:00, John M McIntosh wrote:
> Maybe you could write a plugin/primitive to do the work?
>
> On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote:
>
>> Dear List,
>>
>> I was wondering whether there is a fast way
Maybe you could write a plugin/primitive to do the work?
On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote:
> Dear List,
>
> I was wondering whether there is a fast way to know the method call
> stack depth. Something like what follows does the job:
>
> -=-=-=-=-=-=-=-=-=-=-=-=
> | depth runn
Dear List,
I was wondering whether there is a fast way to know the method call
stack depth. Something like what follows does the job:
-=-=-=-=-=-=-=-=-=-=-=-=
| depth running |
depth := 0.
running := thisContext.
[ running sender notNil ] whileTrue: [ running := running sender.
depth := depth
13 matches
Mail list logo
