About 512 MB changes patch
tim Rowledge
tim at rowledge.org
Mon Oct 2 21:57:15 UTC 2006
I've been looking at this code a while and whilst I congratulate
Klaus on his valiant attempt to solve the file size problem I think
we need to take a step back and try to clean things up a bit more.
The problem here is that we have an extraordinary mess in our source
pointer methods. It mostly stems from 'temporary' attempts to survive
the problems of having source pointed to by four bytes stuck to the
end of a nasty design of a hybrid object type that ought to have
disappeared in 1998 after I first wrote the code to convert them to
proper objects. If we stick any more patches on top of this nonsense
we are in danger of looking like a part decomposed ancient egyptian
mummy.
Let's spend a little time and effort working out what we would like
to end up with and then a way to get there from here.
I would like to propose a fairly complete overhaul of CompiledMethod
and its friends. Get rid of the hybrid object format (which would
simplify the gc code a little too) and define CMs as
bytecodes
literals
sourceaccess
methodClass
...whatever other properties are needed...
ie a plain object with named instance variables. A slight alternative
that might be considered is for the literals to be indexed vars
following the named ones (think OrderedCollection if this is not
familiar to you).
We would lose the algorithmic gymnastics about last literal is the
class, second to last is the properties, first is the recipe for
today's soup dish, etc.
The source code access would be through any object understanding a
small protocol along the lines of 'get source', 'setSourceTo:'
and .... err, I think that's it. Again, back in '98 I demonstrated a
system that used this and had example accessors that used a file, an
encoded file, a plain string, a compressed string and a damp string.
Using a database or a networked method source server or a connection
to another image which held the source in some other way would all be
possible.
The cost is a loss of backwards compatibility for the image. Maybe it
would be possible to make a vm that would run old images as well as
new ones but I suspect it would cost some performance and I'm sure it
would cost some tedious maintenance tax. You may not care about that
but *I* sure do! Maybe it would be better to just abandon the current
image lineage and jump ship to build this purely on top of Spoon?
Maybe nobody cares?
tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: SEXI: Sign EXtend Integer
More information about the Squeak-dev
mailing list
|