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 file 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 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 file 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 <[hidden email]> wrote:
and how long does recompiling all Morph methods take? Marcus, I'm eager to port your code to Squeak. Would that be OK?
best, Eliot |
In reply to this post by Marcus Denker-4
"decompile to an Intermediate Representation" On Sat, Jun 9, 2012 at 5:40 PM, Marcus Denker <[hidden email]> wrote:
|
In reply to this post by Eliot Miranda-2
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 |
In reply to this post by S Krish
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 <[hidden email]> 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" |
In reply to this post by Marcus Denker-4
On 11 June 2012 09:26, Marcus Denker <[hidden email]> 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. |
In reply to this post by Tudor Girba-2
+ 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 <[hidden email]> 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" > |
Administrator
|
Yippppppppppie!!!!!
Cheers,
Sean |
>> Soon we will be able to remove FileDirectory :) > > Yippppppppppie!!!!! even more than that :) |
In reply to this post by Marcus Denker-4
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 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 file 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 |
In reply to this post by Igor Stasenko
> On 11 June 2012 09:26, Marcus Denker <[hidden email]> 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 -- [hidden email] http://www.marcusdenker.de |
Free forum by Nabble | Edit this page |