[Python-Dev] Looking for master thesis ideas involving Python

Michael Hudson 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[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 :-)


[1] e.g. NULL...

  Presumably pronging in the wrong place zogs it.
                                        -- Aldabra Stoddart, ucam.chat

More information about the Python-Dev mailing list