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. One issue is that of changing the source code representation from being four bytes in the compiled method to being a real object. The other one is to change CompiledMethod itself. The two are completely unrelated in my understanding - we could well have a better factored class CompiledMethod that uses four bytes at the end of the bytecodes to encode the source pointer and we can equally have a source object representation within the current CompiledMethods.
Mixing up these two just doesn't seem helpful to make in terms of being able to make progress. We now have a proposed solution for dealing with the source representation, I don't think there is any need to make this dependent on a complete overhaul of compiled method itself (in particular considering that there are some unanswered questions about speed/space tradeoffs in this area). And contrary, if someone would make the concrete proposal for a rework of CompiledMethod I would say let's not make this dependent on agreeing on a particular source code representation. In either case, both are valuable, yet independent problems to be solved. Mixing them up doesn't seem to add much value to the (already complicated) process of getting them adopted.
Cheers, - Andreas
tim Rowledge wrote:
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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SEXI: Sign EXtend Integer