<br><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 11:28 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">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 class="h5">On 22 September 2011 20:06, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> Hi Igor,<br>
><br>
> On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
>><br>
>> On 22 September 2011 19:16, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">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">marcus.denker@inria.fr</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> There are two changesets waiting for integrating in 1.4 that have<br>
>> >> 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<br>
>> > 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<br>
>> > marker<br>
>> > class), and is the route I'm taking with the new<br>
>> > GC/object-representation<br>
>> > I'm working on now. Note that other than determining whether an object<br>
>> > 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>
>> 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>
><br>
> I don't think we get stuck in this at all. The instSpec/format field has an<br>
> unused value (5 i believe) and this can easily be used for Ephemerons. All<br>
> that is needed is a little image work on these methods:<br>
> Behavior>>typeOfClass<br>
> needs to answer e.g. #ephemeron for ephemeron classes<br>
> ClassBuilder>>computeFormat:instSize:forSuper:ccIndex:<br>
> needs to accept e.g. #ephemeron for type and pass variable: false<br>
> and weak: true for ephemerons to format:variable:words:pointers:weak:.<br>
> ClassBuilder>>format:variable:words:pointers:weak:<br>
> needs to respond to variable: false and weak: true by computing the<br>
> ephemeron instSpec.<br>
><br>
> Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category:<br>
><br>
> ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category:<br>
> need siblings, e.g.<br>
><br>
> ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category<br>
><br>
> superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category:<br>
> Right? This is easy. Then in the VM there are a few places where pointer<br>
> indexability (formats 3 and 4) need to be firmed up to exclude 5, but<br>
> nothing difficult. We talked about this in email last week.<br>
><br>
<br>
</div></div>Do you think this will require boosting an image format version number?<br></blockquote><div><br></div><div>That would make sense. Boosting it so that the new VMs can run older images and newer, ephemeron images, but that ephemeron images won't open on older VMs. Yes, this makes perfect sense.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think it is, because clearly, an images which expect ephemerons to<br>
function cannot work with older VMs properly without<br>
support of ephemerons.<br>
<br>
And will lead us to numerous reports "cannot open your f*king image"<br>
with my VM :)<br>
Internally, discussing with Marcus and Stef we came to agreement, that<br>
for each Pharo release we should ship<br>
own version of VM (signed appropriately), so then there will be less<br>
confusion. We also thinking that VM versioning<br>
in future should follow the image versioning, again to make things<br>
simpler and to avoid confusion.<br>
<font color="#888888"><br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>