On 22 September 2011 19:16, Eliot Miranda <[email protected]> wrote: > (apologies for the duplicate reply; someone needs to sort out their > threading for the benefit of the community ;) ) > > On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker <[email protected]> > wrote: >> >> Hi, >> >> There are two changesets waiting for integrating in 1.4 that have serious >> consequences: >> >> - Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, >> but have not >> been integrated in the VMMaker codebase. >> >> http://code.google.com/p/pharo/issues/detail?id=4265 > > I would *really* like to back out these changes. The Ephemeron > implementation is very much a prototype, requiring a hack to determine > whether an object is an ephemeron (the presence of a marker class in the > first inst var) that I'm not at all happy with. There is a neater > implementation available via using an unused instSpec which IMO has > significant advantages (much simpler & faster, instSpec is valid at all > times, including during compaction, less overhead, doesn't require a marker > class), and is the route I'm taking with the new GC/object-representation > I'm working on now. Note that other than determining whether an object is > an ephemeron (instSpec/format vs inst var test) the rest of Igor's code > remains the same. I'd like to avoid too much VM forking. Would you all > consider putting these changes on hold for now? > If so, I'll make the effort to produce prototype changes (in the area of > ClassBuilder and class definition; no VM code necessary as yet) to allow > defining Ephemerons via the int spec route by next week at the latest. >
i agree that in my implementation this is a weak point. But its hard to do anything without making changes to object format to identify these special objects. The main story behind this is can we afford to change the internals of VM without being beaten hard by "backwards compatibility" party? :) Ephemerons are versatile way to get notifications of objects which are about to die, and there are certain parts in language which is hard (or even impossible) to implement without ephemerons. I got stuck with it earlier, when realized that we cannot afford to have weak subscriptions in announcement framework for blocks (which is most convenient and most easy way to define subscriptions) without having ephemerons. And of course, by having ephemerons we can completely review the weak finalization scheme and make it much simpler, and faster. I think we should do something in this regard, even at cost of backward compatibility. Because as to me it blocks us from moving forward. I wanted to remind to people, that it took me around a day to implement ephemerons in VM. And then few more days to actually make a correct implementation and write tests to cover it. Unfortunately, we yet don't have a well established process, which could make VM + language side changes to go in sync, when its required, and go much faster and don't fear to introduce/change functionality. One of the reasons for having a continuous integration setup for VM was exactly for that: having new VMs every day (comparing to having new VMs every year). >> >> - Finalization code checks for #hasNewFinalization >> This is true in the current VMs build in Jenkins, but in older VMs this >> is not in. >> >> http://code.google.com/p/pharo/issues/detail?id=4483 >> >> There are two options: >> >> a) integrate in >> b) not integrate it >> >> a) means that the image runs on older VMs, too. >> b) means we accept that we can never improve anything for real. >> >> There will be more changes coming... e.g. imagine we have a Vector >> Graphics Canvas >> as some point next year... what will we do? use it or not use it to stay >> compatible? >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.
