Hi Tim -

>> As much as I agree with the idea of reworking CompiledMethod in 
>> general, it seems to me we shouldn't mix up two otherwise unrelated 
>> issues.
> [snip]
> Yes, that is plausible and reasonable; except that I *do* think it is 
> way past time to do the CM rework and since to makes it trivial to also 
> clean up the source code representation I consider it a nice synergy. 

And it is. However, I question whether to put the two into the same bag. 
I think we can agree that whatever a new compiled method format will be 
like, it'll have a variable representing the source code reference. If 
we know that, then we can discuss what the source reference should 
represent. And that's really all that this discussion should be about.

Having said that, I don't claim that Klaus' proposal is the one that 
necessarily should be adopted - I like it because it's the simplest 
thing I could imagine for starters and it's not so alien that all of the 
client code needs to be changed. That said, there *is* room for 
discussing the alternatives, and if you're unhappy with Klaus' proposal, 
by all means, propose some alternative. All I'm asking for is that we 
don't mix it with the CompiledMethod discussion.

> As I said, Klaus is to be congratulated for coming up with a concrete 
> proposal. I don't think it cleans up anywhere near enough of the mess, 
> but that could be worked on. For example, it appears to me to leave far 
> too much in the way of assumptions about the source pointer being an 
> encrypted integer for real comfort. I made a technically simple but 
> organisationally more complex proposal. It is what it is. If people 
> don't like it, they don't like it.

Well, in that case all I can say is: "Code speaks" ;-) If you still have 
that code from '98 and can update it to work with method properties I'd 
like to see it and I'd like us to have the discussion about which 
approach people like more.

> Perhaps it is not yet time to change the image format and break backward 
> compatability; then again, the 64bit images are not backward compatible, 
> the proposed 3.9 release requires a condensed changes and new sources 
> file (perhaps not if we adopt a source pointer cleanup?) and frankly the 
> place is in a mess that needs cleaning. I'm fairly amazed you haven't 
> been clamouring for such a cleanup for the OLPC work.

We're steering a deliberately conservative course on OLPC. Right now our 
(effectively only) priority is to make sure that eToys work well and 
that we're on track for the first batch of machines. Because of that, 
concerns regarding the representation of source pointers get little 
attention and unless there is some major, major speedup I would veto any 
changes to CompiledMethod for OLPC simply on general principles. We have 
enough issues to deal with as things stand, there is no reason to create 
a bunch of new ones. That's not to say that we shouldn't do the work, 
but OLPC is simply not the place to debug the issues surrounding it.

Cheers,
   - Andreas