CompiledMethod source access cleanups, questions on #trailer etc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CompiledMethod source access cleanups, questions on #trailer etc

timrowledge
I'm trying to do a minimal cleanup on how compiled methods access  
source as stage one of getting towards a new compiled method format.  
So far it has been somewhat painful due in no small part to the  
horrors of how many bits of code explicitly assume the sources being  
in files.

I've moved all the source pointer stuff from the 'stick some extra  
bytes at the end of the method' approach to a 'have a proper oop in  
properties' one. This is nicer and will allow us to have 256Mb  
sources and changes files. Given the apparent propensity for the  
changes file to get overloaded with doit text (see recent mails on  
that problem) this might be quite useful! With further cleanups we  
can get away from the nasty assumption about files and use well  
encapsulated source accessors instead of excapsulated ones.

Right now I'm trying to do some cleanup of all the peripheral grunge  
to do with this change. For example the users of #trailer, #generate:  
etc. So far as I can work out new methods are compiled with a default  
trailer of #(0 0 0 0) and then the source pointer is set shortly  
after; this is easy to change. It looks like assorted recompiles use  
a shortcut of grabbing the old CM trailer bytes and passing those to  
#generate: directly. That I can change to grab source pointer and set  
in new CM instance.

The question I need to feel I have a good answer to is whether anyone  
is doing other nasty things with method trailers?  I hope not, I  
think not, but I'm not sure not.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DO: Deadstart Operator



Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod source access cleanups, questions on #trailer etc

stephane ducasse-2

On 14 oct. 06, at 02:30, tim Rowledge wrote:

> I'm trying to do a minimal cleanup on how compiled methods access  
> source as stage one of getting towards a new compiled method format.

Cool please keep doing that!!!!!


> So far it has been somewhat painful due in no small part to the  
> horrors of how many bits of code explicitly assume the sources  
> being in files.
>
> I've moved all the source pointer stuff from the 'stick some extra  
> bytes at the end of the method' approach to a 'have a proper oop in  
> properties' one. This is nicer and will allow us to have 256Mb  
> sources and changes files. Given the apparent propensity for the  
> changes file to get overloaded with doit text (see recent mails on  
> that problem) this might be quite useful! With further cleanups we  
> can get away from the nasty assumption about files and use well  
> encapsulated source accessors instead of excapsulated ones.
>
> Right now I'm trying to do some cleanup of all the peripheral  
> grunge to do with this change. For example the users of #trailer,  
> #generate: etc. So far as I can work out new methods are compiled  
> with a default trailer of #(0 0 0 0) and then the source pointer is  
> set shortly after; this is easy to change. It looks like assorted  
> recompiles use a shortcut of grabbing the old CM trailer bytes and  
> passing those to #generate: directly. That I can change to grab  
> source pointer and set in new CM instance.
>
> The question I need to feel I have a good answer to is whether  
> anyone is doing other nasty things with method trailers?  I hope  
> not, I think not, but I'm not sure not.

I hope not :)

Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod source access cleanups, questions on #trailer etc

David T. Lewis
In reply to this post by timrowledge
On Fri, Oct 13, 2006 at 05:30:05PM -0700, tim Rowledge wrote:
> encapsulated source accessors instead of excapsulated ones.

Excapsulation? Excellent word; it actually sounds like a rather
appealing design feature. I think I'll try putting this into
a powerpoint and see if I can use it to help sell a proposal
of some sort. I should think that any pitch that claims a high
level of excapulation, supported by metrics and a pyramid-shaped
conceptual diagram, would be a real winner.

Dave

p.s. At least one other person has thought of this before:
http://www.mail-archive.com/cfcdev@.../msg07200.html