Hash arrays mechanism is not general

[rptb1]

The interface and implementation might be improved by providing a way to "reallocate" an object, in the sense that the client can inform the MPS that a new object has the same mortality properties as an existing object. In this case, the mutator would allocate the new hash array with the same props as the old one, and the MPS could place it in e.g. the same generation. This would be a general interface not restricted to the rehashing problem.

Originally posted by @rptb1 in #215 (comment)

[rptb1]

Note that this is not how the hash arrays mechanism works currently, as seen in #230 . The current implementation works by marking an allocation point with a flag that makes it behave permanently as if it is in "ramping mode", so that it does not contribute to garbage collection scheduling. It does not affect its locus or mortality estimation. See

mps/code/poolamc.c

Lines 961 to 969 in 179341b

	/* If ramping, or if the buffer is intended for allocating hash
	* table arrays, defer the size accounting. */
	if ((amc->rampMode == RampRAMPING
	&& buffer == amc->rampGen->forward
	&& gen == amc->rampGen)
	|| amcbuf->forHashArrays)
	{
	MustBeA(amcSeg, seg)->deferred = TRUE;
	}

The above is not well documented but that will be improved by the edits from yesterday's review of #230 .