Increase Limits For Global Inits

ID:2907671
 
Jan 10 2024, 5:54 pm
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
I've started to hit some kind of a limit on the number of globally initialized things like lists and images. Might have something to do with having a lot of global lists, but I'm not sure.

var/TEST_LIST[][] = new/list(12, 12)
error: new: Procedure is too large; break it into multiple sub-procedures

var/image/TEST_IMAGE = new/image('icons/test.dmi',"test")
error: new: Procedure is too large; break it into multiple sub-procedures

It would be nice to have this limit increased or applied only to procedures like it implies.
Jan 11 2024, 1:37 am (Edited on Jan 11 2024, 2:25 am)
After doing some testing of this myself. I believe that this is a bug.

This error isn't caused by the total amount of global inits, rather the total size of all their arguments.

The following is speculation on my part, but it seems that Dream maker keeps track of the total memory size of an init proc's arguments, and throws an error if the size is too large. However, this size tracker seems to never decrease, leading to a large amount of global inits to trigger the mentioned error.

Even if the above is 100% incorrect, it seems that the more complex any global init's arguments are, the sooner the error is triggered.

Below is the code I used to test this. Steps for using:
1. Paste it into a new project.
2. Compile.
3. Run the project.
4. Run each of the verbs once.
5. Close dream seeker.
6. Refresh the file list of the project.
7. Include & compile the first file.
8. Un-include the file last included, and then repeat step seven with the next file.

While I used lists in my example, this is reproducible with:
datums, images & any proc called to initialize a global var.

//no error
/client/verb/gen_list_no_vars()
    for(var/list_num in 1 to 5041)
        var/str = "var/list/LIST[list_num]= new/list()"
        text2file(str,"list_no_vars.dm")
    usr << "DONE!"

//no error
/client/verb/gen_list_one_num()
    for(var/list_num in 1 to 5041)
        var/str = "var/list/LIST[list_num]= new/list([rand(1,99)])"
        text2file(str,"list_one_num.dm")
    usr << "DONE!"

//error on line 5041
/client/verb/gen_list_one_string()
    for(var/list_num in 1 to 5041)
        var/str = "var/list/LIST[list_num]= new/list(\"test!\")"
        text2file(str,"list_one_string.dm")
    usr << "DONE!"

//error on line 4396
/client/verb/gen_list_two_vars()
    for(var/list_num in 1 to 5041)
        var/str = "var/list/LIST[list_num]= new/list([rand(1,99)],\"test\")"
        text2file(str,"list_two_vars.dm")
    usr << "DONE!"<dm>
Jan 15 2024, 12:09 am
This isn't a bug, but rather a limitation in the current setup. Procs are still currently limited to 64K instruction codes, which is more than enough for most of them, but there's a world init proc for global vars. It sounds like you have a lot of global vars being initialized in world.init. This is ultimately leading to a large number of instruction codes which is overflowing the limit.

So really the issue is not about increasing global lists but potential proc size. A number of changes in the language probably make this feasible, but I have to review what's still in place as far as code that assumes a 2-byte instruction pointer or how ID arrays get compiled into the .dmb.