On Sat, 2 Feb 2002, Henrik Gedenryd wrote:

> Scott A Crosby wrote:
>
> >> collections, including method dictionaries. (I haven't rechecked my
> >> facts, this is all from memory, so please correct me if I've got any
> >> of the details wrong.)
> >
> > No, I preserve the old (flawed) behavior for method dictionaries, rather
> > than rebuilding a new image. True, this means that MethodDictionaries
> > should not be scaled beyond, say, 2000 or so methods. I don't consider
> > this a real problem.
> >
> > Scott
>
> For simplicity reasons they ought to be changed too, to keep everything the
> same. Do you have any benchmarks for such a change?
>

No, doing that change requires both a VM change and a smalltalk-level
change, Rebuilding a new incompatible image in the process. The gain is
marginal. No MethodDictionary is 1/3 the size that would start to expose
this problem.


> Also, changing the image format or rehashing all sets or any such should not
> be considered a problem with a new image format being instated anyway, so we
> ought to disregard such issues and just go for the best solution.

My earlier change is small-talk only, and leads to no image
incompatibility.

BTW<, using 65537 as the multiplier is a *BAD* idea.

What are:
   1*65537 \\ 4096
   2*65537 \\ 4096
   3*65537 \\ 4096
   4*65537 \\ 4096
   5*65537 \\ 4096
      ....

And why is it bad? :)

>
> PS. My thought was also that the two bits change should have a solid
> motivation. Even more so given the clear (yet not severe) disadvantages. "It
> might perhaps sometime become useful" is not enough IMHO.

I want to hear the rationale for it first. Does it save space? How much?
Is the performance degradation minor?

I'm beginning to think the future should be a completely new
ObjectMemory..

Scott