Issue868514

Following the advice of Samuele Pedroni (message to 
python-dev of 2002-10-17 -- a while ago), reworked the way 
yields and f_lasti are implemented to work with finally 
blocks.  Then spent a while arguing with the verifier.

The second file is some test cases I found useful; 
test_generators in the CPython standard lib doesn't exercise 
yields in finallys all that much.

Logged In: YES 
user_id=61408

oops, I didn't notice this patch [SF btw sofar didn't sent
any notification mail about these patches, strange.]

this is very good, but as I have written commenting another
patch sun switched away from jsr. At some point it would be
good to do the same. Not that this mean that this will not
go in , pending review.

There is a lesson still, it is a good idea before writing
any patch that is not trivial to ping jython-dev. I knew
since some time about sun change of strategy.

Thanks for the work.

Logged In: YES 
user_id=920303

True, but I don't regret the learning experience.  As I said
on the other patch, I think that inlining finallys won't be
so bad, especially with generators, so long as there aren't
too many exits from the try block and the finallys aren't
nested.

Logged In: NO 

ah, well it seems that sun cannot make up its mind

http://developer.java.sun.com/developer/bugParade/bugs/4739388.html

they have added a flag to get jsrs back.

pro to no jsrs:
- it simplifies the compiler code
- verification of jsr is one of the most delicate part of
bytecode
verif.
- speed, although reentering a generator in a finally clause
and yield in finally clauses are rather untypical

contra:
- code could blow up, deeply nested try-finally are not that
typical in Python but we emit more bytecode per line of code,
and if PEP 310 is accepted nesting try-finally will be even
easier, more common?

Having some measure about what kind of code lengths we could
get both ways would be good.

Logged In: YES 
user_id=61408

oops, forgot to login, that was me

Logged In: YES 
user_id=920303

Attached a patch that inlines the finally blocks.

It turns out that some of the verifier problems I was having
with try:finally: happen to try:except: as well (nothing to
do with jsrs -- just that the restoreLocals code shouldn't
really be in any exception ranges).  This patch, thus,
covers more cases than the previous one, because it handles
try:except: as well.

Added a test in test_jy_generators that tests a failing
try:except: case.

I'm looking into what this does to code size; more later.

Logged In: YES 
user_id=920303

The python std. library dir *.class gives

  3678583 bytes before

and

  3681995 bytes after inlining finallys

I'm guessing that nested finallys aren't all that common.

I'm sure you could easily contrive an example that blows up;
but I don't think that kind of thing is all that common. 
All in all, I'm happier with the newer patch, especially
some regularization of how it treats try:except: and
try:finally:; although the techniques of the two patches
could be merged somewhat.

Logged In: YES 
user_id=920303

Hmm... thinking about PEP 310.  In practice, it seems to me that it 
would reduce the size of the finally blocks, rather than increase it; 
and you can't nest finallys in the finally part of it -- inlining seems 
like an even bigger win there.

Logged In: YES 
user_id=61408

I'm sorry, I still haven't looked at this, but I'm looking
forward to it.
I want to make some more progress on the newstyle front before.

Thanks.

Logged In: YES 
user_id=61408

patch6inline is the relevant one to be processed for being
applied.

Logged In: YES 
user_id=193969

Will look at testing and applying this.

Logged In: YES 
user_id=193969

applied