On 10/3/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > For stack frames,
> > such a registration is difficult to make efficient.
>
> Also very error-prone if you happen to miss one. Although
> maybe no more error-prone than getting the reference
> counting right.
Maybe, but
Martin v. Löwis wrote:
> For stack frames,
> such a registration is difficult to make efficient.
Also very error-prone if you happen to miss one. Although
maybe no more error-prone than getting the reference
counting right.
--
Greg
___
Python-Dev mailin
> To further elaborate, the main obstacle is with extension modules.
> Most of them create roots and there is no defined API for the Python
> interpreter to find them.
That is a problem, but furthermore, I feel that local variables stored
in stack frames of threads are even more difficult to integ
Hrvoje Nikšić wrote:
> That sounds like a case for the Pixbuf object to have a "close" method
> (not necessarily called that) that releases the resources. The point of
> GC is that you normally don't care if memory is released sooner or
> later;
I think the problem here is that the GC's lack of k
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
>> Why isn't the mark-and-sweep mechanism used for all memory
>> management?
>
> See above - it's not implementable, because the root objects get not
> tracked.
To further elaborate, the main obstacle is with extension modules.
Most of them create roots a
Jeremy covered already most of it, so I'll only address specific points:
> and I think that the current gc
> module is of the mark-and-sweep variety.
That is incorrect. It's two phases, but in the first phase, it isn't
"mark", but "count", and in the second phase, it's not "sweep" but
"break". To
On 10/2/07, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> > Correct. And that reminds me of the limitation of the the Python GC:
> > it doesn't take into account how much memory is being indirectly
> > retained by a Python Object. Like i
On Tue, 2007-10-02 at 11:30 +0100, Gustavo Carneiro wrote:
> even large memory objects, there is always explicit
> management.
> cStringIO's "close" method provides a precedent.
>
> I think close in real files is needed not so much because you want to
> free memory, but th
On 02/10/2007, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> > Correct. And that reminds me of the limitation of the the Python GC:
> > it doesn't take into account how much memory is being indirectly
> > retained by a Python Object. Lik
On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> Correct. And that reminds me of the limitation of the the Python GC:
> it doesn't take into account how much memory is being indirectly
> retained by a Python Object. Like in the example I already gave,
> gtk.gdk.Pixbuf can easily hold
On 02/10/2007, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Justin Tulloss wrote:
> > > Would
> > > somebody care to give me a brief overview on how the current gc module
> > > interacts with the interpreter
> >
> > The cyclic GC kicks in when memo
[xposted to python-ideas, reply-to python-ideas, leaving python-dev in
to correct misinformation]
On Tue, Oct 02, 2007, Greg Ewing wrote:
>
> The cyclic GC kicks in when memory is running low.
Not at all. The sole and only basis for GC is number of allocations
compared to number of de-allocatio
On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > This isn't true at all. It's triggered by heuristics based on the
> > total number of allocated objects.
>
> Hmmm, all right, it seems I don't know what I'm
> talking about. I'll shut up now before I spread
> any more misinf
Adam Olsen wrote:
> This isn't true at all. It's triggered by heuristics based on the
> total number of allocated objects.
Hmmm, all right, it seems I don't know what I'm
talking about. I'll shut up now before I spread
any more misinformation. Sorry.
--
Greg Ewing, Computer Science Dept, +-
Justin Tulloss wrote:
> When what memory is running low? Its default pool? System memory?
I'm not sure of the details, but I think it keeps
a high-water mark of the amount of memory allocated
for Python objects so far. When that is reached, it
tries to free up memory by cyclic GC, and only
malloc
On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Justin Tulloss wrote:
> > Would
> > somebody care to give me a brief overview on how the current gc module
> > interacts with the interpreter
>
> The cyclic GC kicks in when memory is running low. Since
This isn't true at all. It's triggered by
> The cyclic GC kicks in when memory is running low.
When what memory is running low? Its default pool? System memory?
Justin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
Justin Tulloss wrote:
> Is the trend going to be to
> move away from reference counting and towards the mark-and-sweep
> implementation that currently exists, or is reference counting a firmly
> ingrained tradition?
It's hard to predict the future, but the general feeling
I get is that many peo
On 10/1/07, Justin Tulloss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've been doing some tests on removing the GIL, and it's becoming clear that
> some basic changes to the garbage collector may be needed in order for this
> to happen efficiently. Reference counting as it stands today is not very
>
On 01/10/2007, Justin Tulloss <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I've been doing some tests on removing the GIL, and it's becoming clear
> that some basic changes to the garbage collector may be needed in order for
> this to happen efficiently. Reference counting as it stands today is not
>
Hello,
I've been doing some tests on removing the GIL, and it's becoming clear that
some basic changes to the garbage collector may be needed in order for this
to happen efficiently. Reference counting as it stands today is not very
scalable.
I've been looking into a few options, and I'm leaning
21 matches
Mail list logo
