[Vm-dev] SystemTracer64 progress

David T. Lewis lewis at mail.msen.com
Wed Jan 13 12:40:53 UTC 2010


Levente,

Great, thank you. I just added to as developer on SqueakSource/SystemTracing.
Please go ahead and commit your changes directly if you like.

The discrepancy between Squeak trunk and Pharo is minor (Jannik
has been posting his changes), so we can easily resolve this.

The main open issue is why Squeak trunk and Pharo images traced to
64 bit format on my Intel box are failing. It's got to be something
I have not spotted yet in the word swapping in SystemTracer64, and
it appears to affect only these new images, I can trace a Squeak 3.8
to 64 bits on Intel without problems. And the Pharo image that
Jannik traced with a big endian machine works fine, so it must
be a byte ordering issue of some sort.

Dave


On Wed, Jan 13, 2010 at 07:31:18AM +0100, Levente Uzonyi wrote:
> Hi Dave,
> 
> I got some time to clean up the SystemTracing package a bit. I made 
> two versions. One which just fixes, enhances, removes methods and another 
> which completely removes NoAssocIdentityDictionary. I could successfully 
> trace images with SystemTracer2 and SystemTracer64 in both Squeak trunk 
> (8863) and Pharo 1.1 dev (11138)  images, though I don't have a vm for 
> 64-bit images at the moment, so I couldn't test the 64-bit images. The 
> traced Pharo image raised an error at startup because SmalltalkImage 
> didn't understand #setPlatformPreferences, that method was removed. I ran 
> all tests in the traced images and everything seemed to be fine except 
> for #testUndeclared. It fails, because PositionableStream has two 
> extension methods, which reference a missing class variable, but that 
> should be OK if the SystemTracing package is unloaded. The changes are 
> available here under the MIT license if you're interested: 
> http://leves.web.elte.hu/squeak/
> 
> 
> Cheers,
> Levente
> 
> P.S.: I removed NoAssocIdentityDictionary, because it didn't show any 
> benefit compared to PluggableDictionary. I also tried IdentityDictionary, 
> but it's really slow, because it uses #identityHash (or 
> #scaledIdentityHash) instead of #largeHash (which should be called 
> #largeIdentityHash). Tracing 400k+ objects with IdentityDictionary means 
> that there are ~1000 objects for every possible value of #identityHash. 
> Therefore I removed the possibility to change the dictionary class 
> directly. Subclasses can override #newLargeIdentityDictionaryOfSize: if 
> necessary.


More information about the Vm-dev mailing list