"Phillip J. Eby" <pje@telecommunity.com> writes:
At 11:35 AM 11/3/03 +0000, Michael Hudson wrote:
Armin Rigo <arigo@tunes.org> writes:
What seems to me like a good solution would be to use one relatively large "arena" per type and Python's memory allocator to subdivide each arena. If each arena starts at a pointer address which is properly aligned, then *(p&MASK) gives you the type of any object, and possibly even without much cache-miss overhead because there are not so many arenas in total (probably only 1-2 per type in common cases, and arenas can be large).
Hmm, maybe. I'm not going to make guesses about that one :-)
You guys do realize that this scheme would make it impossible to change an object's type, right? Unless of course you have some way to "search and replace" all references to an object.
I'd got this far...
And if you were to say, "well, we'll only use this trick for non-heap types", my question would be, how's the code doing *(p&MASK) going to know how *not* to do that? If heap types have a different layout, how can you inherit from a builtin type in pure Python? And so on.
... but somehow this point had escaped me. Well, you could do something like having a cookie[1] at the start of heap type pools that says "the pointer to the type object is actually at *(p-4)" but that's pretty sick (and puts branches in every type access). Darn. Oh well, I suspected my idea had to have some large problem, it just took longer that I expected for someone to spot it :-) Cheers, mwh [1] e.g. NULL... -- Presumably pronging in the wrong place zogs it. -- Aldabra Stoddart, ucam.chat