Alan,

It could be that your memcpy equivalent is wrong? For example, if the compaction phase, or any phase, of the garbage collection, is not doing correct thing, or object creation doesn't do nil-out, etc., etc. can cause this kind of errors.

Oh, by the way, speaking of memcpy equivalent, I've been advocating (well, just sent two related emails over 2-3 years period) that we should look at what the #copy (and deepCopy and veryDeepCopy) message does to some important collection objects like strings.

For example, if you send #copy to a String, it first allocates the space for the new object, zero-out the space and copy over the original string onto it. But if we use #clone to implement #copy, we can eliminate the zero-out or nil-out phase and speed it up by 30% or so on a platform I tested. Strings and Symbols are heavily used in the structure of a morph, and copy a morph involves a lot of copying of those.

-- Yoshiki

If you dig around in interpreter you'll see there is already some methods to do santity checks. You just need to invoke them and turn the asserts on.

On Apr 1, 2004, at 2:00 PM, Bryce Kampjes wrote:

Yoshiki Ohshima writes:

...

It could be that your memcpy equivalent is wrong? For example, if the compaction phase, or any phase, of the garbage collection, is not doing correct thing, or object creation doesn't do nil-out, etc., etc. can cause this kind of errors.

If that doesn't work, one thing I'm currently doing is writing a memory checker. The garbage collector's sweep walks over all the objects in memory, that loop can be used to check that memory hasn't been corrupted.

Memory corruption bugs are much messier when there is a garbage collector moving objects around.

Bryce

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

Alan Grimes alangrimes@starpower.net wrote:

I noticed that the object format appears to be a 1 word header with about 33 fields packed into 32 bits followed by the text of the object...

Well, as it says in section 5.1 Object Format of my chapter in the nublu book :-

One word - all objects have this header. 3 bits reserved for GC state machine (mark, old, dirty) 12 bits object hash (for hashed Set usage) 5 bits compact class index, non-zero if the class is in a group of classes known as 'Compact Classes' 4 bits object format 6 bits object size, in 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: free chunk of memory, not an object at all, 3: 1-word) Two word - objects that are instances of classes not in the compact classes list. This second word sits in front of the header shown above. 30 bits oop of the class 2 bits header type as above Three word - objects that are too big for the size to be encoded in the one-word header, i.e. more than 255 bytes. This third word sits in front of the two shown above. 30 bits of size 2 bits header type as above

I think this is still the case.

I know it is common CS practice to point to the beginning of any given data object...

Since, I presume, the most interesting computations involve the text of the object, wouldn't it, on balance, be better to point to the _middle_ of the object and skip adding BaseHeaderSize to everything?

Actually, I suspect that the header is accessed a great deal since it is involved in message sending, anything requiring knowledge of the size and format, all that sort of stuff.

By the way, Is there anything screwy going on with small integers that causes negative values to be a different object type or something? It would be damn convenient if I could just ignore the sign bit when it suits my purpose..

Uh? Negative SmallIntegers are the same class, same type object as positive ones. Oops have the bottom two bits zero (because they're jst word aligned memory pointers) and SmallInts have a set bit at the bottom with the rest of the bits being an otherwise normal 2s complement value. What are you seeing to be thinking of anything stranger than that? If you're seeing = & - SmallInts as separate classes I think maybe your memory is messed up a bit. The sign bit is nothing to do with object class or format.

You'll need to tell us more, I think.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Oxymorons: Twelve-ounce pound cake