Hi Igor, On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <[email protected]> wrote:
> 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? :) > I don't think we get stuck in this at all. The instSpec/format field has an unused value (5 i believe) and this can easily be used for Ephemerons. All that is needed is a little image work on these methods: Behavior>>typeOfClass needs to answer e.g. #ephemeron for ephemeron classes ClassBuilder>>computeFormat:instSize:forSuper:ccIndex: needs to accept e.g. #ephemeron for type and pass variable: false and weak: true for ephemerons to format:variable:words:pointers:weak:. ClassBuilder>>format:variable:words:pointers:weak: needs to respond to variable: false and weak: true by computing the ephemeron instSpec. Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: need siblings, e.g. ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: Right? This is easy. Then in the VM there are a few places where pointer indexability (formats 3 and 4) need to be firmed up to exclude 5, but nothing difficult. We talked about this in email last week. > > 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. > > -- best, Eliot
