Special objects array - sometimes everybody cannot be special

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Special objects array - sometimes everybody cannot be special

David T. Lewis
 
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.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Special objects array - sometimes everybody cannot be special

Andreas.Raab
 
On 5/24/2010 8:56 PM, David T. Lewis wrote:
> 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.

That sounds fine. Go for it.

> I seem to recall some discussion of a more flexible special objects
> registry, although I can't find it right now. Pointers welcome.

The discussion evolved around the issue that plugins shouldn't have the
need to modify the splObjs array for precisely the reasons we're seeing
here. The splObjs are reserved for the VM and plugins can and absolutely
should use their own registry mechanism. Historically, this wasn't
possible due to not being able to GC-protect stuff in a plugin, but I
added that feature a while back so that a plugin can GC-protect variable
locations and consequently, plugins can hold onto references directly.

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Special objects array - sometimes everybody cannot be special

Igor Stasenko
In reply to this post by David T. Lewis

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.
Reply | Threaded
Open this post in threaded view
|

Re: Special objects array - sometimes everybody cannot be special

Igor Stasenko

I thought hard how to avoid using spl object in VM code to check
that an object, which contains a weak ref which just died,
needs a special handling (add it to list, which is in it's first ivar).

So, if there is such scheme, which i don't see, then we could avoid
adding a new special object to support new finalization scheme.

On 25 May 2010 08:19, Igor Stasenko <[hidden email]> 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: []).
>
> 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.
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Special objects array - sometimes everybody cannot be special

David T. Lewis
In reply to this post by Igor Stasenko
 
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
 
Reply | Threaded
Open this post in threaded view
|

Re: Special objects array - sometimes everybody cannot be special

Igor Stasenko

On 25 May 2010 15:30, David T. Lewis <[hidden email]> wrote:

>
> 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).
>
No, in my changesets its 51 in image and 50 in VMMaker.
But it don't matters much. So, if you say 55, let it be 55.

>> 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
>
>



--
Best regards,
Igor Stasenko AKA sig.