Unsent selectors in CompiledMethod
Locked
Unsent selectors in CompiledMethod
 
|
Hello guys,
there are few unsent messages on class side of CompiledMethod, primitive: primNum numArgs: numArgs numTemps: numTemps stackSize: stackSize literals: literals bytecodes: bytecodes trailer: trailerBytes and newBytes: numberOfBytes trailerBytes: trailer nArgs: nArgs nTemps: nTemps nStack: stackSize nLits: nLits primitive: primitiveIndex flag: flag I checked both in Pharo 1.1-core and in Trunk images, both of them seem having no senders. Any insights if it safe to wipe them out? -- Best regards, Igor Stasenko AKA sig. |
Re: Unsent selectors in CompiledMethod
|
|
I would keep CompiledMethod class>>primitive:numArgs:numTemps:stackSize:literals:bytecodes:trailer:, it has some abstraction that could be useful for e.g. tests. I like the assurance that CompiledMethod flag is zero, and so am happy to sere that deleted. e.g. Cog has a mode controlled by vmParameterAt:put: where it will set the flag bits of methods that are interpreted. Craig has code in his spoon VM which sets the flag for used methods. I would like to reserve the bit for introspective tasks like these, and for these it is convenient that all methods have a zero flag bit.
cheers Eliot
On Sun, Dec 13, 2009 at 8:05 AM, Igor Stasenko <[hidden email]> wrote: Hello guys, |
Re: Unsent selectors in CompiledMethod
|
|
2009/12/13 Eliot Miranda <[hidden email]>:
> I would keep CompiledMethod > class>>primitive:numArgs:numTemps:stackSize:literals:bytecodes:trailer:, it > has some abstraction that could be useful for e.g. tests. I like the > assurance that CompiledMethod flag is zero, and so am happy to sere that > deleted. e.g. Cog has a mode controlled by vmParameterAt:put: where it will > set the flag bits of methods that are interpreted. Craig has code in his > spoon VM which sets the flag for used methods. I would like to reserve the > bit for introspective tasks like these, and for these it is convenient that > all methods have a zero flag bit. > cheers Thanks for explanation. Should we put that in method's comment? What about second one? > Eliot > > On Sun, Dec 13, 2009 at 8:05 AM, Igor Stasenko <[hidden email]> wrote: >> >> Hello guys, >> >> there are few unsent messages on class side of CompiledMethod, >> >> primitive: primNum numArgs: numArgs numTemps: numTemps stackSize: >> stackSize literals: literals bytecodes: bytecodes trailer: >> trailerBytes >> and >> newBytes: numberOfBytes trailerBytes: trailer nArgs: nArgs nTemps: >> nTemps nStack: stackSize nLits: nLits primitive: primitiveIndex flag: >> flag >> >> I checked both in Pharo 1.1-core and in Trunk images, both of them >> seem having no senders. >> >> Any insights if it safe to wipe them out? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Unsent selectors in CompiledMethod
|
|
In reply to this post by Igor Stasenko
Let me try and be more coherent.
I would keep CompiledMethod class>>primitive:numArgs:numTemps:stackSize:literals:bytecodes:trailer:, it has some abstraction that could be useful for e.g. tests. But I am happy to delete CompiledMethod class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive:flag:. I like the assurance that CompiledMethod flag is zero, and so am happy to sere that deleted. e.g. Cog has a mode controlled by vmParameterAt:put: where it will set the flag bits of methods that are interpreted. Craig has code in his spoon VM which sets the flag for used methods. I would like to reserve the bit for introspective tasks like these, and for these it is convenient that all methods have a zero flag bit. cheers Eliot On Sun, Dec 13, 2009 at 8:05 AM, Igor Stasenko <[hidden email]> wrote: Hello guys, |
Re: Unsent selectors in CompiledMethod
|
|
In reply to this post by Igor Stasenko
On Sun, Dec 13, 2009 at 1:53 PM, Igor Stasenko <[hidden email]> wrote: 2009/12/13 Eliot Miranda <[hidden email]>: Good idea.
I want to keep CompiledMethod class>>primitive:numArgs:numTemps:stackSize:literals:bytecodes:trailer: because it provides a reasonable way of creating methods that I could imagine being used in e.g. test or a ClassBuilder that doesn't recompile when shape changing but instead disassembles and reassembles (as the VisualWorks one does).
BTW, anyone wanting something worthwhile to work on could choose this. The idea is for the ClassBuilder to only update methods that access instance variables.and do it without compiling from source, which is both faster and removes run-=time dependency on exotic compilers. The ClassBuilder would scan for methods that access instance variables, disassemble these to some sort of symbolic bytecode, and reassemble them with updated inst var refs. If this has already been done, e.g. in the context of the NewCompiler, then it is still worth-while making this work in Squeak trunk and Pharo.
cheers
Eliot
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |