New submission from Mark Shannon :
Large literals or function calls with many arguments can consume a lot of stack
space.
This will be a problem for any future work to use a contiguous stack for data
and possibly eliminate frame objects for most calls.
It is also possible (I haven&#
Change by Mark Shannon :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue43846>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24136
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25403
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 11e0b295dee235dd6fd66a10d4823b0dcb014dc4 by Mark Shannon in
branch 'master':
bpo-43846: Use less stack for large literals and calls (GH-25403)
https://github.com/python/cpython/commit/11e0b295dee235dd6fd66a10d4823b
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
I've not measured performance, as the sort of large literals it would impact
are very rare, and the sort of calls it would change are almost non-existent.
I'd be surprised if any performance difference could be reliably detected with
our current p
Mark Shannon added the comment:
The changes to pyc format aren't user visible so shouldn't matter,
but what about the dis output?
Consider this program:
def f():
try:
1/0
except:
return "fail"
Currently it compiles to:
2 0 SETUP_FINA
Mark Shannon added the comment:
Adding an extra flag seems like the sensible thing to do for 3.10
Longer term, we should decouple immutability from whether something is a heap
type.
I don't know why we would care that it is a heap type at all. Which bit of
memory it happens to sit in
Mark Shannon added the comment:
What exactly is the issue here?
That the line number is -1, or that is different from 3.9?
The `-1` should be `None`. I can fix that, but there is the issue of whether
the cleanup code in a with statement should have a line number or not.
The traceback for
Mark Shannon added the comment:
In this case, if happens that line 10 was the last line of code executing in
the body of the with statement.
But the reason it was listed, was that it was statically the last line of code
in the body.
If the body is something like:
1. if TRUE:
2. ...
3
Mark Shannon added the comment:
This test case was added for 3.10.
In 3.9 it reports that the pass statement executes, even though it is
unreachable.
https://github.com/python/cpython/blob/master/Lib/test/test_sys_settrace.py#L919
--
___
Python
Mark Shannon added the comment:
Using sentinels as a marker to terminate the line number table, might be a
problem if we want to use a different format. So I'm fixing this for 3.10.
--
___
Python tracker
<https://bugs.python.org/is
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24348
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25657
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
The additional cost will not only be the line number table, but we need to
store the line for exceptions that are reraised after cleanup.
Adding a column will mean more stack consumption.
--
___
Python tracker
Mark Shannon added the comment:
New changeset c76da79b37d2bcbe575cc927ba0a9b7a9ce465db by Mark Shannon in
branch 'master':
bpo-42739: Don't use sentinels to mark end of line table. (GH-25657)
https://github.com/python/cpython/commit/c76da79b37d2bcbe575cc927b
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24408
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25717
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
I'm going to set the line number for executing the `__exit__()` function as
that of the `with` keyword.
This should give a sensible traceback, and not break coverage, as the with
statement is already executed.
It will impact traces and profiles, which i
Change by Mark Shannon :
--
pull_requests: +24410
pull_request: https://github.com/python/cpython/pull/25719
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
> BTW, what are the three POP_TOP op codes in a row popping?
When exceptions are pushed to the stack, they are pushed as a triple: (exc,
type, traceback)
so when we pop them, we need three pops.
--
___
Pyt
Mark Shannon added the comment:
Responding to Serhiy's suggestions:
1 Add another column:
Adding another column makes for lots of repetition in larger try blocks, and
pushes useful information further to the right.
2 Add pseudo-instructions
I find those misleading, as they aren
Mark Shannon added the comment:
I've played around with a few formats, and what I've ended up with is this:
1. Use the >> marker for for exception targets, as well as normal branch
targets.
2. Add a text version of the exception handler table at the end of the
disassembly.
New submission from Mark Shannon :
PEP 634 has been updated to allow a faster and more robust implementation of
matching sequences and mappings: https://github.com/python/peps/pull/1937
It needs to be implemented.
--
assignee: Mark.Shannon
messages: 392330
nosy: Mark.Shannon
priority
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24415
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25723
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 088a15c49d99ecb4c3bef93f8f40dd513c6cae3b by Mark Shannon in
branch 'master':
bpo-43933: Show frame.f_lineno as None, rather than -1, if there is no line
number. (GH-25717)
https://github.com/python/cpyt
Mark Shannon added the comment:
New changeset 069e81ab3da46c441335ca762c4333b7bd91861d by Mark Shannon in
branch 'master':
bpo-43977: Use tp_flags for collection matching (GH-25723)
https://github.com/python/cpython/commit/069e81ab3da46c441335ca762c4333
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24440
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25729
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 5979e81a212949c62c2490167c9137d233d7de64 by Mark Shannon in
branch 'master':
bpo-43933: Set frame.f_lineno during call to __exit__ (GH-25719)
https://github.com/python/cpython/commit/5979e81a212949c62c2490167c9137
Mark Shannon added the comment:
I'm claiming that this is fixed.
Feel free to reopen if the additional line in tracing causes a problem.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python t
Change by Mark Shannon :
--
pull_requests: +24500
pull_request: https://github.com/python/cpython/pull/25813
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
New changeset 33ec88ac81f23668293d101b83367b086c795e5e by Mark Shannon in
branch 'master':
bpo-43977: Make sure that tp_flags for pattern matching are inherited
correctly. (GH-25813)
https://github.com/python/cpyt
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Definitely one for Python ideas.
Quite a good idea though.
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
Thanks for the responses.
Probably nothing to do for now.
--
resolution: -> postponed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
This seems to have been fixed sometime.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Mark Shannon :
Currently, the local variables (inc. cell and free vars) for functions and the
evaluation stack are kept in per-activation chunks in the frame object. This is
not a good design for modern hardware.
The local variables and stack are amongst the hottest memory
Change by Mark Shannon :
--
title: Store locals and evaluation stack should be stored in a contiguous,
per-thread stack -> Function locals and evaluation stack should be stored in a
contiguous, per-thread stack
___
Python tracker
<
New submission from Mark Shannon :
Consider this function, which has a syntax error on line 4.
>>> def f():
... try:
... 1/0
... except:
... pass
... except Exception:
... pass
3.9 reports an incorrect line number of 3.
3.10b reports an
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24606
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25939
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> needs patch
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Thanks everyone for the triaging and fixing.
--
___
Python tracker
<https://bugs.python.org/issue40222>
___
___
Python-bug
Mark Shannon added the comment:
Ned, no line numbers should never be None.
(Except under very unusual circumstances, like the trace function raising an
error)
Taking a look at the disassembly of execsitecustomize, there is a return with
no line number, which shouldn't h
Mark Shannon added the comment:
At yappi/_yappi.c:1261 sets an undocumented field on a CPython internal data
structure.
What did you believe that was supposed to do? use_tracing is not documented
anywhere.
We could add the field back and ignore it, but I doubt that would help you much
Mark Shannon added the comment:
If there is no C-API function that supports your needs, feel free to suggest
one.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
Removed message: https://bugs.python.org/msg393388
___
Python tracker
<https://bugs.python.org/issue43933>
___
___
Python-bugs-list m
Mark Shannon added the comment:
If there is no C-API function that supports your needs, feel free to suggest
one.
--
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
But what does "use it" mean?
What does setting `tstate->use_tracing = 1` do?
There is no documented behavior, so how do we know what assumptions people are
making about what happens when they set some field to 1?
As I said, we could keep the fie
Change by Mark Shannon :
--
pull_requests: +24671
pull_request: https://github.com/python/cpython/pull/26021
___
Python tracker
<https://bugs.python.org/issue40
Mark Shannon added the comment:
I know PyCode_NewWithPosOnlyArgs is declared as "PyAPI_FUNC" but that can't
make it part of the ABI unless it has stable behavior.
It can't have stable behavior because its inputs are complex, undefined, have
altered semantics and are in
Mark Shannon added the comment:
It is very little effort to add back the old function, so that isn't the
problem. It won't work properly, but it never did anyway. So I guess that's
sort of compatible.
Maybe the best thing is to put a big red warning in the docs and hope t
Mark Shannon added the comment:
Duplicate of https://bugs.python.org/issue43933
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
pull_requests: +24694
pull_request: https://github.com/python/cpython/pull/26054
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
pull_requests: +24699
pull_request: https://github.com/python/cpython/pull/26059
___
Python tracker
<https://bugs.python.org/issue40
Change by Mark Shannon :
--
pull_requests: +24702
pull_request: https://github.com/python/cpython/pull/26061
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24716
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26076
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 0acdf255a51b836c0b44f3676797620322974af3 by Mark Shannon in
branch '3.10':
[3.10] bpo-43933: Force RETURN_VALUE bytecodes to have line numbers (GH-26061)
https://github.com/python/cpython/commit/0acdf255a51b836c0b44f367679762
Mark Shannon added the comment:
I have to admit that I find the truncated version more readable.
Some sort of truncation is useful, as a regex could be thousands of character
long.
Adding the offset to the warning message seems like a useful addition.
--
nosy: +Mark.Shannon
New submission from Mark Shannon :
As described in PEP 659 (Specializing Adaptive Interpreter) the first part of
implementing specialization is to implement the machinery to do the quickening.
Conceptually, this is fairly simple: add a new field to the code object, which
points to the first
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24868
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26264
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
Add a version number to dict keys.
PEP 509 added a version number to dicts. Unfortunately this is no use for
optimizing attribute loads and store on instances.
We need to know whether the keys are as expected, not the dict as that is
likely to be different
Mark Shannon added the comment:
The memory saving comes from converting:
Py_ssize_t dk_size;
dict_lookup_func dk_lookup;
to:
uint8_t dk_log2_size;
uint8_t dk_loopup_kind; /* Only 3 possible values */
uint32_t dk_version;
which saves 8 bytes on a 64 bit machine (no saving
New submission from Mark Shannon :
In order to specialize calls to Python functions, or to inline them, we need to
know that the code object has not changed. It is also useful to know that the
globals, builtins and various defaults haven't changed either. Rather than
attempting to
Change by Mark Shannon :
--
pull_requests: +24891
pull_request: https://github.com/python/cpython/pull/26285
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
What's the test case, exactly?
ref.py for the other issue doesn't crash if I change "func.py" to "ref.py"
otherwise it just complains that "func.py" doesn't exist.
--
___
Mark Shannon added the comment:
The version is on the dict keys. It changes if the dict keys object changes in
a meaningful way.
So, no it doesn't change if a value is changed.
Nor would it change if the keys were shared and a new key-value pair is added
to a dict, but that key was al
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24925
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26333
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
http://theses.gla.ac.uk/2975/1/2011shannonphd.pdf page 128.
It means we don't need to cache a pointer to the keys, just the version number.
The version number is half the size (for 64 bit machines) and using it means
that we don't
Mark Shannon added the comment:
Which optimizations?
LOAD_GLOBAL:
Using a keys version instead of a whole dict version means that LOAD_GLOBAL
won't leak references. It also means that we can (in the future) remove the PEP
509 version and save 8 bytes per dict.
LOAD
New submission from Mark Shannon :
Should the tp_version overflow, and wrap around to a value previously used in
the opcache for LOAD_ATTR, then LOAD_ATTR could produce the wrong value.
It will take a fair bit of contrivance and a long time to do this, but it is
possible:
Run some code ~2000
Mark Shannon added the comment:
It is extremely unlikely, I agree. But not impossible.
I plan to fix it for 3.11. Once I've done that we can decide if backports are
worth it.
--
___
Python tracker
<https://bugs.python.org/is
Mark Shannon added the comment:
New changeset 6cc800d3634fdd002b986c3ffe6a3d5540f311a0 by Eric Snow in branch
'main':
bpo-43693: Clean up the PyCodeObject fields. (GH-26364)
https://github.com/python/cpython/commit/6cc800d3634fdd002b986c3ffe6a3d
Mark Shannon added the comment:
New changeset f8a95df84bcedebc0aa7132b3d1a4e8f000914bc by Mark Shannon in
branch 'main':
bpo-44206: Add a version number to dictionary keys (GH-26333)
https://github.com/python/cpython/commit/f8a95df84bcedebc0aa7132b3d1a4e
Change by Mark Shannon :
--
pull_requests: +25027
pull_request: https://github.com/python/cpython/pull/26432
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
For context, this behavior was introduced in https://bugs.python.org/issue43933
--
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
Why this occurs:
with cm:
A
break
translates to something like:
ex = cm.__exit__; cm.__enter__() # with cm
A
ex(...)
goto loop_end # break
So, the break is traced after the exit call.
However, this doesn't seem consistent wit
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25109
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26513
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 937cebc93b4922583218e0cbf0a9a14705a595b2 by Mark Shannon in
branch 'main':
bpo-44298: Fix line numbers for early exits in with statements. (GH-26513)
https://github.com/python/cpython/commit/937cebc93b4922583218e0cbf0a9a1
Change by Mark Shannon :
--
pull_requests: +25111
pull_request: https://github.com/python/cpython/pull/26516
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
Basic blocks have only a single exit, at the end.
https://en.wikipedia.org/wiki/Basic_block
If the devguide says otherwise it is wrong.
--
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
New changeset 001eb520b5757294dc455c900d94b7b153de6cdd by Mark Shannon in
branch 'main':
bpo-44187: Quickening infrastructure (GH-26264)
https://github.com/python/cpython/commit/001eb520b5757294dc455c900d94b7
New submission from Mark Shannon :
Port the implementation of LOAD_ATTR to the new adaptive interpreter
--
messages: 395271
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Port LOAD_ATTR to adaptive interpreter
___
Python
New submission from Mark Shannon :
Port the implementation of LOAD_GLOBAL to the new adaptive interpreter
Once this and https://bugs.python.org/issue44337 are implemented we can remove
the old opcache.
--
messages: 395272
nosy: Mark.Shannon
priority: normal
severity: normal
status
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25178
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26595
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Pablo,
Is there a bpo issue for the buildbot failures on Windows?
The failures I've been seeing are C stack overflows.
Long term, I expect to fix it by decoupling the C and Python stacks.
In the short term I have a couple of changes that might get it wo
New submission from Mark Shannon :
Running the buildbot for https://github.com/python/cpython/pull/26595
results in failures:
https://buildbot.python.org/all/#/builders/581/builds/63
Which claim that the address calculation in `LOAD_ATTR_MODULE` is out of bounds.
The tests pass with an added
Change by Mark Shannon :
--
nosy: +Mark.Shannon
nosy_count: 9.0 -> 10.0
pull_requests: +25208
pull_request: https://github.com/python/cpython/pull/26623
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
If I run the following on main
./configure --with-address-sanitizer
make clean
make -j12 test
I get 22 failures.
So something is broken.
test_lib2to3 does fork; at least it does when I run it under gdb
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
pull_requests: +25209
pull_request: https://github.com/python/cpython/pull/26624
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
I still get quite a few failures on the main branch.
It seems like ceval.c:1600 upsets the sanitizer, at least for gcc.
There isn't anything wrong with that line, but as I plan to change it anyway I
guess it doesn't matter:
https://github.com/pyth
Mark Shannon added the comment:
What commit are you running that on?
--
___
Python tracker
<https://bugs.python.org/issue44363>
___
___
Python-bugs-list mailin
Mark Shannon added the comment:
This line seems to be responsible for most of the failures:
https://github.com/python/cpython/blob/main/Objects/frameobject.c#L985
Which does appear to be a true positive.
--
___
Python tracker
<ht
Mark Shannon added the comment:
No, this is done
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
New changeset e117c0283705943189e6b1aef668a1f68f3f00a4 by Mark Shannon in
branch 'main':
bpo-44337: Port LOAD_ATTR to PEP 659 adaptive interpreter (GH-26595)
https://github.com/python/cpython/commit/e117c0283705943189e6b1aef668a1
Mark Shannon added the comment:
New changeset 54cb63863f19a7c64d9a3a5fd97bdfc0dd7ab374 by Mark Shannon in
branch 'main':
bpo-44348: Move trace-info to thread-state (GH-26623)
https://github.com/python/cpython/commit/54cb63863f19a7c64d9a3a5fd97bdf
Mark Shannon added the comment:
It looks like I've been a bit unfair to the address sanitizer.
It does appear to produce incorrect locations sometimes, but that's not really
a false positive and the reports are generally useful.
--
Mark Shannon added the comment:
Yes. Simpler is good.
I think it will also be better for performance:
In general, we don't know what X is in `from Y import X`. It could be a module
or anything else.
However, if we are accessing an attribute it is quite likely to be a module or
class
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25225
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26638
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
pull_requests: +25226
pull_request: https://github.com/python/cpython/pull/26639
___
Python tracker
<https://bugs.python.org/issue44
301 - 400 of 1219 matches
Mail list logo
