Smalltalk › Squeak › Squeak - Dev

extracting BlockClosures from CompiledMethods

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Michael Haupt-3

extracting BlockClosures from CompiledMethods

Dear all,

CompiledMethod allInstances detect: [ :m | m containsBlockClosures ]

finds no CompiledMethod containing a BlockClosure. (Can't be right, can it?)

Delving further into this, it seems the methods in the "closures"
protocol of CompiledMethod are all broken. Is that correct?

Best,

Michael

Michael Haupt-3

Re: extracting BlockClosures from CompiledMethods

Hi again,

On Tue, Sep 21, 2010 at 10:09 AM, Michael Haupt <[hidden email]> wrote:
> CompiledMethod allInstances detect: [ :m | m containsBlockClosures ]
> finds no CompiledMethod containing a BlockClosure. (Can't be right, can it?)
>
> Delving further into this, it seems the methods in the "closures"
> protocol of CompiledMethod are all broken. Is that correct?

having looked at things a bit more, it seems that most of the
"closures" protocol is obsolete:

* allEmbeddedBlockMethods - no senders, only marked as a failing test
* embeddedBlockMethods - no senders, only marked as a failing test
* isBlockMethod, isBlockMethod: - no senders
* containsBlockClosures - no senders (and a non-working implementation)
* method - there are many senders of #method, but I'm not sure if
CompiledMethods are receivers
* remoteReturns - no senders
* searchImageForHomeMethod - no senders save itself (recursive)

I am going to upload some things to the Inbox in a few minutes that do
the following:

* remove most of the "obsolete" methods above,
* prototypical implementation of embeddedBlockMethods that makes
containsBlockClosures work again
* some few tests (extension of CompiledMethodTest)

Please comment. I'm not sure the implementation is (a) sound or (b)
sensible. :-)

Best,

Michael

Eliot Miranda-2

Re: extracting BlockClosures from CompiledMethods

Hi Michael,

yes, all of this protocol is obsolete. Look at the methods in 'debugger support' for relevant stuff. if you are in the mood to implement useful stuff here we could do with an efficient method that tells if a context is at the end of its block or method. For a method activation that's easy, pc >= method endPC. But for a block activation one has to parse the block creation bytecode to find out how bit the block is (that's going to be far faster than scanning). This is useful in implementing e.g. Process>>isTerminated.

On Tue, Sep 21, 2010 at 4:46 AM, Michael Haupt <[hidden email]> wrote:

Hi again,

On Tue, Sep 21, 2010 at 10:09 AM, Michael Haupt <[hidden email]> wrote:
> CompiledMethod allInstances detect: [ :m | m containsBlockClosures ]
> finds no CompiledMethod containing a BlockClosure. (Can't be right, can it?)
>
> Delving further into this, it seems the methods in the "closures"
> protocol of CompiledMethod are all broken. Is that correct?

having looked at things a bit more, it seems that most of the
"closures" protocol is obsolete:

* allEmbeddedBlockMethods - no senders, only marked as a failing test
* embeddedBlockMethods - no senders, only marked as a failing test
* isBlockMethod, isBlockMethod: - no senders
* containsBlockClosures - no senders (and a non-working implementation)
* method - there are many senders of #method, but I'm not sure if
CompiledMethods are receivers
* remoteReturns - no senders
* searchImageForHomeMethod - no senders save itself (recursive)

I am going to upload some things to the Inbox in a few minutes that do
the following:

* remove most of the "obsolete" methods above,
* prototypical implementation of embeddedBlockMethods that makes
containsBlockClosures work again
* some few tests (extension of CompiledMethodTest)

Please comment. I'm not sure the implementation is (a) sound or (b)
sensible. :-)

Best,

Michael

Eliot Miranda-2

Re: extracting BlockClosures from CompiledMethods

In reply to this post by Michael Haupt-3

Hi Michael,

here are a few cleanups for the block locating/numbering facilities. You can implement e.g. CompiledMethod>>containsBlockClosures as

containsBlockClosures

^self startpcsToBlockExtents size > 1

The startpcsToBlockExtents and support methods would also have to move into accessing and private out of debugger support.

HTH,

Eliot

On Tue, Sep 21, 2010 at 4:46 AM, Michael Haupt <[hidden email]> wrote:

Hi again,

On Tue, Sep 21, 2010 at 10:09 AM, Michael Haupt <[hidden email]> wrote:
> CompiledMethod allInstances detect: [ :m | m containsBlockClosures ]
> finds no CompiledMethod containing a BlockClosure. (Can't be right, can it?)
>
> Delving further into this, it seems the methods in the "closures"
> protocol of CompiledMethod are all broken. Is that correct?

having looked at things a bit more, it seems that most of the
"closures" protocol is obsolete:

* allEmbeddedBlockMethods - no senders, only marked as a failing test
* embeddedBlockMethods - no senders, only marked as a failing test
* isBlockMethod, isBlockMethod: - no senders
* containsBlockClosures - no senders (and a non-working implementation)
* method - there are many senders of #method, but I'm not sure if
CompiledMethods are receivers
* remoteReturns - no senders
* searchImageForHomeMethod - no senders save itself (recursive)

I am going to upload some things to the Inbox in a few minutes that do
the following:

* remove most of the "obsolete" methods above,
* prototypical implementation of embeddedBlockMethods that makes
containsBlockClosures work again
* some few tests (extension of CompiledMethodTest)

Please comment. I'm not sure the implementation is (a) sound or (b)
sensible. :-)

Best,

Michael

CM-blockExtentCleanups.st (3K) Download Attachment

Eliot Miranda-2

Re: extracting BlockClosures from CompiledMethods

Oops, there's a slip in the changes. Fixed version attached.

On Tue, Sep 21, 2010 at 10:40 AM, Eliot Miranda <[hidden email]> wrote:

Hi Michael,

here are a few cleanups for the block locating/numbering facilities. You can implement e.g. CompiledMethod>>containsBlockClosures as

containsBlockClosures

^self startpcsToBlockExtents size > 1

The startpcsToBlockExtents and support methods would also have to move into accessing and private out of debugger support.

HTH,
Eliot

On Tue, Sep 21, 2010 at 4:46 AM, Michael Haupt <[hidden email]> wrote:

Hi again,

On Tue, Sep 21, 2010 at 10:09 AM, Michael Haupt <[hidden email]> wrote:
> CompiledMethod allInstances detect: [ :m | m containsBlockClosures ]
> finds no CompiledMethod containing a BlockClosure. (Can't be right, can it?)
>
> Delving further into this, it seems the methods in the "closures"
> protocol of CompiledMethod are all broken. Is that correct?

having looked at things a bit more, it seems that most of the
"closures" protocol is obsolete:

* allEmbeddedBlockMethods - no senders, only marked as a failing test
* embeddedBlockMethods - no senders, only marked as a failing test
* isBlockMethod, isBlockMethod: - no senders
* containsBlockClosures - no senders (and a non-working implementation)
* method - there are many senders of #method, but I'm not sure if
CompiledMethods are receivers
* remoteReturns - no senders
* searchImageForHomeMethod - no senders save itself (recursive)

I am going to upload some things to the Inbox in a few minutes that do
the following:

* remove most of the "obsolete" methods above,
* prototypical implementation of embeddedBlockMethods that makes
containsBlockClosures work again
* some few tests (extension of CompiledMethodTest)

Please comment. I'm not sure the implementation is (a) sound or (b)
sensible. :-)

Best,

Michael

CM-blockExtentCleanups.st (3K) Download Attachment

Michael Haupt-3

Re: extracting BlockClosures from CompiledMethods

In reply to this post by Eliot Miranda-2

Hi Eliot,

thanks for your input. See below for some progress (?).

On Tue, Sep 21, 2010 at 6:55 PM, Eliot Miranda <[hidden email]> wrote:
> if you are in the mood to implement useful
> stuff here we could do with an efficient method that tells if a context is
> at the end of its block or method. For a method activation that's easy, pc
>>= method endPC. But for a block activation one has to parse the block
> creation bytecode to find out how bit the block is (that's going to be far
> faster than scanning). This is useful in implementing e.g.
> Process>>isTerminated.

I just inboxed KernelTests-mha.164 and Kernel-mha.499 - please take a
look at the implementations of BlockClosure >> #size and MethodContext
>> #atEnd. Is that what you meant? (Please give feedback - it might be
wrong code.)

Apart from these two methods, Kernel-mha.499 moves two of the block
extent methods from debugger support to accessing and private
protocols in CompiledMethod.

I'd still like to get some feedback on CompiledMethod >>
#embeddedBlockMethods; this is a method I sorely need and that IMHO
would make a good extension to CompiledMethod's meta-programming
protocol (read: closures protocol). I'd rather see something like it
in CompiledMethod than in my development code.

Best,

Michael

Michael Haupt-3

Re: extracting BlockClosures from CompiledMethods

Hi again,

whoever out there is interested in CompiledMethod and its closures
protocol, please take a look at the inboxed KernelTests-mha.167 and
Kernel-mha.500. I'm hesitant to push this to trunk because it's really
core stuff and someone else should look at it.

Best,

Michael