| | <<<Back 1 day (to 2020/03/21) | Fwd 1 day (to 2020/03/23)>>> | 20200322 |
| avih | ator: why is JS_STACKSIZE limit a thing? the stack can be realloced - js_Value doesn't care if it's moved - that's why js_dup works. probably the same for js_try limit and the environment stack as well. | 10:07.12 |
| | (not sure about regex limit, i guess it's mostly to avoid infinite recursion?) | 10:08.23 |
| | i'm guessing the limits are for simplicity of just one allocation, but the limit is checked anyway in all of those whenever it's touched, so i think this can be extended to do realloc if the limit is reached | 10:11.08 |
| | maybe the limits can be re-porposed to become minimum free slots when a js C function is called. this way you don't get a realloced anything during js c functions, and only the main run loop does the allocations | 10:13.07 |
| | (this does need careful analysis to ensure it's ok. for instance i believe the main run loop can be entered during e.g. js_tostring, and we don't want JS_TLITSTR value which was obtained previously at the C function to move) | 10:17.08 |
| | in fact, i think JS_TLITSTR is the only case which needs care. all the other values are either pointers to objects which won't move, or strings which won't change, or primitive values which don't reference external memory once obtained | 10:19.05 |
| ator | avih: 1) JS_TSHRSTR points to the stack; the only promise we make is that a js_tostring pointer will be live as long as the stack slot it came from is untouched | 19:48.21 |
| | 2) C functions can call JS functions that can call C functions | 19:48.33 |
| | these in combination prevent us from reallocating the JS value stack (C functions further up the call stack can hold pointers to values on the old stack) | 19:49.04 |
| avih | ator: right, i meant of course JS_TSHSTR and not literal. but that's the only kind of value which cannot move easily, right? (also, correct re c calls js calls c, hence my further notes about short string) | 19:51.40 |
| | <<<Back 1 day (to 2020/03/21) | Forward 1 day (to 2020/03/23)>>> | |
Log of #mupdf at irc.freenode.net.