Completely disabling import optimization for a global variable?

[petrihakkinen]

Would it be possible to somehow completely disable the import optimization for a certain global variable? I'm trying to port an older game to run on Luau and I'm having troubles because the codebase heavily uses a few global variables which are very often read but only occasionally mutated.

Without getting too deep in the details, let's say there's a global table variable "level" which contains dynamic data for the current level in the game. If I register the variable in the mutable globals array in compile options, imports are correctly disabled for every access to the fields inside "level" as expected. However, reading the value of "level" still causes the compiler to emit GETIMPORT, so mutating the value of "level" does not work.

So ideally I'm looking for a way to still have the safe-env feature enabled but somehow disable the import optimization completely for "level" and all its fields. -O0 or turning off safe-env are not really great options in this case because of the major performance impact. Same for marking the entire global env as mutable (although I'm not sure if that's even possible).

Generally speaking it would be great to have more control over imports, but not sure how exactly...

[zeux]

Yeah generally speaking we expected mutableGlobals to be used for this use case. Is there a way that the host API can be changed so that instead of changing the level variable itself, it mutates its contents?

[zeux]

Oh, one other option I forgot is to make sure that the level variable is nil at the point when bytecode is loaded and imports are resolved.

We do something similar to this in Roblox, although we have nested global environments so that our main VM global table is "pure" and all code is loaded in the main thread, and the actual scripts run with a global table that defines some impure variables and uses __index to reference the main global table, although this has a cost and it might be easier for you to lua_setglobal level to nil before loading the code and restore it after.

Let me know if none of these two options work, as we can certainly rework how mutableGlobals affect compilation. There's a reason for the current logic where mutableGlobals only disable access to the global's fields, not reading of the global itself (has to do with Roblox API specifics), but I'm not sure how compelling this reason is so we can revisit.

[petrihakkinen]

Hmm, yeah, I'm kind of desperate here trying to optimize the project for a low-end device at the moment... and those import accesses show up at the top of the list in profiler. Clearing and reusing 'level' is in the realm of possibility, so is wrapping everything in a table called 'g' (and registering it as mutable global), but these require quite a big refactoring (+ there are other similar global variables).

Generally, I'm more worried about the rather large incompatibility with Lua -- it feels like Luau at the moment does not really have global variables, just global constants. So any reasonably sized Lua codebase can encounter similar difficulties when transitioning to Luau. In fact, this is not the only project where I have had to fight the import system...

I've been trying to think about ways to mitigate this problem. One way forward would indeed be to make it possible to register real mutable global variables to the compiler. A downside is that this probably would make the semantics harder to understand: in one hand we have mutable globals (i.e. tables in global env whose fields can be mutated), and in the other mutable global variables (i.e. fields in global env which can be mutated). We'd at least need to come up with better naming! Perhaps you have ideas how this would work in practice?

Another half-baked idea: right now we have a way to black-list certain global tables for importing. What if we could (additionally?) white-list imports? E.g. in my engine I have about 1300 global functions that the engine exposes. With some work I could register all these to the compiler (and hopefully the compiler would not do a linear scan over this long array). Any access to globals not on the white-list would disable the importing mechanism. This is somewhat half finished though at this point... For example, I also have a lot of global Lua functions and there could be a performance impact if these would not use imports. Also maintaining the list could be problematic.

Overall both these ideas, white and black listing globals feel somewhat messy... Registering variables either way increases friction, especially when live coding, which I do pretty much always. Globals are especially nice for quickly prototyping (and also for "library" functions), but not so if the host has to be restarted everytime a new global is introduced. With Lua/LuaJIT I didn't have to worry about these details and perf with LuaJIT was pretty great out of the box. But I completely understand why you have taken this approach, and why this is non-issue with tightly sandboxed Roblox environment.

Anyway, that's my current thoughts. Hopefully I don't sound too negative -- still loving Luau, just wish there was a way to have the cake and eat it too.

I'll get back to you about the floor division RFC later this week, probably tomorrow.

[davidgiven]

So any reasonably sized Lua codebase can encounter similar difficulties when transitioning to Luau. In fact, this is not the only project where I have had to fight the import system...

I've just run into precisely this; it was really surprising to me that adding declare someGlobal: any didn't allow assignment to the global. My use case is I have a big chunky program consisting of lots of files loaded into the same environment, so there are lots of cross dependencies and splitting it up to use require isn't really an option. So the code expects to do Something = {} in one file and reference Something.blah in another.

Would something similar to declare assignable Something be feasible? Or does the analyser need to know the set of assignable globals up front, before the analysis starts?

(I'll add that my program works, so whatever the compiler doing is fine. This is just an analysis problem. And probably a performance problem too, TBH.)

[petrihakkinen]

Here's an idea: replace mutableGlobals in compiler options with a callback that gets the three parts of an import as strings?

Make a global variable mutable:
if(strcmp(part1, "some_global") == 0) && !part2 && !part3 return true;

Make all fields (and all subfields) of a table mutable:
if(strcmp(part1, "my_table") == 0) return true;

Make a field in a table mutable:
if(strcmp(part1, "my_table") == 0 && strcmp(part2, "some_field") == 0) return true;

Make all global variables starting with a prefix mutable:
if(startsWith(part1, "some_prefix_")) return true;

etc.

[davidgiven]

I'd prefer to declare them in the typedefs file (or even inline). Syntax like:

declare something?: Something
declare function something?: () -> Something

...should work, as I think adding the extra question mark makes it unambiguous.

The question is whether the mutable globals array can be changed during typedef read.

[davidgiven]

Actually, having had a look through the code, there appear to be two distinct problems here:

• allowing writable globals between modules; this is what the mutableGlobals compiler option controls, right? @petrihakkinen I'm guessing that this is the problem that's affecting you?
• telling the typechecker that specific globals are writable; this is the problem that's affecting me. My entire program is treated as a single module, so all my globals are in the per-module shadow globals table. This makes writes invisibly work without affecting all the other (non-existent) modules. This also explains why my program works fine even though the type checker flags all the global references as invalid.

So adding declare something? syntax would fix the typechecker and help me, but it wouldn't help you. Although, I still don't understand why you're having trouble writing to your level variable. Wouldn't the assignment end up in the shadow globals table?

[petrihakkinen]

• allowing writable globals between modules; this is what the mutableGlobals compiler option controls, right?

Not quite. mutableGlobals as it is now only makes the fields of a global table whose name is registered in mutableGlobals mutable. So for example, if mutableGlobals contains "foo", any access to foo.* will be considered mutable. But the value of the variable "foo" itself is treated as constant so you can't point "foo" to some other table (or set foo to nil, or whatever).

Although, I still don't understand why you're having trouble writing to your level variable.

Because "level" is considered an import and therefore its value is cached in the constant table of a loaded script and can't change.

btw. I came up with another use case for the mutable callback API that I suggested..
turn off all imports (for example when performance is not critical and you just want to get some old project working):
return false;

[petrihakkinen]

@davidgiven are you sure your code actually uses the fast paths in the VM (imports, fastcalls, safe-envs etc.)? In my projects where I share a single environment for all scripts, I have to patch the imports after loading the scripts (using some custom code that scans the bytecode and traverses the Lua heap). Since scripts are loaded one by one and imports are cached into the constant table for each function proto at load time, any globals whose values have not been set yet do not end up in the constant table. Therefore the VM takes slow path in GETIMPORT opcode and has to look up values for those imports dynamically.

[davidgiven]

@petrihakkinen From what I've found out from this thread, I'm pretty sure it's doing everything the slow way. But I'm not importing anything other than the system libraries and host-provided user functions, so I don't think there is a fast way for me anyway. Performance isn't critical for me as my program's a word processor so I'm not going to worry about it. I would like to use the type checker, though.

[davidgiven]

...aaaand I've found out what's upsetting the typechecker. It's code like this:

--!nonstrict
function foo()
	print(A)
end
function bar()
	A={}
end

It sees the reference to A, but it doesn't see the definition of A. Which is weird, but it's also completely unrelated to this particular discussion. So I don't have any business here! Apart from learning things, so thanks...