[Pharo-project] recompiling class
krishnamachari.sudhakar at gmail.com
Mon Jun 11 01:17:08 EDT 2012
"decompile to an Intermediate Representation"
This will be nice to have backported if possible to 1.4.
On Sat, Jun 9, 2012 at 5:40 PM, Marcus Denker <marcus.denker at 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev