[issue46817] Add a line-start table to the code object.

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46817] Add a line-start table to the code object.

[Mark Shannon]

Mark Shannon  added the comment:

sys.settrace line events cannot use the co_lines table. They need additional 
state, as we don't want to trace the same line twice (unless there is a 
backwards jump).

Using the start of a entry in `co_lines` doesn't work when some entries have no 
line number.
E.g.
list(co.co_lines):

(0, 2, 1)
(2, 4, None)
(4, 6, 1)

The instruction @ byte offset 4 starts an entry for line 1, but does not start 
line 1.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46817] Add a line-start table to the code object.

[Irit Katriel]

Irit Katriel  added the comment:

I can see the linestarts used in trace.py to figure out coverage. But for this 
duplications don't make a difference (they are deduped in _find_lines_from_code 
anyway), right? 

Where else are they used, such that the current scheme may not work?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46817] Add a line-start table to the code object.

[Mark Shannon]

New submission from Mark Shannon :

Computing whether an instruction is the first on a line (for tracing) in the 
interpreter is complicated and slow. Doing it in the compiler should be simpler 
and has no runtime cost.

Currently we decide if the current instruction is the first on a line, by using 
the `co_lines` table, but if the previous instruction executed was a jump from 
the same line over a block of instructions with different line number(s) then 
we can get this wrong.

This doesn't seem to a problem now, but could be with either: 
Specialization of FOR_ITER inlining generators, or
Compiler improvements leading to different code layout.


The table is only one bit per instruction, so shouldn't be a problem in terms 
of space.

--
components: Interpreter Core
messages: 413651
nosy: Mark.Shannon, iritkatriel
priority: normal
severity: normal
status: open
title: Add a line-start table to the code object.
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com