Special objects array - sometimes everybody cannot be special

>
> We have some contention for slots in the special objects array. The Alien
> package lays claim to slots 50 - 54, and Igor's improved finalization
> would like to use slot 50. The Alien claim predates the Finalizer claim
> (albeit only through an *Extentions in Alien-VMMaker-Support), and there
> may already be people running VMs that rely on these special object
> assignments. On the other hand, finalization is part of the core system,
> so it would have been nice to put ClassWeakFinalizer at slot 50, and the
> optional Alien assignments at 51 - 55.
>
> Would anyone object to the following allocation of slots in the special
> objects array? This would leave Alien mostly unaffected, but would require
> Igor's finalization improvements to put WeakFinalizer at position 55 in
> the special objects array, and it would require that the Alien override
> be pulled into the VMMaker package such that all VMs would have the Alien
> assignments in the special objects array (albeit unused in many cases).
> And recreateSpecialObjectsArray would need updates to match of course.
>
>        SelectorAttemptToAssign := 50.
>        "PrimErrTableIndex := 51. in Interpreter class>>initializePrimitiveErrorCodes"
>        ClassAlien := 52.
>        InvokeCallbackSelector := 53.
>        ClassUnsafeAlien := 54.
>        ClassWeakFinalizer := 55
>
> I seem to recall some discussion of a more flexible special objects
> registry, although I can't find it right now. Pointers welcome.
>

> On 25 May 2010 06:56, David T. Lewis <[hidden email]> wrote:
>>
>> We have some contention for slots in the special objects array. The Alien
>> package lays claim to slots 50 - 54, and Igor's improved finalization
>> would like to use slot 50. The Alien claim predates the Finalizer claim
>> (albeit only through an *Extentions in Alien-VMMaker-Support), and there
>> may already be people running VMs that rely on these special object
>> assignments. On the other hand, finalization is part of the core system,
>> so it would have been nice to put ClassWeakFinalizer at slot 50, and the
>> optional Alien assignments at 51 - 55.
>>
>> Would anyone object to the following allocation of slots in the special
>> objects array? This would leave Alien mostly unaffected, but would require
>> Igor's finalization improvements to put WeakFinalizer at position 55 in
>> the special objects array, and it would require that the Alien override
>> be pulled into the VMMaker package such that all VMs would have the Alien
>> assignments in the special objects array (albeit unused in many cases).
>> And recreateSpecialObjectsArray would need updates to match of course.
>>
>>        SelectorAttemptToAssign := 50.
>>        "PrimErrTableIndex := 51. in Interpreter class>>initializePrimitiveErrorCodes"
>>        ClassAlien := 52.
>>        InvokeCallbackSelector := 53.
>>        ClassUnsafeAlien := 54.
>>        ClassWeakFinalizer := 55
>>
>> I seem to recall some discussion of a more flexible special objects
>> registry, although I can't find it right now. Pointers welcome.
>>
>
> Ouch.. David, it seems like i used the different version of
> #recreateSpecialObjectsArray
> than yours.
>
> The tail of spl objects in Alien-Core package, found at  SqS/Alien
> looks like following:
>
>        newArray at: 50 put: #run:with:in:.
>        newArray at: 51 put: nil.
>        newArray at: 52 put: nil.
>        newArray at: 53 put: (self at: #Alien ifAbsent: []).
>        newArray at: 54 put: #invokeCallback:stack:registers:jmpbuf:.
>        newArray at: 55 put: (self at: #UnsafeAlien ifAbsent: []).
>
> So, i thought its not a problem to reserve the 51 slot for weak
> finalization, because it unused anyways.
>
> Also, maybe we could fill an unused/obsolete slot instead of allocating new one?
>  There are some:
>
>        newArray at: 23 put: nil.
>        newArray at: 41 put: nil.
>
>> Dave
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

>
> On 25 May 2010 06:56, David T. Lewis <[hidden email]> wrote:
> >
> > We have some contention for slots in the special objects array. The Alien
> > package lays claim to slots 50 - 54, and Igor's improved finalization
> > would like to use slot 50. The Alien claim predates the Finalizer claim
> > (albeit only through an *Extentions in Alien-VMMaker-Support), and there
> > may already be people running VMs that rely on these special object
> > assignments. On the other hand, finalization is part of the core system,
> > so it would have been nice to put ClassWeakFinalizer at slot 50, and the
> > optional Alien assignments at 51 - 55.
> >
> > Would anyone object to the following allocation of slots in the special
> > objects array? This would leave Alien mostly unaffected, but would require
> > Igor's finalization improvements to put WeakFinalizer at position 55 in
> > the special objects array, and it would require that the Alien override
> > be pulled into the VMMaker package such that all VMs would have the Alien
> > assignments in the special objects array (albeit unused in many cases).
> > And recreateSpecialObjectsArray would need updates to match of course.
> >
> > ?? ?? ?? ??SelectorAttemptToAssign := 50.
> > ?? ?? ?? ??"PrimErrTableIndex := 51. in Interpreter class>>initializePrimitiveErrorCodes"
> > ?? ?? ?? ??ClassAlien := 52.
> > ?? ?? ?? ??InvokeCallbackSelector := 53.
> > ?? ?? ?? ??ClassUnsafeAlien := 54.
> > ?? ?? ?? ??ClassWeakFinalizer := 55
> >
> > I seem to recall some discussion of a more flexible special objects
> > registry, although I can't find it right now. Pointers welcome.
> >
>
> Ouch.. David, it seems like i used the different version of
> #recreateSpecialObjectsArray
> than yours.
>
> The tail of spl objects in Alien-Core package, found at  SqS/Alien
> looks like following:
>
> newArray at: 50 put: #run:with:in:.
> newArray at: 51 put: nil.
> newArray at: 52 put: nil.
> newArray at: 53 put: (self at: #Alien ifAbsent: []).
> newArray at: 54 put: #invokeCallback:stack:registers:jmpbuf:.
> newArray at: 55 put: (self at: #UnsafeAlien ifAbsent: []).

>
> On Tue, May 25, 2010 at 08:19:43AM +0300, Igor Stasenko wrote:
>>
>> On 25 May 2010 06:56, David T. Lewis <[hidden email]> wrote:
>> >
>> > We have some contention for slots in the special objects array. The Alien
>> > package lays claim to slots 50 - 54, and Igor's improved finalization
>> > would like to use slot 50. The Alien claim predates the Finalizer claim
>> > (albeit only through an *Extentions in Alien-VMMaker-Support), and there
>> > may already be people running VMs that rely on these special object
>> > assignments. On the other hand, finalization is part of the core system,
>> > so it would have been nice to put ClassWeakFinalizer at slot 50, and the
>> > optional Alien assignments at 51 - 55.
>> >
>> > Would anyone object to the following allocation of slots in the special
>> > objects array? This would leave Alien mostly unaffected, but would require
>> > Igor's finalization improvements to put WeakFinalizer at position 55 in
>> > the special objects array, and it would require that the Alien override
>> > be pulled into the VMMaker package such that all VMs would have the Alien
>> > assignments in the special objects array (albeit unused in many cases).
>> > And recreateSpecialObjectsArray would need updates to match of course.
>> >
>> > ?? ?? ?? ??SelectorAttemptToAssign := 50.
>> > ?? ?? ?? ??"PrimErrTableIndex := 51. in Interpreter class>>initializePrimitiveErrorCodes"
>> > ?? ?? ?? ??ClassAlien := 52.
>> > ?? ?? ?? ??InvokeCallbackSelector := 53.
>> > ?? ?? ?? ??ClassUnsafeAlien := 54.
>> > ?? ?? ?? ??ClassWeakFinalizer := 55
>> >
>> > I seem to recall some discussion of a more flexible special objects
>> > registry, although I can't find it right now. Pointers welcome.
>> >
>>
>> Ouch.. David, it seems like i used the different version of
>> #recreateSpecialObjectsArray
>> than yours.
>>
>> The tail of spl objects in Alien-Core package, found at  SqS/Alien
>> looks like following:
>>
>>       newArray at: 50 put: #run:with:in:.
>>       newArray at: 51 put: nil.
>>       newArray at: 52 put: nil.
>>       newArray at: 53 put: (self at: #Alien ifAbsent: []).
>>       newArray at: 54 put: #invokeCallback:stack:registers:jmpbuf:.
>>       newArray at: 55 put: (self at: #UnsafeAlien ifAbsent: []).
>
> Note that ObjectMemory class>>initializeSpecialObjectIndices uses zero-based
> indexing, versus one-based indexing in SmalltalkImage>>recreateSpecialObjectsArray,
> so I think the difference is not a problem.
>
>> So, i thought its not a problem to reserve the 51 slot for weak
>> finalization, because it unused anyways.
>
> Well, the slot for PrimErrTableIndex does appear to be unused at the moment,
> but I suspect that either Eliot or John reserved it for a reason. If it is
> actually unused, then this would be a good place to put ClassWeakFinalizer
> (i.e. ClassWeakFinalizer would go in 51 initializeSpecialObjectIndices, which
> would be 52 in the special objects array, right before ClassAlien).
>

>> Also, maybe we could fill an unused/obsolete slot instead of allocating new one?
>>  There are some:
>>
>>       newArray at: 23 put: nil.
>>       newArray at: 41 put: nil.
>>
>
> I think that these slots are probably still used in older images. But it
> would be good idea if we can safely recycle them.
>
> Dave
>
>