On Wed, Apr 8, 2020 at 10:21 AM Guido van Rossum wrote:

On Wed, Apr 8, 2020 at 10:05 AM Alex Hall wrote:

...

This would break uses of locals(), e.g.

Hm, okay, so suppose the code analysis was good enough to recognize most un-obfuscated uses of locals(), exec() and eval() (and presumably sys._getframe() -- IIUC there's already a Python implementation that generates less optimal code for functions where it detects usage of sys._getframe(), maybe IronPython).

...

Plus if the calculation raises an exception and I'm looking at the report on Sentry, I'd like to see the values of all variables. In particular I might have expected the function to return early and I want to see what `x` was.

That's a very valid objection. For simpletons like myself who just use pdb it could also be problematic. So at the very least there would have to be a way to turn it off, and probably it should have to be requested explicitly (maybe just with -O).

Even though it seems like a pedantically correct behavior to toss something after no future direct references to it are detected, it would just break so much existing code that the upgrade to an interpreter doing this would be a nightmare. Yes, people should in theory be using a context manager or explicit reference to things that need to live, but what _is_ an explicit reference if not the local scope? In practice code all over the place assumes "still in local scope" means the reference lives on. Including wrapped C/C++ code where the destructor frees underlying resources that are needed by other things outside of CPython's view. Different behavior when debugging or adding a debug print vs when running normally is bad. Seeing surprising behavior changes due to the addition or removal of code later in a scope that inadvertently changes when something's destructor is called is action at a distance and hard to debug. In my experience, people understand scope-based lifetime. It is effectively the same as modern C++ STL based pointer management semantics; destruction only happens after going out of scope or when explicitly called for. Making it optional? It'd need to be at least at a per-file level (from __future__ style... but called something else as this isn't likely to be our future default). A behavior change of this magnitude globally for a program with -O would just reinforce the existing practice of nobody practically using -O. (does anyone actually run their tests under -O let alone deploy with -O? I expect that to be a single digit % or lower minority) -gps

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c... _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CNON3M... Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 8 Apr 2020 10:18:47 -0700 Guido van Rossum wrote:

...

But when I leave "large" temp objects hanging and give a rip, I already stick in "del" statements anyway. Very rarely, but it happens.

I recall that in the development of asyncio there were a few places where we had to insert del statements, not so much to free a chunk of memory, but to cause some destructor or finalizer to run early enough. (IIRC not right at that moment, but at some later moment even if some Futures are still alive.) Those issues took considerable effort to find, and would conceivably have been prevented by this proposal.

If code relies on life variable analysis for correctness, it implies other Python implementations must implement it with exactly the same results. Regards Antoine.

On Thu, 9 Apr 2020 20:56:56 -0700 "Gregory P. Smith" wrote:

On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou wrote:

...

On Wed, 8 Apr 2020 10:18:47 -0700 Guido van Rossum wrote:

...

...

But when I leave "large" temp objects hanging and give a rip, I already stick in "del" statements anyway. Very rarely, but it happens.

I recall that in the development of asyncio there were a few places where we had to insert del statements, not so much to free a chunk of memory,

but

...

to cause some destructor or finalizer to run early enough. (IIRC not right at that moment, but at some later moment even if some Futures are still alive.) Those issues took considerable effort to find, and would conceivably have been prevented by this proposal.

If code relies on life variable analysis for correctness, it implies other Python implementations must implement it with exactly the same results.

As far as I know they all do? The existence of locals() as an API cements this behavior. If you want something to disappear from locals it requires an explicit del. (explicit is better than implicit and all...)

I mean all Python implementations would have to implement the exact same variant of live variable analysis. Right now there is none: variables are deleted when the frame dies (or when `del x` is issued explicitly, which does not imply any analysis :-)). Regards Antoine.

This would almost certainly break my code. As a DSL developer I do a lot of (exec | eval | introspection | ... ) shenanigans, that would make doing liveness analysis undecidable. On Wed, Apr 8, 2020 at 10:51 AM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

On Apr 8, 2020, at 09:57, Guido van Rossum wrote:

...

 Look at the following code.

def foo(a, b): x = a + b if not x: return None sleep(1) # A calculation that does not use x return a*b

This code DECREFs x when the frame is exited (at the return statement).

But (assuming) we can clearly see that x is not needed during the sleep (representing a big calculation), we could insert a "del x" statement before the sleep.

...

I think our compiler is smart enough to find out *some* cases where it

could safely insert such del instructions.

It depends on how much you’re willing to break and still call it “safely”.

def sleep(n): global store store = inspect.current_frame().f_back.f_locals['x']

This is a ridiculous example, but it shows that you can’t have all of Python’s dynamic functionality and still know when locals are dead. And there are less ridiculous examples with different code. If foo actually calls eval, exec, locals, vars, etc., or if it has a nested function that nonlocals x, etc., how can we spot that at compile time and keep x alive?

Maybe that’s ok. After all, that code doesn’t work in a Python implementation that doesn’t have stack frame support. Some of the other possibilities might be more portable, but I don’t know without digging in further.

Or maybe you can add new restrictions to what locals and eval and so on guarantee that will make it ok? Some code will break, but only rare “expert” code, where the authors will know how to work around it.

Or, if not, it’s definitely fine as an opt-in optimization: decorate the function with @deadlocals and that decorator scans the bytecode and finds any locals that are dead assuming there’s no use of locals/eval/cells/etc. and, because you told it to assume that by opting in to the decorator, it can insert a DELETE_FAST safely.

People already do similar things today—e.g., I’ve (only once in live code, but that’s still more than zero) used a @fastconst decorator that turns globals into consts on functions that I know are safe and are bottlenecks, and this would be no different. And of course you can add a recursive class decorator, or an import hook (or maybe even a command line flag or something) that enables it everywhere (maybe with a @nodeadlocals decorator for people who want it _almost_ everywhere but need to opt out one or two functions).

Did Victor Stinner explore this as one of the optimizations for FAT Python/PEP 511/etc.? Maybe not, since it’s not something you can insert a guard, speculatively do, and then undo if the guard triggers, which was I think his key idea.

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OIGCRV... Code of Conduct: http://python.org/psf/codeofconduct/

Could something just heuristically add del statements with an AST transformation that we could review with source control before committing? When the gc pause occurs is something I don't fully understand. For example: FWIW, this segfaults CPython in 2 lines: import ctypes ctypes.cast(1, ctypes.py_object) Interestingly, this (tends to?) work; even when there are ah scope closures?: import ctypes, gc x = 22 _id = id(x) del x gc.collect() y = ctypes.cast(_id, ctypes.py_object).value assert y == 22 Adding explicit calls to del with e.g. redbaron or similar would likely be less surprising. https://redbaron.readthedocs.io/en/latest/ Or something like a @jit decorator that pros would be aware of (who could just add del statements to free as necessary) On Wed, Apr 8, 2020, 10:29 PM Caleb Donovick wrote:

This would almost certainly break my code. As a DSL developer I do a lot of (exec | eval | introspection | ... ) shenanigans, that would make doing liveness analysis undecidable.

On Wed, Apr 8, 2020 at 10:51 AM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

...

On Apr 8, 2020, at 09:57, Guido van Rossum wrote:

...

 Look at the following code.

def foo(a, b): x = a + b if not x: return None sleep(1) # A calculation that does not use x return a*b

This code DECREFs x when the frame is exited (at the return statement).

But (assuming) we can clearly see that x is not needed during the sleep (representing a big calculation), we could insert a "del x" statement before the sleep.

...

I think our compiler is smart enough to find out *some* cases where it

could safely insert such del instructions.

It depends on how much you’re willing to break and still call it “safely”.

def sleep(n): global store store = inspect.current_frame().f_back.f_locals['x']

This is a ridiculous example, but it shows that you can’t have all of Python’s dynamic functionality and still know when locals are dead. And there are less ridiculous examples with different code. If foo actually calls eval, exec, locals, vars, etc., or if it has a nested function that nonlocals x, etc., how can we spot that at compile time and keep x alive?

Maybe that’s ok. After all, that code doesn’t work in a Python implementation that doesn’t have stack frame support. Some of the other possibilities might be more portable, but I don’t know without digging in further.

Or maybe you can add new restrictions to what locals and eval and so on guarantee that will make it ok? Some code will break, but only rare “expert” code, where the authors will know how to work around it.

Or, if not, it’s definitely fine as an opt-in optimization: decorate the function with @deadlocals and that decorator scans the bytecode and finds any locals that are dead assuming there’s no use of locals/eval/cells/etc. and, because you told it to assume that by opting in to the decorator, it can insert a DELETE_FAST safely.

People already do similar things today—e.g., I’ve (only once in live code, but that’s still more than zero) used a @fastconst decorator that turns globals into consts on functions that I know are safe and are bottlenecks, and this would be no different. And of course you can add a recursive class decorator, or an import hook (or maybe even a command line flag or something) that enables it everywhere (maybe with a @nodeadlocals decorator for people who want it _almost_ everywhere but need to opt out one or two functions).

Did Victor Stinner explore this as one of the optimizations for FAT Python/PEP 511/etc.? Maybe not, since it’s not something you can insert a guard, speculatively do, and then undo if the guard triggers, which was I think his key idea.

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OIGCRV... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DSIMIU... Code of Conduct: http://python.org/psf/codeofconduct/

Thanks for removing the mystery. FWIW, here are some of the docs and resources for memory management in Python; I share these not to be obnoxious or to atoen, but to point to the docs that would need updating to explain what is going on if this is not explicit. - https://docs.python.org/3/reference/datamodel.html#object.__del__ - https://docs.python.org/3/extending/extending.html?highlight=__del__#thin-ic... - https://docs.python.org/3/c-api/memory.html - https://docs.python.org/3/library/gc.html - https://docs.python.org/3/library/tracemalloc.html - https://devguide.python.org/gdb/ - https://devguide.python.org/garbage_collector/ - https://devguide.python.org/garbage_collector/#optimization-reusing-fields-t... - https://doc.pypy.org/en/latest/gc_info.html - https://github.com/jythontools/jython/blob/master/src/org/python/modules/gc.... https://javadoc.io/doc/org.python/jython-standalone/2.7.2/ org/python/modules/gc.html - https://github.com/IronLanguages/ironpython2/blob/master/Src/IronPython.Modu... https://github.com/IronLanguages/ironpython2/blob/master/Src/StdLib/Lib/test... https://github.com/IronLanguages/ironpython2/blob/master/Src/StdLib/Lib/test... https://github.com/IronLanguages/ironpython3/blob/master/Src/IronPython.Modu... - "[Python-Dev] Re: Mixed Python/C debugging" https://mail.python.org/archives/list/python-dev@python.org/message/Z3S2RAXR... - @anthonypjshaw's CPython Internals book has a (will have a) memory management chapter. - > And then take a look at how @ApacheArrow "supports zero-copy reads for lightning-fast data access without serialization overhead." - .@blazingsql … #cuDF … @ApacheArrow https://docs.blazingdb.com/docs/blazingsql … New #DataFrame Interface and when that makes a copy for 2x+ memory use - "A dataframe protocol for the PyData ecosystem" https://discuss.ossdata.org/t/a-dataframe-protocol-for-the-pydata-ecosystem/... Presumably, nothing about magic del statements would affect C extensions, Cython, zero-copy reads, or data that's copied to the GPU for faster processing; but I don't understand this or how weakrefs and c-extensions share memory that could be unlinked by a del. Would be interested to see the real performance impact of this potential optimization: - 10%: https://instagram-engineering.com/dismissing-python-garbage-collection-at-in... On Thu, Apr 9, 2020 at 2:48 PM Andrew Barnert wrote:

On Apr 8, 2020, at 23:53, Wes Turner wrote:

...

Could something just heuristically add del statements with an AST

transformation that we could review with source control before committing?

...

When the gc pause occurs is something I don't fully understand. For

example:

Your examples don’t have anything to do with gc pause.

...

FWIW, this segfaults CPython in 2 lines:

import ctypes ctypes.cast(1, ctypes.py_object)

Yes, because this is ultimately trying to print the repr of (PyObject*)1, which means calling some function that tries to dereference some member of a struct at address 1, which means trying to access an int or pointer or whatever at address 1 or 9 or 17 or whatever. On most platforms, those addresses are going to be unmapped (and, on some, illegally aligned to boot), so you’ll get a segfault. This has nothing to do with the GC, or with Python objects at all.

...

Interestingly, this (tends to?) work; even when there are ah scope closures?:

import ctypes, gc x = 22 _id = id(x) del x gc.collect() y = ctypes.cast(_id, ctypes.py_object).value assert y == 22

The gc.collect isn’t doing anything here.

First, the 22 object, like other small integers and a few other special cases, is immortal. Even after you del x, the object is still alive, so of course everything works.

Even if you used a normal object that does get deleted, it would get deleted immediately when the last reference to the value goes away, in that del x statement. The collect isn’t needed and doesn’t do anything relevant here. (It’s there to detect reference cycles, like `a.b=b; b.a=a; del a; del b`. Assuming a and b were the only references to their objects at the start, a.b and b.a are the only references at the end. They won’t be deleted by refcounting because there’s still one reference to each, but they are garbage because they’re not accessible. The gc.collect is a cycle detector that handles exactly this case.)

But your code may well still often work on most platforms. Deleting an object rarely unmaps its memory; it just returns that memory to the object allocator’s store. Eventually that memory will be reused for another object, but until it is, it will often still look like a perfectly valid value if you cheat and look at it (as you’re doing). (And even after it’s reused, it will often end up getting reused by some object of the same shape, so you won’t crash, you’ll just get odd results.)

Anyway, getting off this side track and back to the main point: releasing the locals reference to an object that’s no longer being used locally isn’t guaranteed to destroy the object—but in CPython, if locals is the only reference, the object will be destroyed immediately. That’s why Guido’s optimization makes sense.

The only way gc pause is relevant is for other implementations. For example, if CPython stops guaranteeing that x is alive until the end of the scope under certain conditions, PyPy could decide to do the same thing, and in PyPy, there is no refcount; garbage is deleted when it’s detected by the GC. So it wouldn’t be deterministic when x goes away, and the question of how much earlier does it go away and how much benefit there is becomes more complicated than in CPython. But the PyPy guys seem to be really good at figuring out how to test such questions empirically.