On 22 September 2011 20:06, Eliot Miranda <
eliot.miranda@gmail.com> wrote:
> 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.
>