<br><br><div class="gmail_quote">On Fri, Jul 27, 2012 at 11:16 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah OK, I was not concentrated enough when I read Eliot post :)<br>
<br>
Eliot, this is not a bug, and normal code would statistically create<br>
other objects in between...<br>
But isn't there a risk that tools like Fuel populate a small<br>
collection of simple objects (say an IdentitySet of Symbol), sharing<br>
same identityHash for each pair?<br>
It would noticeably increase the number of collisions well before the 4096 wall.<br></blockquote><div><br></div><div>Yes, but in practice no one's complained. ANyway, look at both of these:</div><div><br></div><div>
Array new: 512 streamContents: [ :stream |</div><div> 1 to: 4096 do: [ :e | stream nextPut: Object new identityHash ] ] "repeats every two objects"</div><div><br></div><div>Array new: 512 streamContents: [ :stream |</div>
<div> 1 to: 4096 do: [ :e | stream nextPut: Array new identityHash ] ] "repeats every 4 objects"</div><div><br></div><div>I'll change the scaling so that the last one does not repeat. So lets leave the test unchanged and put up with the failures until new VMs are in use.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Nicolas<br>
<br>
2012/7/27 Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>>:<br>
<div class="HOEnZb"><div class="h5">><br>
> On 27.07.2012, at 05:18, Nicolas Cellier wrote:<br>
><br>
>> 2012/7/27 Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>>:<br>
>>> On 26 July 2012 22:35, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>> On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi <<a href="mailto:leves@elte.hu">leves@elte.hu</a>> wrote:<br>
>>>>><br>
>>>>> On Thu, 26 Jul 2012, Frank Shearar wrote:<br>
>>>>><br>
>>>>>> In a freshly updated trunk we have 3184 out of 3157 tests passing. We<br>
>>>>>> have 16 expected failures, and 11 failures, the latter being:<br>
>>>>>> * BecomeTest>>#testBecomeIdentityHash<br>
>>>>><br>
>>>>><br>
>>>>> This is failing due to a VM bug. There's a fix for it somewhere, but it<br>
>>>>> seems like it's not integrated into Cog yet. Explore this to see that two<br>
>>>>> consecutive objects share the same identityHash:<br>
>>>>><br>
>>>>> Array new: 10 streamContents: [ :stream |<br>
>>>>> 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]<br>
>>>><br>
>>>><br>
>>>> IMO this isn't a bug. The identity hash changes at least every other<br>
>>>> object. Hashes don't have to be unique. But they do have to be<br>
>>>> well-distributed. With 12 bits of identityHash Cog does fine basing its<br>
>>>> identityHash on the allocation pointer. The above will wrap around after<br>
>>>> 8192 allocations, and provide 4096 distinct hashes (the maximum available).<br>
>>>> So the test needs rewriting to be more statistical. The rationale for this<br>
>>>> is to speed up allocation. Instead of a read-modify-write cycle to turn the<br>
>>>> crank of a pseudo-random generator there's a masking of the allocation<br>
>>>> pointer, which has to be read anyway to allocate an object. BTW, the<br>
>>>> *right* way to implement this is to lazily allocate hashes, but for that<br>
>>>> there needs to be a flag (e.g. an identityHash of 0) to mark an object as<br>
>>>> not yet having a hash but existing Squeak images (because of the old<br>
>>>> definition) use 0 as a valid hash, so lazy hashes requires either a header<br>
>>>> bit (not enough of those) or an image change (which is my plan, as part of<br>
>>>> the new object representation).<br>
>>><br>
>>> If it's not a bug, let's nuke the test. We need to get to a position<br>
>>> where we have a green light.<br>
>>><br>
>>> frank<br>
>>><br>
>><br>
>> If I understood Eliot correctly, it would suffice to keep a pointer<br>
>> alive to the created objects...<br>
>><br>
>> preserveObjectsFromGarbageCollection := IdentitySet new.<br>
>> Array new: 10 streamContents: [ :stream |<br>
>> 1 to: 10 do: [ :e | stream nextPut:<br>
>> (preserveObjectsFromGarbageCollection add: Object new) identityHash ]<br>
>> ]<br>
>><br>
>> Nicolas<br>
><br>
><br>
> Makes no difference. GC does not happen after each allocation. Here's one that would work with Cog because each allocation is larger:<br>
><br>
> (1 to: 10) collect: [ :e | (Array new: 4) identityHash ]<br>
><br>
> But as Eliot said the test is somewhat meaningless in its current form.<br>
><br>
> - Bert -<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>