[Python-Dev] Looking for master thesis ideas involving Python
mwh at python.net
Mon Nov 3 14:59:40 EST 2003
"Phillip J. Eby" <pje at telecommunity.com> writes:
> At 11:35 AM 11/3/03 +0000, Michael Hudson wrote:
>>Armin Rigo <arigo at 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 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 :-)
 e.g. NULL...
Presumably pronging in the wrong place zogs it.
-- Aldabra Stoddart, ucam.chat
More information about the Python-Dev