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. - Chris |
On Wed, Jul 25, 2012 at 11:55 AM, Chris Muller <[hidden email]> wrote: I need your help Eliot. The first time Magma reads an object from the 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?
best, Eliot |
Yea, I will try.
Thank you! On Wed, Jul 25, 2012 at 4:24 PM, Eliot Miranda <[hidden email]> wrote: > > > On Wed, Jul 25, 2012 at 11:55 AM, Chris Muller <[hidden email]> 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 > |
Free forum by Nabble | Edit this page |