RetroSearch Browse

Fri Oct 31 06:42:52 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039861.html

"Brett C." <bac at OCF.Berkeley.EDU> writes:

>> I take it from your posting of last week that you've thought about
>> other ways of implementing exception handling?  I guess a
>> non-reference count based GC is a prerequisite for that...
>> 
>
> Yeah, I have tossed the exception handling idea around in my head a
> little, but the culmination was what I posted.
>
> And a non-refcount GC would definitely help, even if the exception
> handling wasn't changed.  More places where you could just return NULL
> instead of having to deal with DECREFing objects.

And reducing the memory overhead of objects.

Here's my crazy idea that's been knocking around my head for a while.
I wonder if anyone can shoot in down in flames.

Remove the ob_type field from all PyObjects.  Make pymalloc mandatory,
make it use type specific pools and store a pointer to the type object
at the start of each pool.

So instead of 

  p->ob_type

it's

  *(p&MASK)

I think having each type in its own pools would also let you lose the
gc_next & gc_prev fields.

Combined with a non-refcount GC, you could hammer sizeof(PyIntObject)
down to sizeof(long)!

(Actually, a potential killer is assigning to __class__ -- maybe you
could only do this for heaptypes)

Cheers,
mwh

-- 
  To summarise the summary of the summary:- people are a problem.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 12

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039861.html below:

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