Quantcast

Fwd: Significant WriteBarrier bug, assistance needed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Significant WriteBarrier bug, assistance needed

Chris Muller-4
----- Forwarded Message -----
From: Chris Muller <[hidden email]>
To: Avi Bryant <[hidden email]>
Sent: Tuesday, April 5, 2005 3:35 PM
Subject: Significant WriteBarrier bug, assistance needed

Hi, I know you just helped me with one bug but now I've run into a tougher one.
I thought I had it nailed, I think my fix is close but there is still one
problem which I can't seem to fix.

Here's the problem.  Given this class-hierarchy:

  Object
    WbTestA
      WbTestB

and instances of WbTestB are behind write-barrier, if then inst-vars are added
to WbTestA, the current implementation tries to migrate (e.g., in
WBClassBuider>>migrateFromTarget:to:) based on what comes in from the
SystemChangeEvent, which is the WbTestA changes.  It ends up creating a new
write-barrier subclass for WbTestA and assigning that to the 'class' variable
of the builder for WbTestB.  A primitive failure soon results.

Based on my research, it seems, under this case, no migration of old WbTestB
instances should be necessary because class WbTestB will, by the time it gets
to WBClassBuider>>migrateFromTarget:to:, already be pointing to the new WbTestA
superclass, not the old one.  So my fix so far involves changing that method
to:

migrateFromTarget: oldSuperclass to: newSuperclass
    | oldClass |
    oldClass _ class.
    "Was the immediate WriteBarrier superclass modified (or was it a
superclass of
that)?"
    (oldClass superclass == newSuperclass)
        ifTrue:
            [ oldClass superclass: oldSuperclass.
            class _ self createSubclassOf: newSuperclass.
            class updateInstancesFrom: oldClass ]

To test this, I created these two test scripts.  The first as a regression-test
for changing the immediate superclass, the second to handle the new scenario I
stumbled on.

"Immediate superclass change test."
| a wb domain |
a _ Object
    subclass: #WbTestA
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'as yet uncategorized'.
b _ (Smalltalk at: #WbTestA)
    subclass: #WbTestB
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'as yet uncategorized'.
wb _ WriteBarrier new.
domain _ (Smalltalk at: #WbTestB) new.
wb add: domain.
[ a
    subclass: #WbTestB
    instanceVariableNames: 'newBvar'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'as yet uncategorized' ]

    ensure:
        [ wb remove: domain.
        b removeFromSystem.
        a removeFromSystem ]



"Super superclass change test."
| a b wb domain |
a _ Object
    subclass: #WbTestA
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'as yet uncategorized'.
b _ (Smalltalk at: #WbTestA)
    subclass: #WbTestB
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'as yet uncategorized'.
wb _ WriteBarrier new.
domain _ (Smalltalk at: #WbTestB) new.
wb halt add: domain.
[ Object
    subclass: #WbTestA
    instanceVariableNames: 'newAvar'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'as yet uncategorized' ]

    ensure:
        [ wb remove: domain.
        b removeFromSystem.
        a removeFromSystem ]


So, what's the problem now?  The first test still works, the second "works"
until it tries to clean up.  The line in the ensure block:

  wb remove: domain

gets a primitive failure in primitiveChangeClassTo: and I can't figure out why.
The commment is very detailed about the possible reasons but I still think
we're not violating any of those reasons, it should work..

I stared at it until 1am, but I'm just not seeing it..  Can you give me a hand?

Thanks,
  Chris
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Loading...