Hi Igor,

On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 22 September 2011 19:16, Eliot Miranda <eliot.miranda@gmail.com> 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 <marcus.denker@inria.fr>
> 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