Potential bug in becomeForward:, need help!

Chris Muller afunkyobject at yahoo.com
Sun May 19 00:51:56 UTC 2002


Avi Bryant wrote:

Couldn't you have a special range of oids (ie, a bit flag somewhere in the
oid) marking it as a symbol?  Presumably this is what you mean when you
say SmallIntegers have special-value oids.  You would still have to read
the buffer to find out what symbol it was, but you would know from the oid
range that it was a Symbol and that you should read it in immediately.

============

Yes, that could probably work.  I am using 64-bit oids with special ranges for
things (which still leaves plenty for multi-terabyte sized databases).  But the
three kinds of buffers I have, ByteObjectBuffer, NormalObjectBuffer and
ClassObjectBuffer, are all lean and clean in terms of the "fields" they have;
meaning I currently have no special-case bit flags.  The code in the server
that traverses the buffers in the database file is simple and dense, controlled
solely by an optionally-supplied ReadStrategy, which tells it how deep it
should read for each instance variable.  This code could be modified to check
the bit of every referenced oid of every NormalObjectBuffer to see if it needs
to deviate deeper than what the ReadStrategy says.

Actually, I'm not sure it would be enough, because the becomeForward: may
affect me with other hashedCollection.  If it modifies the identityHash of
every object you become to, then the problem is probably more widespread than
just the Smalltalk hashed collection.  Maybe it is just the first one I hit in
my test script since I changed the code to use becomeFoward: instead of
become:..

I'll have to consider that further, but I think I am also still interested in
pursuing a client-side solution that involves fixing the becomeForward:.

Best Regards,
  Chris


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com



More information about the Squeak-dev mailing list