Why primitive new have unexpected temp affectation

 
Hi,

I have look at the code of the primitiveNew and it seems that the  
temporaries is affect twice which don't make sense:

primitiveNewWithArg
        "Allocate a new indexable instance. Fail if the allocation would  
leave less than lowSpaceThreshold bytes free."
        | size class spaceOkay |
        size := self positive32BitValueOf: self stackTop.
        class := self stackValue: 1.
        self success: size >= 0.
        successFlag
                ifTrue: ["The following may cause GC!"
                        spaceOkay := self sufficientSpaceToInstantiate: class  
indexableSize: size.
                        self success: spaceOkay.
                        class := self stackValue: 1].
        successFlag ifTrue: [self pop: 2 thenPush: (self instantiateClass:  
class indexableSize: size)]


The first affectation is not necessary. Isn't it?

        Mth

 
Hi Mathieu,

Not sure if I understand you correctly. Do you mean, why stackValue:  
1 is read twice?
The reason for this is because  
#sufficientSpaceToInstantiate:indexableSize: may trigger GC (as the  
comment says), and therefore the temp pointer to the class, which is  
read before, may not be valid anymore. In this case the simplest  
thing to do is to get the pointer from the stack again.  
Alternatively, you could also manually remap the temp (see  
#pushRemappableOop: and #popRemappableOop). So, it is really necessary.

Cheers,
Adrian
___________________
Adrian Lienhard
www.adrian-lienhard.ch


On Aug 13, 2007, at 01:46 , Mathieu Suen wrote:

 
On Aug 13, 2007, at 10:08 AM, Adrian Lienhard wrote:

> Hi Mathieu,
>
> Not sure if I understand you correctly. Do you mean, why  
> stackValue: 1 is read twice?
> The reason for this is because  
> #sufficientSpaceToInstantiate:indexableSize: may trigger GC (as the  
> comment says), and therefore the temp pointer to the class, which  
> is read before, may not be valid anymore.

Why the  GC need to change the temp pointer?

 

On Aug 13, 2007, at 13:23 , Mathieu Suen wrote:

It does not change it. And this is exactly the problem when objects  
are moved in memory during the compaction phase.

Adrian

 
Ok. so if I understood correctly that means that when a GC occurs the  
address of the object class may change and the reference from an  
object pointing to him is updated but not the register of the VM.

Ok thanks.

        Mth



On Aug 13, 2007, at 1:36 PM, Adrian Lienhard wrote:

> It does not change it. And this is exactly the problem when objects  
> are moved in memory during the compaction phase.

 

On 13-Aug-07, at 2:22 PM, Mathieu Suen wrote:

> Ok. so if I understood correctly that means that when a GC occurs  
> the address of the object class may change and the reference from  
> an object pointing to him is updated but not the register of the VM.
Exactly. If we had the luxury of a really suitable cpu it would  
obviously handle it transparently. Talk nicely to Jecel and alter  
reality a bit so that the intel 'architecture' doesn't have a pretty  
much total stranglehold...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Hex dump:  Where witches put used curses...