On Sat, Jun 9, 2012 at 5:10 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On Jun 9, 2012, at 8:26 AM, S Krish wrote:
Can we do this in Pharo:
"in Java, the computation of numeric o ffsets for instance elds in
memory is done by
the run-time system. This permits updating a class with new instance elds or methods without aff ecting existing code. In other words, it is possible to run an existing bytecode fi le for a subclass after updating and recompiling the class, but without recompiling the subclass."
Hello,
In Smalltalk, not only *new* instances get the changed class layout, but *all* existing ones are migrated.
There is always just one version of a class in the system, all instances are of that version.
Thus, if you add a instvar in a superclass, the iVar offsets of the subclasses have to be fixed. Right now this is done by recompiling the all subclasses, but you could be much more intelligent: filter for those methods that actually reference ivars and then don't recompile but just change the offset.
This "just" is more difficult than it seems: changing an offset can mean that the bytecode needed is larger (2 instead of 1), and that then means jump offsets need to be changed. Which in turn can mean that the larger jump needs more bytecode, too..
So in practice, the best is to decompile to an Intermediate Representation that is at the level of bytecode, yet abtracts away jumps and the decision of which bytecode exactly it used.
For the backend of Opal, I did some crude benchmark for Martin this week: Decompiling to IR and re-generating of all methods in Morph that access iVars takes 0.8 seconds...
and how long does recompiling all Morph methods take? Marcus, I'm eager to port your code to Squeak. Would that be OK?
We will add the IR backend to 2.0 soon and the new ClassBuilder will use it.
But in general, it would be nice to late-bind the offsets and just use names in the representation that a method is saved in.
Marcus
-- Marcus Denker -- http://marcusdenker.de
-- best, Eliot