<br><br><div class="gmail_quote">On Wed, Jul 25, 2012 at 11:55 AM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I need your help Eliot. The first time Magma reads an object from the<br>
db, it compiles a new (anonymous) subclass for write-barrier behavior<br>
-- so it can send #modified: to the Session when any of its inst vars<br>
are changed.<br>
<br>
The subclass cannot add any new state so how could it know the<br>
Session? Answer - when the subclass is generated, a #writeBarrier<br>
accessor is generate into which the session object is hacked into one<br>
of its literal associations. Like this:<br>
<br>
installAccessingOverrides<br>
class<br>
compileSilently:<br>
'writeBarrier<br>
^ Object first'<br>
classified: 'access'.<br>
(class methodDictionary at: #writeBarrier)<br>
literalAt: 2<br>
put: #Object -> (WeakArray with: barrier)<br>
<br>
The above is generating a #writeBarrier method on 'class' which must<br>
answer the Magma session object ('barrier') so it can handle the<br>
#modified: logic.<br>
<br>
This dreadful hack accomplishes the goal (performance) in the standard<br>
VM and.. I'm sure it has for some time in Cog too but.. I'm not sure<br>
when or why this started happening. With Cog 2562 when the object<br>
sent #writeBarrier, it found the integer 1004867812, and so the<br>
debugger popped up with "SmallInteger DNU #first". However, when I<br>
examine the CM literals of the #writeBarrier method, the Magma session<br>
is in there correctly.<br>
<br>
A bit later (minute or so), of just sitting there, me thinking, doing<br>
nothing, then suddenly "self writeBarrier" works right there in the<br>
debugger! Initially, my doing that gave me the same error, but then,<br>
without my doing _anything_ it suddenly returns the correct object we<br>
stuffed in the generate method above.<br>
<br>
At this point I'm able to resume the application, but it shortly<br>
happens again -- this time with a DIFFERENT object (a character) but,<br>
once again, the CM shows the correct literal in the explorer and,<br>
after a moment, "self writeBarrier" stops returning the Character and<br>
starts returning the correct object.<br>
<br>
I thought maybe inadvertently corrupted image so built fresh but it<br>
still happens every time.<br>
<br>
Thanks very much for any insight you can provide.<br></blockquote><div><br></div><div>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?</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Chris<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>