About 512 MB changes patch
andreas.raab at gmx.de
Tue Oct 3 03:18:41 UTC 2006
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
> 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.
More information about the Squeak-dev