In a freshly updated trunk we have 3184 out of 3157 tests passing. We have 16 expected failures, and 11 failures, the latter being: * BecomeTest>>#testBecomeIdentityHash * ExceptionTests>>#testHandlerFromAction * LocaleTest>>#testLocaleChanged * MCFileInTest>>#testStWriter * MCMczInstallerTest>>#testInstallFromFile * MCMczInstallerTest>>#testInstallFromStream * PackageDependencyTest>>#testMultilingual * PackageDependencyTest>>#testSystem * RWBinaryOrTextStreamTest>>#testExisiting * ReleaseTest>>#testNoObsoleteClasses * SocketTest>>#testSendTimeout
ReleaseTest>>#testNoObsoleteClasses lists a bunch of what look to be test artifacts: things like AnObsoleteAutoGeneratedClassForTestingSystemChanges. ChangeHooksTest and ClassRenameFixTest look to be the culprits. How do we make these two guys not interfere with ReleaseTest? (Or, how do we nuke the obsolete classes created by these guys?)
PackageDependencyTest>>#testExisiting [sic] and #testMultilingual looks like they need updating. I don't know if these dependencies SHOULD be there, but they ARE there. I'll fix them to reflect reality, but if they shouldn't be there, please raise a Mantis report to remove the dependency!
I suspect that SocketTest might well involve platform dependencies: it fails on my machine, an Ubuntu Lucid Lynx running the latest Cog VM.
I'd really like to have a green test status before we ship 4.4, so I'm asking for folks to take a look at the above tests (I'll do the PackageDependencyTest ones) and see if anyone can make them green? And then maybe, for bonus brownie points, see if we can reduce the number of expected failures?
Thanks!
frank
On Thu, 26 Jul 2012, Frank Shearar wrote:
In a freshly updated trunk we have 3184 out of 3157 tests passing. We have 16 expected failures, and 11 failures, the latter being:
- BecomeTest>>#testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but it seems like it's not integrated into Cog yet. Explore this to see that two consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
- ExceptionTests>>#testHandlerFromAction
This is more like a feature request, the current exception handling mechanism doesn't work like this.
- LocaleTest>>#testLocaleChanged
A bug introduced during the GetText integration.
- MCFileInTest>>#testStWriter
- MCMczInstallerTest>>#testInstallFromFile
- MCMczInstallerTest>>#testInstallFromStream
Some old and funky MC issues, if you run the tests one or two more times, they somehow pass.
- PackageDependencyTest>>#testMultilingual
Looks okay, just update the dependencies.
- PackageDependencyTest>>#testSystem
This one is a side effect of the GetText integration. Not sure if NaturalLanguageTranslator should use TextDomainManager or if it should be part of the System package. Also not sure about other dependencies here either.
- RWBinaryOrTextStreamTest>>#testExisiting
Another feature request, which changes the semantics of ReadWriteStream. Not implemented yet, because it breaks some code, so it requires a larger rewrite.
- ReleaseTest>>#testNoObsoleteClasses
As you described, some TestCases hold references to obsolete classes and the TestRunner holds the reference to the TestCases.
- SocketTest>>#testSendTimeout
Either a bug or just some network problem, works for me on windows.
Levente
ReleaseTest>>#testNoObsoleteClasses lists a bunch of what look to be test artifacts: things like AnObsoleteAutoGeneratedClassForTestingSystemChanges. ChangeHooksTest and ClassRenameFixTest look to be the culprits. How do we make these two guys not interfere with ReleaseTest? (Or, how do we nuke the obsolete classes created by these guys?)
PackageDependencyTest>>#testExisiting [sic] and #testMultilingual looks like they need updating. I don't know if these dependencies SHOULD be there, but they ARE there. I'll fix them to reflect reality, but if they shouldn't be there, please raise a Mantis report to remove the dependency!
I suspect that SocketTest might well involve platform dependencies: it fails on my machine, an Ubuntu Lucid Lynx running the latest Cog VM.
I'd really like to have a green test status before we ship 4.4, so I'm asking for folks to take a look at the above tests (I'll do the PackageDependencyTest ones) and see if anyone can make them green? And then maybe, for bonus brownie points, see if we can reduce the number of expected failures?
Thanks!
frank
On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi leves@elte.hu wrote:
On Thu, 26 Jul 2012, Frank Shearar wrote:
In a freshly updated trunk we have 3184 out of 3157 tests passing. We
have 16 expected failures, and 11 failures, the latter being:
- BecomeTest>>#**testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but it seems like it's not integrated into Cog yet. Explore this to see that two consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
IMO this isn't a bug. The identity hash changes at least every other object. Hashes don't have to be unique. But they do have to be well-distributed. With 12 bits of identityHash Cog does fine basing its identityHash on the allocation pointer. The above will wrap around after 8192 allocations, and provide 4096 distinct hashes (the maximum available). So the test needs rewriting to be more statistical. The rationale for this is to speed up allocation. Instead of a read-modify-write cycle to turn the crank of a pseudo-random generator there's a masking of the allocation pointer, which has to be read anyway to allocate an object. BTW, the *right* way to implement this is to lazily allocate hashes, but for that there needs to be a flag (e.g. an identityHash of 0) to mark an object as not yet having a hash but existing Squeak images (because of the old definition) use 0 as a valid hash, so lazy hashes requires either a header bit (not enough of those) or an image change (which is my plan, as part of the new object representation).
- ExceptionTests>>#**testHandlerFromAction
This is more like a feature request, the current exception handling mechanism doesn't work like this.
- LocaleTest>>#testLocaleChanged
A bug introduced during the GetText integration.
- MCFileInTest>>#testStWriter
- MCMczInstallerTest>>#**testInstallFromFile
- MCMczInstallerTest>>#**testInstallFromStream
Some old and funky MC issues, if you run the tests one or two more times, they somehow pass.
- PackageDependencyTest>>#**testMultilingual
Looks okay, just update the dependencies.
- PackageDependencyTest>>#**testSystem
This one is a side effect of the GetText integration. Not sure if NaturalLanguageTranslator should use TextDomainManager or if it should be part of the System package. Also not sure about other dependencies here either.
- RWBinaryOrTextStreamTest>>#**testExisiting
Another feature request, which changes the semantics of ReadWriteStream. Not implemented yet, because it breaks some code, so it requires a larger rewrite.
- ReleaseTest>>#**testNoObsoleteClasses
As you described, some TestCases hold references to obsolete classes and the TestRunner holds the reference to the TestCases.
- SocketTest>>#testSendTimeout
Either a bug or just some network problem, works for me on windows.
Levente
ReleaseTest>>#**testNoObsoleteClasses lists a bunch of what look to be test artifacts: things like AnObsoleteAutoGeneratedClassFo**rTestingSystemChanges. ChangeHooksTest and ClassRenameFixTest look to be the culprits. How do we make these two guys not interfere with ReleaseTest? (Or, how do we nuke the obsolete classes created by these guys?)
PackageDependencyTest>>#**testExisiting [sic] and #testMultilingual looks like they need updating. I don't know if these dependencies SHOULD be there, but they ARE there. I'll fix them to reflect reality, but if they shouldn't be there, please raise a Mantis report to remove the dependency!
I suspect that SocketTest might well involve platform dependencies: it fails on my machine, an Ubuntu Lucid Lynx running the latest Cog VM.
I'd really like to have a green test status before we ship 4.4, so I'm asking for folks to take a look at the above tests (I'll do the PackageDependencyTest ones) and see if anyone can make them green? And then maybe, for bonus brownie points, see if we can reduce the number of expected failures?
Thanks!
frank
On 26 July 2012 22:35, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi leves@elte.hu wrote:
On Thu, 26 Jul 2012, Frank Shearar wrote:
In a freshly updated trunk we have 3184 out of 3157 tests passing. We have 16 expected failures, and 11 failures, the latter being:
- BecomeTest>>#testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but it seems like it's not integrated into Cog yet. Explore this to see that two consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
IMO this isn't a bug. The identity hash changes at least every other object. Hashes don't have to be unique. But they do have to be well-distributed. With 12 bits of identityHash Cog does fine basing its identityHash on the allocation pointer. The above will wrap around after 8192 allocations, and provide 4096 distinct hashes (the maximum available). So the test needs rewriting to be more statistical. The rationale for this is to speed up allocation. Instead of a read-modify-write cycle to turn the crank of a pseudo-random generator there's a masking of the allocation pointer, which has to be read anyway to allocate an object. BTW, the *right* way to implement this is to lazily allocate hashes, but for that there needs to be a flag (e.g. an identityHash of 0) to mark an object as not yet having a hash but existing Squeak images (because of the old definition) use 0 as a valid hash, so lazy hashes requires either a header bit (not enough of those) or an image change (which is my plan, as part of the new object representation).
If it's not a bug, let's nuke the test. We need to get to a position where we have a green light.
frank
- ExceptionTests>>#testHandlerFromAction
This is more like a feature request, the current exception handling mechanism doesn't work like this.
- LocaleTest>>#testLocaleChanged
A bug introduced during the GetText integration.
- MCFileInTest>>#testStWriter
- MCMczInstallerTest>>#testInstallFromFile
- MCMczInstallerTest>>#testInstallFromStream
Some old and funky MC issues, if you run the tests one or two more times, they somehow pass.
- PackageDependencyTest>>#testMultilingual
Looks okay, just update the dependencies.
- PackageDependencyTest>>#testSystem
This one is a side effect of the GetText integration. Not sure if NaturalLanguageTranslator should use TextDomainManager or if it should be part of the System package. Also not sure about other dependencies here either.
- RWBinaryOrTextStreamTest>>#testExisiting
Another feature request, which changes the semantics of ReadWriteStream. Not implemented yet, because it breaks some code, so it requires a larger rewrite.
- ReleaseTest>>#testNoObsoleteClasses
As you described, some TestCases hold references to obsolete classes and the TestRunner holds the reference to the TestCases.
- SocketTest>>#testSendTimeout
Either a bug or just some network problem, works for me on windows.
Levente
ReleaseTest>>#testNoObsoleteClasses lists a bunch of what look to be test artifacts: things like AnObsoleteAutoGeneratedClassForTestingSystemChanges. ChangeHooksTest and ClassRenameFixTest look to be the culprits. How do we make these two guys not interfere with ReleaseTest? (Or, how do we nuke the obsolete classes created by these guys?)
PackageDependencyTest>>#testExisiting [sic] and #testMultilingual looks like they need updating. I don't know if these dependencies SHOULD be there, but they ARE there. I'll fix them to reflect reality, but if they shouldn't be there, please raise a Mantis report to remove the dependency!
I suspect that SocketTest might well involve platform dependencies: it fails on my machine, an Ubuntu Lucid Lynx running the latest Cog VM.
I'd really like to have a green test status before we ship 4.4, so I'm asking for folks to take a look at the above tests (I'll do the PackageDependencyTest ones) and see if anyone can make them green? And then maybe, for bonus brownie points, see if we can reduce the number of expected failures?
Thanks!
frank
-- best, Eliot
2012/7/27 Frank Shearar frank.shearar@gmail.com:
On 26 July 2012 22:35, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi leves@elte.hu wrote:
On Thu, 26 Jul 2012, Frank Shearar wrote:
In a freshly updated trunk we have 3184 out of 3157 tests passing. We have 16 expected failures, and 11 failures, the latter being:
- BecomeTest>>#testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but it seems like it's not integrated into Cog yet. Explore this to see that two consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
IMO this isn't a bug. The identity hash changes at least every other object. Hashes don't have to be unique. But they do have to be well-distributed. With 12 bits of identityHash Cog does fine basing its identityHash on the allocation pointer. The above will wrap around after 8192 allocations, and provide 4096 distinct hashes (the maximum available). So the test needs rewriting to be more statistical. The rationale for this is to speed up allocation. Instead of a read-modify-write cycle to turn the crank of a pseudo-random generator there's a masking of the allocation pointer, which has to be read anyway to allocate an object. BTW, the *right* way to implement this is to lazily allocate hashes, but for that there needs to be a flag (e.g. an identityHash of 0) to mark an object as not yet having a hash but existing Squeak images (because of the old definition) use 0 as a valid hash, so lazy hashes requires either a header bit (not enough of those) or an image change (which is my plan, as part of the new object representation).
If it's not a bug, let's nuke the test. We need to get to a position where we have a green light.
frank
If I understood Eliot correctly, it would suffice to keep a pointer alive to the created objects...
preserveObjectsFromGarbageCollection := IdentitySet new. Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: (preserveObjectsFromGarbageCollection add: Object new) identityHash ] ]
Nicolas
- ExceptionTests>>#testHandlerFromAction
This is more like a feature request, the current exception handling mechanism doesn't work like this.
- LocaleTest>>#testLocaleChanged
A bug introduced during the GetText integration.
- MCFileInTest>>#testStWriter
- MCMczInstallerTest>>#testInstallFromFile
- MCMczInstallerTest>>#testInstallFromStream
Some old and funky MC issues, if you run the tests one or two more times, they somehow pass.
- PackageDependencyTest>>#testMultilingual
Looks okay, just update the dependencies.
- PackageDependencyTest>>#testSystem
This one is a side effect of the GetText integration. Not sure if NaturalLanguageTranslator should use TextDomainManager or if it should be part of the System package. Also not sure about other dependencies here either.
- RWBinaryOrTextStreamTest>>#testExisiting
Another feature request, which changes the semantics of ReadWriteStream. Not implemented yet, because it breaks some code, so it requires a larger rewrite.
- ReleaseTest>>#testNoObsoleteClasses
As you described, some TestCases hold references to obsolete classes and the TestRunner holds the reference to the TestCases.
- SocketTest>>#testSendTimeout
Either a bug or just some network problem, works for me on windows.
Levente
ReleaseTest>>#testNoObsoleteClasses lists a bunch of what look to be test artifacts: things like AnObsoleteAutoGeneratedClassForTestingSystemChanges. ChangeHooksTest and ClassRenameFixTest look to be the culprits. How do we make these two guys not interfere with ReleaseTest? (Or, how do we nuke the obsolete classes created by these guys?)
PackageDependencyTest>>#testExisiting [sic] and #testMultilingual looks like they need updating. I don't know if these dependencies SHOULD be there, but they ARE there. I'll fix them to reflect reality, but if they shouldn't be there, please raise a Mantis report to remove the dependency!
I suspect that SocketTest might well involve platform dependencies: it fails on my machine, an Ubuntu Lucid Lynx running the latest Cog VM.
I'd really like to have a green test status before we ship 4.4, so I'm asking for folks to take a look at the above tests (I'll do the PackageDependencyTest ones) and see if anyone can make them green? And then maybe, for bonus brownie points, see if we can reduce the number of expected failures?
Thanks!
frank
-- best, Eliot
On 27.07.2012, at 05:18, Nicolas Cellier wrote:
2012/7/27 Frank Shearar frank.shearar@gmail.com:
On 26 July 2012 22:35, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi leves@elte.hu wrote:
On Thu, 26 Jul 2012, Frank Shearar wrote:
In a freshly updated trunk we have 3184 out of 3157 tests passing. We have 16 expected failures, and 11 failures, the latter being:
- BecomeTest>>#testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but it seems like it's not integrated into Cog yet. Explore this to see that two consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
IMO this isn't a bug. The identity hash changes at least every other object. Hashes don't have to be unique. But they do have to be well-distributed. With 12 bits of identityHash Cog does fine basing its identityHash on the allocation pointer. The above will wrap around after 8192 allocations, and provide 4096 distinct hashes (the maximum available). So the test needs rewriting to be more statistical. The rationale for this is to speed up allocation. Instead of a read-modify-write cycle to turn the crank of a pseudo-random generator there's a masking of the allocation pointer, which has to be read anyway to allocate an object. BTW, the *right* way to implement this is to lazily allocate hashes, but for that there needs to be a flag (e.g. an identityHash of 0) to mark an object as not yet having a hash but existing Squeak images (because of the old definition) use 0 as a valid hash, so lazy hashes requires either a header bit (not enough of those) or an image change (which is my plan, as part of the new object representation).
If it's not a bug, let's nuke the test. We need to get to a position where we have a green light.
frank
If I understood Eliot correctly, it would suffice to keep a pointer alive to the created objects...
preserveObjectsFromGarbageCollection := IdentitySet new. Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: (preserveObjectsFromGarbageCollection add: Object new) identityHash ] ]
Nicolas
Makes no difference. GC does not happen after each allocation. Here's one that would work with Cog because each allocation is larger:
(1 to: 10) collect: [ :e | (Array new: 4) identityHash ]
But as Eliot said the test is somewhat meaningless in its current form.
- Bert -
Ah OK, I was not concentrated enough when I read Eliot post :)
Eliot, this is not a bug, and normal code would statistically create other objects in between... But isn't there a risk that tools like Fuel populate a small collection of simple objects (say an IdentitySet of Symbol), sharing same identityHash for each pair? It would noticeably increase the number of collisions well before the 4096 wall.
Nicolas
2012/7/27 Bert Freudenberg bert@freudenbergs.de:
On 27.07.2012, at 05:18, Nicolas Cellier wrote:
2012/7/27 Frank Shearar frank.shearar@gmail.com:
On 26 July 2012 22:35, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi leves@elte.hu wrote:
On Thu, 26 Jul 2012, Frank Shearar wrote:
In a freshly updated trunk we have 3184 out of 3157 tests passing. We have 16 expected failures, and 11 failures, the latter being:
- BecomeTest>>#testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but it seems like it's not integrated into Cog yet. Explore this to see that two consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
IMO this isn't a bug. The identity hash changes at least every other object. Hashes don't have to be unique. But they do have to be well-distributed. With 12 bits of identityHash Cog does fine basing its identityHash on the allocation pointer. The above will wrap around after 8192 allocations, and provide 4096 distinct hashes (the maximum available). So the test needs rewriting to be more statistical. The rationale for this is to speed up allocation. Instead of a read-modify-write cycle to turn the crank of a pseudo-random generator there's a masking of the allocation pointer, which has to be read anyway to allocate an object. BTW, the *right* way to implement this is to lazily allocate hashes, but for that there needs to be a flag (e.g. an identityHash of 0) to mark an object as not yet having a hash but existing Squeak images (because of the old definition) use 0 as a valid hash, so lazy hashes requires either a header bit (not enough of those) or an image change (which is my plan, as part of the new object representation).
If it's not a bug, let's nuke the test. We need to get to a position where we have a green light.
frank
If I understood Eliot correctly, it would suffice to keep a pointer alive to the created objects...
preserveObjectsFromGarbageCollection := IdentitySet new. Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: (preserveObjectsFromGarbageCollection add: Object new) identityHash ] ]
Nicolas
Makes no difference. GC does not happen after each allocation. Here's one that would work with Cog because each allocation is larger:
(1 to: 10) collect: [ :e | (Array new: 4) identityHash ]
But as Eliot said the test is somewhat meaningless in its current form.
- Bert -
On Fri, Jul 27, 2012 at 11:16 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ah OK, I was not concentrated enough when I read Eliot post :)
Eliot, this is not a bug, and normal code would statistically create other objects in between... But isn't there a risk that tools like Fuel populate a small collection of simple objects (say an IdentitySet of Symbol), sharing same identityHash for each pair? It would noticeably increase the number of collisions well before the 4096 wall.
Yes, but in practice no one's complained. ANyway, look at both of these:
Array new: 512 streamContents: [ :stream | 1 to: 4096 do: [ :e | stream nextPut: Object new identityHash ] ] "repeats every two objects"
Array new: 512 streamContents: [ :stream | 1 to: 4096 do: [ :e | stream nextPut: Array new identityHash ] ] "repeats every 4 objects"
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.
Nicolas
2012/7/27 Bert Freudenberg bert@freudenbergs.de:
On 27.07.2012, at 05:18, Nicolas Cellier wrote:
2012/7/27 Frank Shearar frank.shearar@gmail.com:
On 26 July 2012 22:35, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi leves@elte.hu
wrote:
On Thu, 26 Jul 2012, Frank Shearar wrote:
> In a freshly updated trunk we have 3184 out of 3157 tests passing.
We
> have 16 expected failures, and 11 failures, the latter being: > * BecomeTest>>#testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but
it
seems like it's not integrated into Cog yet. Explore this to see
that two
consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ]
]
IMO this isn't a bug. The identity hash changes at least every other object. Hashes don't have to be unique. But they do have to be well-distributed. With 12 bits of identityHash Cog does fine basing
its
identityHash on the allocation pointer. The above will wrap around
after
8192 allocations, and provide 4096 distinct hashes (the maximum
available).
So the test needs rewriting to be more statistical. The rationale
for this
is to speed up allocation. Instead of a read-modify-write cycle to
turn the
crank of a pseudo-random generator there's a masking of the allocation pointer, which has to be read anyway to allocate an object. BTW, the *right* way to implement this is to lazily allocate hashes, but for
that
there needs to be a flag (e.g. an identityHash of 0) to mark an
object as
not yet having a hash but existing Squeak images (because of the old definition) use 0 as a valid hash, so lazy hashes requires either a
header
bit (not enough of those) or an image change (which is my plan, as
part of
the new object representation).
If it's not a bug, let's nuke the test. We need to get to a position where we have a green light.
frank
If I understood Eliot correctly, it would suffice to keep a pointer alive to the created objects...
preserveObjectsFromGarbageCollection := IdentitySet new. Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: (preserveObjectsFromGarbageCollection add: Object new) identityHash ] ]
Nicolas
Makes no difference. GC does not happen after each allocation. Here's
one that would work with Cog because each allocation is larger:
(1 to: 10) collect: [ :e | (Array new: 4) identityHash ]
But as Eliot said the test is somewhat meaningless in its current form.
- Bert -
On 27 July 2012 20:05, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, Jul 27, 2012 at 11:16 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah OK, I was not concentrated enough when I read Eliot post :)
Eliot, this is not a bug, and normal code would statistically create other objects in between... But isn't there a risk that tools like Fuel populate a small collection of simple objects (say an IdentitySet of Symbol), sharing same identityHash for each pair? It would noticeably increase the number of collisions well before the 4096 wall.
Yes, but in practice no one's complained. ANyway, look at both of these:
Array new: 512 streamContents: [ :stream | 1 to: 4096 do: [ :e | stream nextPut: Object new identityHash ] ] "repeats every two objects"
Array new: 512 streamContents: [ :stream | 1 to: 4096 do: [ :e | stream nextPut: Array new identityHash ] ] "repeats every 4 objects"
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.
In which case let's make it an expected failure, rather, and I've made a note on the Squeak 4.4 page to un-expect it as part of prepping for 4.5.
frank
Nicolas
2012/7/27 Bert Freudenberg bert@freudenbergs.de:
On 27.07.2012, at 05:18, Nicolas Cellier wrote:
2012/7/27 Frank Shearar frank.shearar@gmail.com:
On 26 July 2012 22:35, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi leves@elte.hu wrote: > > On Thu, 26 Jul 2012, Frank Shearar wrote: > >> In a freshly updated trunk we have 3184 out of 3157 tests passing. >> We >> have 16 expected failures, and 11 failures, the latter being: >> * BecomeTest>>#testBecomeIdentityHash > > > This is failing due to a VM bug. There's a fix for it somewhere, but > it > seems like it's not integrated into Cog yet. Explore this to see > that two > consecutive objects share the same identityHash: > > Array new: 10 streamContents: [ :stream | > 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] > ]
IMO this isn't a bug. The identity hash changes at least every other object. Hashes don't have to be unique. But they do have to be well-distributed. With 12 bits of identityHash Cog does fine basing its identityHash on the allocation pointer. The above will wrap around after 8192 allocations, and provide 4096 distinct hashes (the maximum available). So the test needs rewriting to be more statistical. The rationale for this is to speed up allocation. Instead of a read-modify-write cycle to turn the crank of a pseudo-random generator there's a masking of the allocation pointer, which has to be read anyway to allocate an object. BTW, the *right* way to implement this is to lazily allocate hashes, but for that there needs to be a flag (e.g. an identityHash of 0) to mark an object as not yet having a hash but existing Squeak images (because of the old definition) use 0 as a valid hash, so lazy hashes requires either a header bit (not enough of those) or an image change (which is my plan, as part of the new object representation).
If it's not a bug, let's nuke the test. We need to get to a position where we have a green light.
frank
If I understood Eliot correctly, it would suffice to keep a pointer alive to the created objects...
preserveObjectsFromGarbageCollection := IdentitySet new. Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: (preserveObjectsFromGarbageCollection add: Object new) identityHash ] ]
Nicolas
Makes no difference. GC does not happen after each allocation. Here's one that would work with Cog because each allocation is larger:
(1 to: 10) collect: [ :e | (Array new: 4) identityHash ]
But as Eliot said the test is somewhat meaningless in its current form.
- Bert -
-- best, Eliot
On 26 July 2012 11:59, Levente Uzonyi leves@elte.hu wrote:
On Thu, 26 Jul 2012, Frank Shearar wrote:
In a freshly updated trunk we have 3184 out of 3157 tests passing. We have 16 expected failures, and 11 failures, the latter being:
- BecomeTest>>#testBecomeIdentityHash
This is failing due to a VM bug. There's a fix for it somewhere, but it seems like it's not integrated into Cog yet. Explore this to see that two consecutive objects share the same identityHash:
Array new: 10 streamContents: [ :stream | 1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
- ExceptionTests>>#testHandlerFromAction
This is more like a feature request, the current exception handling mechanism doesn't work like this.
- LocaleTest>>#testLocaleChanged
A bug introduced during the GetText integration.
It looks like I just need a Preference that differs between ja and en locales. How could I find such a thing? I seem to have uncovered a nest of uncommented classes and things that look like selectors that are actually keys in dictionaries. It's less than clear how this stuff works.
frank
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
Frank Shearar -
Levente Uzonyi -
Nicolas Cellier