Make separate memory tables for various typed-objects.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. There is a hard maximum of 65535 'ent's accessible through the PS object
2. This means that there may only be 65535 vm allocations, total, per memory 
file, including all strings, dicts, names, um, arrays. Each of these is an ent.
3. This imposes a constraint on program complexity lower than the PLRM 
describes.

This burden could be somewhat relieved by including the type of the object as 
an additional memory identifier.

I propose to add additional SPECIAL entities SPECIAL_ARRAY SPECIAL_DICT 
SPECIAL_STRING to each memory file's table-zero. These special ents would point 
to head's of additional memory-table-chains specifically for objects of that 
type. Names and strings would still share the same space.

This would permit these limits:
65535 global names or strings
65535 local names or strings
65535 global arrays
65535 local arrays
65535 global dicts
65535 local dicts

Oh, and SPECIAL_FILE, too.

This would have an impact on the garbage collector logic, but I expect it would 
facilitate improvements there, too.

Original issue reported on code.google.com by luser.droog on 1 Dec 2013 at 12:54

[GoogleCodeExporter]

At first blush, I think this will require restoring the mtabaddr parameter 
(base memory table address (unsigned int)) to the table functions. This is a 
"local" table-zero for indexing 'ent's into the memory table chain.

Original comment by luser.droog on 1 Dec 2013 at 12:56

[GoogleCodeExporter]

Note, creating names directly in ps code creates a single vm-allocation for the 
string value. But, creating a name from a string still creates an allocation 
for the immutable value, since the source string may be changed.

Original comment by luser.droog on 1 Dec 2013 at 1:22

[GoogleCodeExporter]

There are only a few hundred names so no worries there. The object's ent field 
has been extended by 3 bits from the tag, giving > 500000 ents. 

But I'd still feel better with the different types in separate tables.

Original comment by luser.droog on 16 Dec 2013 at 11:42

[GoogleCodeExporter]

With the extra bits for extending the ent field, this change appears not to be 
necessary.

Original comment by luser.droog on 22 Feb 2015 at 9:06

• Changed state: WontFix