Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

!!! xs: failed to allocate 1024 bytes for slots !!! #239

Closed
wilberforce opened this issue Jul 30, 2019 · 5 comments
Closed

!!! xs: failed to allocate 1024 bytes for slots !!! #239

wilberforce opened this issue Jul 30, 2019 · 5 comments

Comments

@wilberforce
Copy link
Contributor

I'm unclear under creation: in the manifest on what setting to increase.

image

infact for this esp32 project - I'm note clear where the current settings are getting inherited from?

The slots are curently 18432.

in the clock example I see:

https://github.com/Moddable-OpenSource/moddable/blob/public/contributed/modClock/manifest.json#L13-L16

and here:
#193 (comment)

however I don't understand how this relates to slots

Thanks!

@wilberforce
Copy link
Contributor Author

Re-reading it looks like I need to increase static from 32k.

Will try tomorrow.

@phoddie
Copy link
Collaborator

phoddie commented Jul 30, 2019

The "creation" in the manifest is the total available to slots, chunks, and the stack. The stack is static but the division between slots and chunks is somewhat dynamic. Each slot is 16 bytes. A stack frame entry is a slot.

The ESP32 has tons of memory (at least relative to the ESP8266). You can easily bump to 64 KB or more (hard limit around 128 KB due to address banks on ESP32 hardware architecture). We keep the default small to keep ourselves working under a constraints to avoid getting sloppy.

@wilberforce
Copy link
Contributor Author

@phoddie
Thanks. Do you have some sort of rule of thumb that you apply for what a resonable amount of head space for % usage for slots, chunks, stack?

@phoddie
Copy link
Collaborator

phoddie commented Aug 13, 2019

There's no simple answer because projects are so different. That said...

If you are running for a while through all the usual operations of the project and the total of (slots peak) + (chunks peak) + (stack size) is within 2 KB of your static allocation, it is kind of tight. Neither the chunk heap nor the slot heap can fragment, so you never lose space to that.

Also, if the garbage collector is running often (dozens of times a second) that suggests allocating more memory for the virtual machine could improve performance -- though, again, it really depends on the project characteristics.

@wilberforce
Copy link
Contributor Author

@phoddie Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants