Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove 1.8 evalScope from 9k #2300

Closed
nirvdrum opened this issue Dec 10, 2014 · 4 comments
Closed

Remove 1.8 evalScope from 9k #2300

nirvdrum opened this issue Dec 10, 2014 · 4 comments

Comments

@nirvdrum
Copy link
Contributor

@nirvdrum nirvdrum commented Dec 10, 2014

Ruby 1.8 had some weird behavior around two disjoint evals sharing the same binding if in the same lexical scope. While most of 1.8 has been excised from 9k, some vestiges from this old behavior still exist and should be removed.

@nirvdrum nirvdrum added this to the JRuby 9.0.0.0 milestone Dec 10, 2014
@nirvdrum nirvdrum removed this from the JRuby 9.0.0.0 milestone Dec 10, 2014
@headius headius added this to the JRuby 9.0.0.0 milestone Dec 10, 2014
@headius
Copy link
Member

@headius headius commented Dec 12, 2014

I started exploring this, and found that we're still using this logic (incorrectly) to produce a DynamicScope for parsing evals in a given context. It's incorrect because when we actually run the evals, they get their own DynamicScope instances. The reuse of a single scope for all evals in a context causes their local variables to be offset as if they could all see each others' definitions. This causes eval dynscopes to be larger than necessary (and may represent a leak if you are evaluating many different local variable names in a single scope).

I'm looking at removing the logic you mention and fixing this issue now.

@enebo
Copy link
Member

@enebo enebo commented Dec 12, 2014

I have figured out the mystery of the index growing. IREvalScript will ask for variables from a special variable stash in the nearest non-eval IRScope. In essence, IR solves the variable sharing its own way. Tantalizingly just deleting this code and running things makes several evals work as expected but there is still something I have wrong.

The plus side is IR Eval can get much simpler. IR was started at a point when we still had to support lvars being captured across evals. Now that this is gone most of the craziness of evals in IR will go away. I will maybe get @subbuss to help me now that he is back home :)

@subbuss
Copy link
Contributor

@subbuss subbuss commented Dec 12, 2014

Given that I got home 30 mins back .. maybe over the weekend :)

@enebo enebo reopened this Dec 15, 2014
@enebo enebo added this to the JRuby 9.0.0.0-pre1 milestone Dec 16, 2014
@enebo enebo removed this from the JRuby 9.0.0.0 milestone Dec 16, 2014
@enebo
Copy link
Member

@enebo enebo commented Dec 23, 2014

I am calling this as done for now. Behavior of binding is still a little weird but only because we clone bindings because we modify the binding during evals (and we have done this for a long time). We should untangle this once and for all but it will be done later when we tackle block/eval call protocol in IR.

@enebo enebo closed this Dec 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants