Why not make the garbage collector check the reference count before freeing
objects? Only c extensions would increment the ref count while python code
would just use garbage collector making ref count = 0. That way even the
existing c extensions would continue to work.
Regarding to Java using
On 06/22/2017 10:26 PM, Rustom Mody wrote:
Lawrence d'Oliveiro was banned on 30th Sept 2016 till end-of-year
https://mail.python.org/pipermail/python-list/2016-September/714725.html
Is there still a ban?
My apologies to Lawrence, I completely forgot.
The ban is now lifted.
--
~Ethan~
--
htt
Gregory Ewing :
> Lawrence D’Oliveiro wrote:
>> what WOULD you consider to be so “representative”?
>
> I don't claim any of them to be representative. Different GC
> strategies have different characteristics.
My experiences with Hotspot were a bit disheartening. GC is a winning
concept provided t
Lawrence D’Oliveiro wrote:
what WOULD you consider to be so “representative”?
I don't claim any of them to be representative. Different GC
strategies have different characteristics.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
And, BTW, my rule of thumb came from experiences with the Hotspot JRE.
I wouldn't take a Java implementation to be representative of
the behaviour of GC systems in general.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Thursday, June 22, 2017 at 4:28:03 AM UTC+5:30, Steve D'Aprano wrote:
> On Thu, 22 Jun 2017 08:23 am, breamoreboy wrote:
>
> > Don't you know that Lawrence D’Oliveiro has been banned from the mailing
> > list
> > as he hasn't got a clue what he's talking about,
>
> That's not why he was give
On Fri, 23 Jun 2017 01:07 am, breamore...@gmail.com wrote:
> 11 comments on the thread "Instagram: 40% Py3 to 99% Py3 in 10 months" showing
> that he knows as much about Unicode as LDO knows about garabge collection.
Who cares? Every time he opens his mouth to write absolute rubbish he just make
On Jun 22, 2017 4:03 PM, "Chris Angelico" wrote:
On Fri, Jun 23, 2017 at 5:22 AM, CFK wrote:
> On Jun 22, 2017 9:32 AM, "Chris Angelico" wrote:
>
> On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
>> When
>> I draw memory usage graphs, I see sawtooth waves to the memory usage
which
>> suggest that
On Fri, Jun 23, 2017 at 5:22 AM, CFK wrote:
> On Jun 22, 2017 9:32 AM, "Chris Angelico" wrote:
>
> On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
>> When
>> I draw memory usage graphs, I see sawtooth waves to the memory usage which
>> suggest that the garbage builds up until the GC kicks in and re
On Thursday, June 22, 2017 at 11:07:36 AM UTC-4, bream...@gmail.com wrote:
> On Wednesday, June 21, 2017 at 11:58:03 PM UTC+1, Steve D'Aprano wrote:
> > On Thu, 22 Jun 2017 08:23 am, breamoreboy wrote:
> >
> > > Don't you know that Lawrence D’Oliveiro has been banned from the mailing
> > > list
>
On Jun 22, 2017 9:32 AM, "Chris Angelico" wrote:
On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
> When
> I draw memory usage graphs, I see sawtooth waves to the memory usage which
> suggest that the garbage builds up until the GC kicks in and reaps the
> garbage.
Interesting. How do you actually
On Fri, Jun 23, 2017 at 1:48 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> not "aim for 400MB because the garbage collector is only 10%
>> efficient". Get yourself a better garbage collector. Employ Veolia or
>> something.
>
> It's about giving GC room (space- and timewise) to operate. Also, y
Marko Rauhamaa :
> Chris Angelico :
>
>> not "aim for 400MB because the garbage collector is only 10%
>> efficient". Get yourself a better garbage collector. Employ Veolia or
>> something.
>
> It's about giving GC room (space- and timewise) to operate. Also, you
> don't want your memory consumptio
Chris Angelico :
> not "aim for 400MB because the garbage collector is only 10%
> efficient". Get yourself a better garbage collector. Employ Veolia or
> something.
It's about giving GC room (space- and timewise) to operate. Also, you
don't want your memory consumption to hit the RAM ceiling even
On Thu, Jun 22, 2017 at 11:27 PM, Marko Rauhamaa wrote:
> CFK :
>
>> Yes, and this is why I suspect CPython would work well too. My usage
>> pattern may be similar to Python usage patterns. The only way to know for
>> sure is to try it and see what happens.
>
> I have a rule of thumb that your ap
CFK :
> Yes, and this is why I suspect CPython would work well too. My usage
> pattern may be similar to Python usage patterns. The only way to know for
> sure is to try it and see what happens.
I have a rule of thumb that your application should not need more than
10% of the available RAM. If y
On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
> When
> I draw memory usage graphs, I see sawtooth waves to the memory usage which
> suggest that the garbage builds up until the GC kicks in and reaps the
> garbage.
Interesting. How do you actually measure this memory usage? Often,
when a GC frees u
On Jun 22, 2017 12:38 AM, "Paul Rubin" wrote:
Lawrence D’Oliveiro writes:
> while “memory footprint” depends on how much memory is actually being
> retained in accessible objects.
If the object won't be re-accessed but is still retained by gc, then
refcounting won't free it either.
> Once agai
On Jun 21, 2017 1:38 AM, "Paul Rubin" wrote:
Cem Karan writes:
> I'm not too sure how much of performance impact that will have. My
> code generates a very large number of tiny, short-lived objects at a
> fairly high rate of speed throughout its lifetime. At least in the
> last iteration of th
Lawrence D’Oliveiro writes:
> while “memory footprint” depends on how much memory is actually being
> retained in accessible objects.
If the object won't be re-accessed but is still retained by gc, then
refcounting won't free it either.
> Once again: The trouble with GC is, it doesn’t know when
On Thu, 22 Jun 2017 10:30 am, Lawrence D’Oliveiro wrote:
> Once again: The trouble with GC is, it doesn’t know when to kick in: it just
> keeps on allocating memory until it runs out.
Once again: no it doesn't.
Are you aware that CPython has a GC? (Or rather, a *second* GC, apart from the
refer
On Thu, 22 Jun 2017 08:23 am, breamore...@gmail.com wrote:
> Don't you know that Lawrence D’Oliveiro has been banned from the mailing list
> as he hasn't got a clue what he's talking about,
That's not why he was given a ban. Being ignorant is not a crime -- if it were,
a lot more of us would be
Lawrence D’Oliveiro writes:
> The trouble with GC is, it doesn’t know when to kick in: it just keeps
> on allocating memory until it runs out.
That's not how GC works, geez. Typically it would run after every N
bytes of memory allocated, for N chosen to balance memory footprint
with cpu overhead
Paul Rubin :
> How it works (i.e. what the implementation does) is quite simple and
> understandable. The amazing thing is that it doesn't leak memory
> catastrophically.
If I understand it correctly, the 32-bit Go language runtime
implementation suffered "catastrophically" at one point. The reas
Cem Karan writes:
> I'm not too sure how much of performance impact that will have. My
> code generates a very large number of tiny, short-lived objects at a
> fairly high rate of speed throughout its lifetime. At least in the
> last iteration of the code, garbage collection consumed less than 1
On Jun 20, 2017, at 1:19 AM, Paul Rubin wrote:
> Cem Karan writes:
>> Can you give examples of how it's not reliable?
>
> Basically there's a chance of it leaking memory by mistaking a data word
> for a pointer. This is unlikely to happen by accident and usually
> inconsequential if it does ha
Paul Rubin :
> The simplest way to start experimenting with GC in Python might be to
> redefine the refcount macros to do nothing, connect the allocator to
> the Boehm GC, and stop all the threads when GC time comes. I don't
> know if Guile has threads at all, but I know it uses the Boehm GC and
>
Cem Karan writes:
> Can you give examples of how it's not reliable?
Basically there's a chance of it leaking memory by mistaking a data word
for a pointer. This is unlikely to happen by accident and usually
inconsequential if it does happen, but maybe there could be malicious
data that makes it
Chris Angelico writes:
> Or let's look at it a different way. Instead of using a PyObject* in C
> code, you could write C++ code that uses a trivial wrapper class that
> holds the pointer, increments its refcount on construction, and
> decrements that refcount on destruction.
That's the C++ STL s
On Tue, Jun 20, 2017 at 1:52 PM, Rustom Mody wrote:
> Saw this this morning
> https://medium.com/@alexdixon/functional-programming-in-javascript-is-an-antipattern-58526819f21e
>
> May seem irrelevant to this, but if JS, FP is replaced by Python, GC it
> becomes
> more on topical
https://rhetting
On Tuesday, June 20, 2017 at 5:53:00 AM UTC+5:30, Cem Karan wrote:
> On Jun 19, 2017, at 6:19 PM, Gregory Ewing wrote:
>
> > Ethan Furman wrote:
> >> Let me ask a different question: How much effort is required at the C
> >> level when using tracing garbage collection?
> >
> > That depends on t
On Jun 19, 2017, at 6:19 PM, Gregory Ewing wrote:
> Ethan Furman wrote:
>> Let me ask a different question: How much effort is required at the C level
>> when using tracing garbage collection?
>
> That depends on the details of the GC implementation, but often
> you end up swapping one form o
Ethan Furman wrote:
Let me ask a different question: How much effort is required at the C
level when using tracing garbage collection?
That depends on the details of the GC implementation, but often
you end up swapping one form of boilerplate (maintaining ref
counts) for another (such as makin
On Tue, Jun 20, 2017 at 1:44 AM, Skip Montanaro
wrote:
> On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman wrote:
>
>> Programming at the C level is not working in Python, and many Python
>> niceties simply don't exist there.
>
>
> True, but a lot of functionality available to Python programmers exi
On 06/19/2017 08:44 AM, Skip Montanaro wrote:
On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman wrote:
Programming at the C level is not working in Python, and many Python niceties
simply don't exist there.
True, but a lot of functionality available to Python programmers exists at the
extensi
On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman wrote:
> Programming at the C level is not working in Python, and many Python
> niceties simply don't exist there.
True, but a lot of functionality available to Python programmers exists at
the extension module level, whether delivered as part of t
On 06/19/2017 08:06 AM, Skip Montanaro wrote:
On Mon, Jun 19, 2017 at 9:20 AM, Ethan Furman wrote:
Reference counting is a valid garbage collecting mechanism, therefore Python is
also a GC language.
Garbage collection is usually thought of as a way to remove responsibility for
tracking of
On Mon, Jun 19, 2017 at 9:20 AM, Ethan Furman wrote:
> Reference counting is a valid garbage collecting mechanism, therefore
> Python is also a GC language.
Garbage collection is usually thought of as a way to remove responsibility
for tracking of live data from the user. Reference counting doe
On Monday, June 19, 2017 at 7:40:49 PM UTC+5:30, Robin Becker wrote:
> On 19/06/2017 01:20, Paul Rubin wrote:
> ...
> > the existing C API quite seriously. Reworking the C modules in the
> > stdlib would be a large but not impossible undertaking. The many
> > external C modules out there woul
On 06/19/2017 07:10 AM, Robin Becker wrote:
I have always found the management of reference counts to be one of the hardest
things about the C api. I'm not sure
exactly how C extensions would/should interact with a GC python. There seem to be
different approaches eg lua & go are
both GC langu
On 19/06/2017 01:20, Paul Rubin wrote:
...
the existing C API quite seriously. Reworking the C modules in the
stdlib would be a large but not impossible undertaking. The many
external C modules out there would be more of an issue.
I have always found the management of reference counts to b
I always thought the GIL removal obstacle was the need to put locks
around every refcount adjustment, and the only real cure for that is to
use a tracing GC. That is a good idea in many ways, but it would break
the existing C API quite seriously. Reworking the C modules in the
stdlib would be a l
On Tue, Jun 13, 2017 at 1:53 PM, Terry Reedy wrote:
> This was tried at least once, perhaps 15 years ago.
Yes, I believe Greg Smith (?) implemented a proof-of-concept in about the
Python 1.4 timeframe. The observation at the time was that it slowed down
single-threaded programs too much to be a
On 6/13/2017 12:09 PM, Robin Becker wrote:
On 11/06/2017 07:27, Steve D'Aprano wrote:
I'm tired of people complaining about the GIL as a "mistake" without
acknowledging that it exists for a reason.
I thought we were also consenting adults about problems arising from bad
extensions. T
On Tue, Jun 13, 2017 at 11:09 AM, Robin Becker wrote:
> I looked at Larry's talk with interest. The GIL is not a requirement as he
> pointed out at the end, both IronPython and Jython don't need it.
But they don't support CPython's extension module API either, I don't
think. (I imagine that mig
On 11/06/2017 07:27, Steve D'Aprano wrote:
I'm tired of people complaining about the GIL as a "mistake" without
acknowledging that it exists for a reason.
I thought we were also consenting adults about problems arising from bad
extensions. The GIL is a blocker for cpython's ability
On Sun, 11 Jun 2017 04:21 pm, Stefan Behnel wrote:
> Serhiy Storchaka schrieb am 11.06.2017 um 07:11:
>> And also GIL is used for guaranteeing atomicity of many operations and
>> consistencity of internal structures without using additional locks. Many
>> parts of the core and the stdlib would j
Serhiy Storchaka schrieb am 11.06.2017 um 07:11:
> 10.06.17 15:54, Steve D'Aprano пише:
>> Larry Hastings is working on removing the GIL from CPython:
>>
>> https://lwn.net/Articles/723949/
>>
>> For those who don't know the background:
>>
>> - The GIL (Global Interpreter Lock) is used to ensure th
10.06.17 15:54, Steve D'Aprano пише:
Larry Hastings is working on removing the GIL from CPython:
https://lwn.net/Articles/723949/
For those who don't know the background:
- The GIL (Global Interpreter Lock) is used to ensure that only one piece of
code can update references to an object at a
On 10-6-2017 14:54, Steve D'Aprano wrote:
> Larry Hastings is working on removing the GIL from CPython:
>
> https://lwn.net/Articles/723949/
Here is Larry's "How's it going" presentation from Pycon 2017 on this subject
https://www.youtube.com/watch?v=pLqv11ScGsQ
-irmen
--
https://mail.python.o
Larry Hastings is working on removing the GIL from CPython:
https://lwn.net/Articles/723949/
For those who don't know the background:
- The GIL (Global Interpreter Lock) is used to ensure that only one piece of
code can update references to an object at a time.
- The downside of the GIL is tha
51 matches
Mail list logo
