Re: _ENV related optimizations (Was: Make the VM Lua-version-agnostic and modularize)
- From: "Vyacheslav Egorov" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "vegorov" for DMARC)
- To: luajit@xxxxxxxxxxxxx
- Date: Thu, 24 Sep 2015 19:56:06 +0200
Overengineering.
Yes. If you read the previous mail - then you probably know that I
don't think it's necessary to optimize this.
// Vyacheslav Egorov
On Thu, Sep 24, 2015 at 7:53 PM, Soni L. <fakedme+lj@xxxxxxxxx> wrote:
On 24/09/15 02:45 PM, Vyacheslav Egorov (Redacted sender vegorov for DMARC)
wrote:
You'd need to keep to extra tracking data to know which upvalue (if
any) was _ENV
Well, you know which upvalue was _ENV. It's one called _ENV :)
You'll need to add a bytecode[1] or extend existing function header
bytecodes to load GCupval by index into one of the registers (e.g. R0)
as opposed to loading value from GCupval by index.
Global's accessing bytecodes GGET, GSET would be re-purposed to load
from a table contained in GCupval in R0.
Overengineering.
We already have _ENV.
(the particularly nasty case is using debug.upvaluejoin to change the
GCupval* which is in the GCfunc, the slightly less nasty case is using
debug.setupvalue to change the TValue within the GCupval).
Oh. I did not know such pile of evilness even exists - did not look at
5.2 debug APIs in a while.
I can't immediately come up with a reasonable way to cache GCupval in
the interpreter in the presence of debug.upvaluejoin. (short of
reloading it after calls - which is not reasonable). Hmm[2].
debug.setupvalue is not a problem - because we don't cache the value
itself. It's no different from a normal assignment _ENV = value for
our purposes.
[1] Ok, I know I criticized bytecode wasting before
[2] Anyway, I still think it's more of a fun mental exercise than an
actual problem.
// Vyacheslav Egorov
On Thu, Sep 24, 2015 at 7:26 PM, Peter Cawley <corsix@xxxxxxxxxx> wrote:
On Thu, Sep 24, 2015 at 6:10 PM, Vyacheslav Egorov
<dmarc-noreply@xxxxxxxxxxxxx> wrote:
In interpreter for functions that don't redefine _ENV you can just
cache an GCupval object for _ENV upvalue on entry to the function -
removing the indirection.
Though I doubt this is the problem worth thinking much about.
You'd need to keep to extra tracking data to know which upvalue (if
any) was _ENV, and you'd need to be careful about the debug library
(the particularly nasty case is using debug.upvaluejoin to change the
GCupval* which is in the GCfunc, the slightly less nasty case is using
debug.setupvalue to change the TValue within the GCupval).
Other related posts:
