Removal of SET_LINENO (experimental)

[marangoz]

BPO	401022
Nosy	@gvanrossum, @tim-one, @smontanaro, @nascheme
Files	None: None

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2002-08-04.21:55:08.000>
created_at = <Date 2000-07-30.23:08:45.000>
labels = ['interpreter-core']
title = 'Removal of SET_LINENO (experimental)'
updated_at = <Date 2002-08-04.21:55:08.000>
user = 'https://bugs.python.org/marangoz'

bugs.python.org fields:

activity = <Date 2002-08-04.21:55:08.000>
actor = 'skip.montanaro'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2000-07-30.23:08:45.000>
creator = 'marangoz'
dependencies = []
files = ['2667']
hgrepos = []
issue_num = 401022
keywords = ['patch']
message_count = 18.0
messages = ['33597', '33598', '33599', '33600', '33601', '33602', '33603', '33604', '33605', '33606', '33607', '33608', '33609', '33610', '33611', '33612', '33613', '33614']
nosy_count = 6.0
nosy_names = ['gvanrossum', 'tim.peters', 'jhylton', 'skip.montanaro', 'marangoz', 'nascheme']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue401022'
versions = []

[marangoz]

No description provided.

[marangoz]

For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

[marangoz]

A nit: inline the argfetch in CALL_TRACE and goto the switch,
instead of jumping to get_oparg which splits the sequence
[fetch opcode, fetch oparg] -- this can slow things down.

[gvanrossum]

Status set to postponed to indicate that this is still experimental.

[marangoz]

Another rewrite, making this whole strategy b/w compatible according to
the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html

Changes:

1. f.f_lineno is computed and updated on f_lineno attribute requests for
   f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated
   on *all* attribute accesses (in LOAD_ATTR in the main loop).

2. The standard setup does not generate SET_LINENO, but uses
   co_lnotab for computing the source line number (e.g. tracebacks)
   This is equivalent to the actual "python -O".

3. With "python -d", we fall back to the current version of the
   interpreter (with SET_LINENO) thus making it easy to test whether
   this patch fully replaces SET_LINENO's behavior.
   (modulo f->f_lineno accesses from legacy C code, but this is insane).

IMO, this version already worths the pain to be truly tested and improved.

One improvement is to define a nicer public C API for breakpoints:

• PyCode_SetBreakPointAtLine(line)
• PyCode_SetBreakPointAtAddr(addr)
  or similar, which would install a CALL_TRACE opcode in the appropriate
  location of the copy of co_code.

Another idea is to avoid duplicating the entire co_code just for storing
the CALL_TRACE opcodes. We can store them in the original and keep
a table of breakpoints. Setting the breakpoints would occur whenever
the sys.settrace hook is set.

[marangoz]

A last tiny fix of the SET_LINENO opcode for better b/w compatibility.
Stopping here and entering standby mode for reactions & feedback.

PS: the last idea about not duplicating co_code and tweaking the
original with CALL_TRACE is a bad one. I remember Guido being
against it because co_code could be used elsewhere (copied, written
to disk, whatever) and he's right! Better operate on an internal copy
created in ceval.

[marangoz]

Fix missing DECREF on error condition in start_tracing()
+ some renaming.

[gvanrossum]

Vladimir, are you there?

The patch doesn't apply cleanly to the current CVS tree any more...

[marangoz]

noreply@sourceforge.net wrote:

Date: 2000-Oct-25 13:56
By: gvanrossum

Comment:
Vladimir, are you there?

So-so :) I'm a moving target, checking my mail occasionally these days.
Luckily, today is one of these days.

The patch doesn't apply cleanly to the current CVS tree any more...

Ah, this one's easy. Here's an update relative to 2.0 final, not CVS.
I got some r/w access error trying to update my CVS copy from SF
that I have no time to investigate right now... The Web interface still
works though :)

[marangoz]

Oops, the last patch update does not contain the f.f_lineno
computation in frame_getattr. This is necessary, cf. the
following messages:
http://www.python.org/pipermail/python-dev/2000-July/014395.html
http://www.python.org/pipermail/python-dev/2000-July/014401.html

Patch assigned to Guido, for review or further assignment.

[gvanrossum]

Rejected. It's in the archives for reference, but for now, I don't think it's worth spending cycles worrying about this kind of stuff. I'll eventually redesign the entire VM.

[gvanrossum]

Logged In: YES
user_id=6380

Tim wants to revisit this. It could be the quickest way to a
7% speedup in pystone that we can think of...

[tim-one]

Logged In: YES
user_id=31435

Unassigned again -- I'm not gonna get to this in this
lifetime.

[nascheme]

Logged In: YES
user_id=35752

I worked a bit on porting to this patch to 2.2+ CVS. I
ran into a snag with generators. Generators save the
instruction pointer (i.e. the bytecode offset) on yield.
That makes the on-the-fly bytecode translation approach
more complicated.

Since Guido is going to redesign the whole VM it's probably
not work spending any more effort on this. :-)

[jhylton]

Logged In: YES
user_id=31392

Just in case Guido doesn't get to that VM redesign next
week, do you want to upload whatever progress you made?

[jhylton]

Logged In: YES
user_id=31392

The URL of the day for Vladimir's explanation of how the
patch works is here:

http://mail.python.org/pipermail/python-dev/2000-July/007652.html

[smontanaro]

Logged In: YES
user_id=44345

Michael Hudson's no SET_LINENO patch seems to be nearing completion
& this one's been marked "out of date" with no assignee, so I'm closing it...

[smontanaro]

Logged In: YES
user_id=44345

Michael Hudson's no SET_LINENO patch seems to be nearing completion
& this one's been marked "out of date" with no assignee, so I'm closing it...