On singleplayer, both the render thread and the server thread report to the same maps in the profiler, they're separated afterwards.

This I believe means that if when the report is finishing and being printed by the server thread the render thread tries to register a ProfilerToken, then there's a chance of the game crashing, and with no useful exception given fastutil doesn't do checks for concurrent modification in order to be fast.

This is likely the cause for #1305 and a few similar crashes reported on discord, and why it only happens rarely.

Consistently getting around 100 calls from render thread vs 82800 from server thread in a randomly created world (jungle).

Calls from the render thread are only made to end_current_section. Nvm I may have to test entity profiling for these to show up.

Consistently all tokens I can find in end_current_section are block entities.

On entity profiler, basically everything is getting in from the render thread. Almost 50-50 split.

This'd either need removing the "client" part of the profiler (which I'd do tbh, there's already the fancy graph for what's taking time afaik just for render thread), maintaining thread-safe collections in the profiler (slow), stopping on a volatile (very slow iinw) or maintaining different collections for render vs server thread (but we still have the issue that the render thread may add to them while server is preparing results, where we crash).