On Mon, 4 Jan 2010, Igor Stasenko wrote:

> They make a difference.
> Actually, when coding the stuff, i was more concerned about #endPC
> than anything else,
> since now it will be calculated much slower, because trailer decoding
> the data , even if its not used by sender which might be interested in
> getting #endPC only.
> To optimize this, i though that maybe it worth to decode data lazily,
> while in #method: , calculate only size field.
> But i'm not sure, if it worth spending time optimizing it, since i'm
> not measured the impact.
>
> My nitpick was about workarounds in using #perform: with pregenerated
> selectors. Other changes, which
> focused on avoiding generating temporary trailer instance is
> definitely worth doing.

I didn't look at the code in detail until now and I think it would be 
better to use subclasses for dispatching. This means removing the kind 
variable and every existing trailerKind would have it's own subclass. 
The subclasses would have 3 responsibilites #kindAsByte (returns a 
constant) #encode and #decode (implement the kind specific 
encoding/decoding). The class side #trailerKinds method could be generated 
based on the #kindAsByte implementations. A single method could be used 
for dispatching like:
CompiledMethodTrailer class >> for: method

 	| flagByte |
 	flagByte := method at: method size.
 	^(self trailerKinds at: flagByte >> 2 + 1) new
 		method: method;
 		yourself

Where trailerKinds returns an Array with the subclasses.
What do you think?


Levente

>
>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>