[Pharo-project] recompiling class
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."
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... 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
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
On Jun 9, 2012, at 8:16 PM, Eliot Miranda wrote:
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?
on the same machine: 6.5 seconds. But of course that can be cut down by selecting for ivar access (to around half). More statistics: Bytecode to IR for the whole image: 4.5 seconds. BC->IR-BC: 12.7 seconds. (no install) Opal image (~57000 CompiledMethods) Not installing the methods yet... and of course nothing is profiled and optimized yet.
Marcus, I'm eager to port your code to Squeak. Would that be OK?
Yes! The first version will be (I think) portable. But future versions might use Pharo features. Compatibility is not the main goal. The whole point about improving the system is to then use the improvements. Else what's the point in improving anything? Marcus -- Marcus Denker -- http://marcusdenker.de
On 11 June 2012 09:26, Marcus Denker <marcus.denker@inria.fr> wrote:
The whole point about improving the system is to then use the improvements. Else what's the point in improving anything?
Hi, from Capt. Obvious :)
    Marcus
-- Marcus Denker -- http://marcusdenker.de
-- Best regards, Igor Stasenko.
On 11 June 2012 09:26, Marcus Denker <marcus.denker@inria.fr> wrote:
The whole point about improving the system is to then use the improvements. Else what's the point in improving anything?
Hi, from Capt. Obvious :)
The sad fact is that this is not obvious... far from it. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
"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@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...
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
On Jun 11, 2012, at 7:17 AM, S Krish wrote:
"decompile to an Intermediate Representation"
This will be nice to have backported if possible to 1.4.
IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short. Marcus -- Marcus Denker -- http://marcusdenker.de
+1. It is in your interest to get us to move to the latest version, and the best way to do it is to keep offering irresistible reasons :) Cheers, Doru On Mon, Jun 11, 2012 at 9:31 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jun 11, 2012, at 7:17 AM, S Krish wrote:
"decompile to an Intermediate Representation"
This will be nice to have backported if possible to 1.4.
IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short.
    Marcus
-- Marcus Denker -- http://marcusdenker.de
-- www.tudorgirba.com "Every thing has its own flow"
+ 1 and we are working on that :) Soon we will be able to remove FileDirectory :), will have Morph rendered in Athensâ¦. On Jun 11, 2012, at 9:45 AM, Tudor Girba wrote:
+1.
It is in your interest to get us to move to the latest version, and the best way to do it is to keep offering irresistible reasons :)
Cheers, Doru
On Mon, Jun 11, 2012 at 9:31 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Jun 11, 2012, at 7:17 AM, S Krish wrote:
"decompile to an Intermediate Representation"
This will be nice to have backported if possible to 1.4.
IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short.
Marcus
-- Marcus Denker -- http://marcusdenker.de
-- www.tudorgirba.com
"Every thing has its own flow"
Stéphane Ducasse wrote
Soon we will be able to remove FileDirectory :)
Yippppppppppie!!!!! -- View this message in context: http://forum.world.st/recompiling-class-tp4633989p4634388.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Marcus Denker-4 wrote
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.
Excepting Gemstone, which allows different versions to coexist, and can specify differing migration strategies for instances: http://www.gemstone.com/docs/GemStoneS/GemStone6X/6.5/GSS-ProgGuide-6.0.pdf ...Stan 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... 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 -- View this message in context: http://forum.world.st/recompiling-class-tp4633989p4634467.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (8)
-
Eliot Miranda -
Igor Stasenko -
Marcus Denker -
S Krish -
Sean P. DeNigris -
Stan Shepherd -
Stéphane Ducasse -
Tudor Girba