[Pharo-project] recompiling class

Marcus Denker marcus.denker at inria.fr
Sat Jun 9 08:10:38 EDT 2012

On Jun 9, 2012, at 8:26 AM, S Krish wrote:

> Can we do this in Pharo:
> "in Java, the computation of numeric offsets for instance elds in memory is done by
> the run-time system. This permits updating a class with new instance elds or methods without
> affecting 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."


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...

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 Denker -- http://marcusdenker.de

More information about the Pharo-dev mailing list