On Wed, Jul 25, 2012 at 11:55 AM, Chris Muller <ma.chris.m at gmail.com> wrote:

> I need your help Eliot.  The first time Magma reads an object from the
> db, it compiles a new (anonymous) subclass for write-barrier behavior
> -- so it can send #modified: to the Session when any of its inst vars
> are changed.
>
> The subclass cannot add any new state so how could it know the
> Session?  Answer - when the subclass is generated, a #writeBarrier
> accessor is generate into which the session object is hacked into one
> of its literal associations.  Like this:
>
>         installAccessingOverrides
>                 class
>                         compileSilently:
>                                 'writeBarrier
>                                         ^ Object first'
>                         classified: 'access'.
>                 (class methodDictionary at: #writeBarrier)
>                         literalAt: 2
>                         put: #Object -> (WeakArray with: barrier)
>
> The above is generating a #writeBarrier method on 'class' which must
> answer the Magma session object ('barrier') so it can handle the
> #modified: logic.
>
> This dreadful hack accomplishes the goal (performance) in the standard
> VM and.. I'm sure it has for some time in Cog too but.. I'm not sure
> when or why this started happening.  With Cog 2562 when the object
> sent #writeBarrier, it found the integer 1004867812, and so the
> debugger popped up with "SmallInteger DNU #first".  However, when I
> examine the CM literals of the #writeBarrier method, the Magma session
> is in there correctly.
>
> A bit later (minute or so), of just sitting there, me thinking, doing
> nothing, then suddenly "self writeBarrier" works right there in the
> debugger!  Initially, my doing that gave me the same error, but then,
> without my doing _anything_ it suddenly returns the correct object we
> stuffed in the generate method above.
>
> At this point I'm able to resume the application, but it shortly
> happens again -- this time with a DIFFERENT object (a character) but,
> once again, the CM shows the correct literal in the explorer and,
> after a moment, "self writeBarrier" stops returning the Character and
> starts returning the correct object.
>
> I thought maybe inadvertently corrupted image so built fresh but it
> still happens every time.
>
> Thanks very much for any insight you can provide.
>

Not sure what this is, but it could be a VM bug.  Can you work on creating
a reproducible test case and then send me an image?


>
>   - Chris
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120725/8d323339/attachment.htm