"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 :-)
Cheers,
mwh
[1] e.g. NULL...
--
Presumably pronging in the wrong place zogs it.
-- Aldabra Stoddart, ucam.chat
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4