some test about gamecache (discussion)

[shuen4]

d24e65e

test trigger: global variable integer udg_test = 0 on event do:

set udg_test  = udg_test + 1
call BJDebugMsg(I2S(udg_test))
// reloaded code was above 2 code copied 999 times (total 1000)

test result on 1.26a: Jass VM reach op limit while processing 46th (running trigger once increase udg_test by 1 (98 times) + reach op limit) if disable Jass VM op limit: no more free instances runtime/instruction.j while processing 267th (running trigger once increase udg_test by 1 (910 times))

test conclusion: using gamecache instead of GetPlayerTechMaxAllowed and GetPlayerName() - works no longer a problem to load big-sized bytecode file however there is another problem: Jass VM op limit and instances

debug info:

---------------------------------------
               Jass error
---------------------------------------
op code limit exceeded

stack traceback:
    [JHCR_Parser_parse_ins:246]
    [JHCR_Parser_parse_and_init:20]
    [JHCR_Init_parseTEST:83]
    [JHCR_Init_parse:2]
---------------------------------------

---------------------------------------
               Jass error
---------------------------------------
op code limit exceeded

stack traceback:
    [JHCR_Interpreter_step:30522]
    [JHCR_Interpreter_start_interpreter_wrap:72]
---------------------------------------

JHCR.txt

[lep]

Very interesting. Using a gamecache could eliminiate the need for the old-patch flag alltogether. I never intended this to be used to (re)load huge chunks so i never tested how many changes you can realistically do and by consequence i only added so many ability ids to suit my needs (or needs reported to me). In the same vain i never cared too much about freeing old instances because if you run into that error you can simply restart your map; and i personally also never ran into this problem myself. If you think allocation failures are a bigger problem than i think they are feel free to post your arguments and we can think about doing proper free-ing.

But back to the topic at hand: i think i will do a PR using only GC with all the old-patch stuff removed etc. and you can have a look at it aswell.

[shuen4]

from what i see it seem that interpreter_step used instruction's instance arent free-ing instruction's instance will make interpreter_step to fail?

i personally would like to solve the allocation failures so i can keep editing and reload for a long time (let say 6 hour or longer without restart the map)

was thinking about to not free-ing instruction's instance but change all script to use hashtable instead of array because the allocation failures might still exist in other function

[lep]

I like your goals. I will have to take a deeper look at the memory management.