<br><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 11:06 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Igor,<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On 22 September 2011 19:16, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
> (apologies for the duplicate reply; someone needs to sort out their<br>
> threading for the benefit of the community ;) )<br>
><br>
> On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker <<a href="mailto:marcus.denker@inria.fr" target="_blank">marcus.denker@inria.fr</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> There are two changesets waiting for integrating in 1.4 that have serious<br>
>> consequences:<br>
>><br>
>> - Ephemerons. The VM level changes are in the Cog VMs build on Jenkins,<br>
>> but have not<br>
>> been integrated in the VMMaker codebase.<br>
>><br>
>> <a href="http://code.google.com/p/pharo/issues/detail?id=4265" target="_blank">http://code.google.com/p/pharo/issues/detail?id=4265</a><br>
><br>
> I would *really* like to back out these changes. The Ephemeron<br>
> implementation is very much a prototype, requiring a hack to determine<br>
> whether an object is an ephemeron (the presence of a marker class in the<br>
> first inst var) that I'm not at all happy with. There is a neater<br>
> implementation available via using an unused instSpec which IMO has<br>
> significant advantages (much simpler & faster, instSpec is valid at all<br>
> times, including during compaction, less overhead, doesn't require a marker<br>
> class), and is the route I'm taking with the new GC/object-representation<br>
> I'm working on now. Note that other than determining whether an object is<br>
> an ephemeron (instSpec/format vs inst var test) the rest of Igor's code<br>
> remains the same. I'd like to avoid too much VM forking. Would you all<br>
> consider putting these changes on hold for now?<br>
> If so, I'll make the effort to produce prototype changes (in the area of<br>
> ClassBuilder and class definition; no VM code necessary as yet) to allow<br>
> defining Ephemerons via the int spec route by next week at the latest.<br>
><br>
<br>
</div></div>i agree that in my implementation this is a weak point. But its hard<br>
to do anything without<br>
making changes to object format to identify these special objects.<br>
<br>
The main story behind this is can we afford to change the internals of<br>
VM without being beaten hard<br>
by "backwards compatibility" party? :)<br></blockquote><div><br></div></div></div><div>I don't think we get stuck in this at all. The instSpec/format field has an unused value (5 i believe) and this can easily be used for Ephemerons. All that is needed is a little image work on these methods:</div>
<div><br></div><div> Behavior>>typeOfClass</div><div> needs to answer e.g. #ephemeron for ephemeron classes</div><div><br></div><div> ClassBuilder>>computeFormat:instSize:forSuper:ccIndex:</div><div>
needs to accept e.g. #ephemeron for type and pass variable: false and weak: true for ephemerons to format:variable:words:pointers:weak:.</div><div><br></div><div> ClassBuilder>>format:variable:words:pointers:weak:</div>
<div> needs to respond to variable: false and weak: true by computing the ephemeron instSpec.</div><div><br></div><div> Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category:</div>
<div> ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category:</div><div> need siblings, e.g.</div><div> ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category </div>
<div> superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category:</div><div><br></div><div>Right? This is easy. Then in the VM there are a few places where pointer indexability (formats 3 and 4) need to be firmed up to exclude 5, but nothing difficult. We talked about this in email last week.</div>
</div></blockquote><div><br></div><div>Here's the format field (Behavior>instSpec at the image level) as currently populated:</div><div> </div><div><div> 0 = 0 sized objects (UndefinedObject True False et al)</div>
<div> 1 = non-indexable objects with inst vars (Point et al)</div><div> 2 = indexable objects with no inst vars (Array et al)</div><div> 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al)</div>
<div> 4 = weak indexable objects with inst vars (WeakArray et al)</div></div><div> 6 = 32-bit indexable objects (Float, Bitmap ert al)</div><div> 8 = 8-bit indexable objects (ByteString, ByteArray et al)</div><div>12 = CompiledMethod</div>
<div><br></div><div>N.B. in the VM the least two bits of the format/instSpec for byte objects (formats 8 and 12) is used to encode the number of odd bytes in the object, so that a 1 character ByteString has a format of 11, = 8 + 3, size = 1 word - 3 bytes.</div>
<div><br></div><div><br></div><div>For the future (i.e. the new GC/object representation, /not/ for the first implementation of ephemerons which we can do now, for Pharo 1.4 or 1.5) we need to extend format/instSpec to support 64 bits. I think format needs to be made a 5 bit field with room for 4 bits of odd bytes for 64-bit images. [For VMers, the Size4Bit is a horrible hack). So then</div>
<div><br></div><div>0 = 0 sized objects (UndefinedObject True False et al)</div><div>1 = non-indexable objects with inst vars (Point et al)</div><div>2 = indexable objects with no inst vars (Array et al)</div><div>3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al)</div>
<div>4 = weak indexable objects with inst vars (WeakArray et al)</div><div>5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron)</div><div><br></div><div>and we need 8 CompiledMethod values, 8 byte values, 4 16-bit values, 2 32-bit values and a 64-bit value, = 23 values, 23 + 5 = 30, so there is room, e.g.</div>
<div><br></div><div>9 (?) 64-bit indexable</div><div>10 - 11 32-bit indexable</div><div>12 - 15 16-bit indexable</div><div>16 - 23 byte indexable</div><div>24 - 31 compiled method</div><div><br></div><div>In 32-bit images only the least significant 2 bits would be used for formats 16 & 24, and the least significant bit for format 12.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><div></div><div class="h5">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ephemerons are versatile way to get notifications of objects which are<br>
about to die,<br>
and there are certain parts in language which is hard (or even<br>
impossible) to implement without ephemerons.<br>
<br>
I got stuck with it earlier, when realized that we cannot afford to<br>
have weak subscriptions in announcement framework<br>
for blocks (which is most convenient and most easy way to define<br>
subscriptions) without having ephemerons.<br>
And of course, by having ephemerons we can completely review the weak<br>
finalization scheme and make it<br>
much simpler, and faster.<br>
<br>
I think we should do something in this regard, even at cost of<br>
backward compatibility.<br>
Because as to me it blocks us from moving forward.<br>
<br>
I wanted to remind to people, that it took me around a day to<br>
implement ephemerons in VM. And then few more days<br>
to actually make a correct implementation and write tests to cover it.<br>
<br>
Unfortunately, we yet don't have a well established process, which<br>
could make VM + language side changes to go in sync,<br>
when its required, and go much faster and don't fear to<br>
introduce/change functionality.<br>
One of the reasons for having a continuous integration setup for VM<br>
was exactly for that:<br>
having new VMs every day (comparing to having new VMs every year).<br>
<div><div></div><div><br>
>><br>
>> - Finalization code checks for #hasNewFinalization<br>
>> This is true in the current VMs build in Jenkins, but in older VMs this<br>
>> is not in.<br>
>><br>
>> <a href="http://code.google.com/p/pharo/issues/detail?id=4483" target="_blank">http://code.google.com/p/pharo/issues/detail?id=4483</a><br>
>><br>
>> There are two options:<br>
>><br>
>> a) integrate in<br>
>> b) not integrate it<br>
>><br>
>> a) means that the image runs on older VMs, too.<br>
>> b) means we accept that we can never improve anything for real.<br>
>><br>
>> There will be more changes coming... e.g. imagine we have a Vector<br>
>> Graphics Canvas<br>
>> as some point next year... what will we do? use it or not use it to stay<br>
>> compatible?<br>
>><br>
>> Marcus<br>
>><br>
>><br>
>> --<br>
>> Marcus Denker -- <a href="http://marcusdenker.de" target="_blank">http://marcusdenker.de</a><br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> best,<br>
> Eliot<br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Best regards,<br>
Igor Stasenko.<br>
<br>
</font></blockquote></div></div></div><font color="#888888"><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>