JSV_LOCK_MAX too low?

I have an app that's been running fine on the Pico but now when running on ESP32 it immediately gives an assertion failure: ASSERT(jsvGetLocks(var) < 15) FAILED AT src/jsvar.c:632. As far as I know it doesn't have much recursion or deep call tree, but I am transpiling from Typescript so.....

I increased this to 31 and re-flashed and problem went away. Perhaps this is a more sensible default for this platform?

@Gordon, @Wilberforce should I log suggestions/requests like this in the Github issues (not sure what the process is for ESP32 specific suggestions/requests)?

This is bit odd as you would expect the interpreter code to be the same across the devices.

As far as raising issues @Gordon 's call - it is sometimes useful to discuss here and then raise an issue if requied

Which build did you use? I thought all the builds used RELEASE=1 which disabled those assertions. That's why you're not seeing it on other devices - there's no check on them.

If the ESP32 build has assertions still in that'd explain why someone was complaining about the execution speed - it'd probably bump it up by a factor of 2 removing them.

Also, can you provide a simple bit of code that shows this happening so I can see what's going on? Having >15 locks means you've got over 15 bits of code on the stack trying to access the same variable - which honestly seems a big much.

The locks are stored in an enum with a bunch of other stuff. Doubling the number uses another bit. Afaik there are only 2 bits left, which were slated to be used for const and enumerable - so if I can avoid increasing it I'd like to (plus on low memory builds those 2 bits are used for something else entirely).

Hi @Gordon I will investigate some more and try to nail it down. It's a bit hard because my app is getting more complex and it's transpiled from Typescript...

I just did a quick test setting the limit back to 15 and running make clean && BOARD=ESP32 RELEASE=1 make and first signs are good -- no assertion! I feel a bit of a fool now -- I will have to re-run my SPI performance test and see what difference it's made ;)

Ahh ok, this was with a build you made yourself?

It's not good news it's going over 15 locks, but usually by that point the var is also referenced by something else so even if the locks overflow it's not a big problem since the variable won't be garbage collected.

Yes I've been doing hacking around the SPI with DMA so have a custom build... Definitely feels a bit bleeding edge particularly on the ESP32, but having fun... Espruino is a great project - well done!