Comments (12)
Memory leak also happens on:
- Zulu 11.31.11
- AdoptOpenJDK 12 with HotSpot (JRE)
from canvas.
Thank you for the confirmation. I'm focused on a different (not yet released) mod currently, but will get back to working on Canvas "soon."
from canvas.
AdoptOpenJDK 12 with HotSpot is working great on OSX. Guessing it is OS-specific.
I will try putting some additional config options to at least allow for debugging, maybe more conservative memory allocation. A rewrite of buffering altogether is what I need to do but that will take longer than I have until work on Exotic Matter and fluid API get to a stopping point.
from canvas.
It does do extra work now on chunk reload to ensure that all buffers are deallocated. When an early reload happens that way there can easily be a couple thousand buffers awaiting access to the main thread for upload, especially on a fast machine. Now it should block until they are all released
from canvas.
Thank you for the excellent report.
Best guess is that it is caused by some incompatibility with LWJGL's MemoryUtil allocation routines, which default to using Unsafe if available, then reflection if not.
There is/was such a bug with OpenJDK 9 which, as you point out, is not the same as OpenJ9. But that does illustrate that such bugs are possible.
The biggest consumer in Canvas will be chunk buffer uploads, for which Canvas uses MemoryUtil.memAlloc()
and MemoryUtil.memFree()
. It appears likely the calls could be made on different threads but they should be properly matched 1:1.
The only other use of memAlloc/memFree
is for light map texture initialization, but it 1X and likely not the culprit.
To reproduce this in isolation a simple test app that allocates and deallocates on multiple threads with a variety of buffer sizes might do the job. I will eventually get around to doing that myself but if you want to have a go at it that would be great.
As for how to fix, I will probably be replacing those buffers with a pool of fixed-sized buffers for reuse, which may help, or perhaps LWJGL offers a different allocation routine that is more compatible (though perhaps less performant.) I have not done that research yet.
If the issue turns out to be allocate/release on different threads, I should be able to force both onto the client thread if necessary.
from canvas.
Also - a faster if less exact way to confirm the problem is the chunk buffer allocation: just open a world and load a bunch of render chunks, either via F3+A or moving across terrain. If the leak is worse when you do that, it is almost certainly a problem with the MemoryUtil routines.
from canvas.
The memory leak is still present with AdoptOpenJDK's JDK12-OpenJ9 build and worsens as I move across terrain I did not previously visit.
Sorry if my comment did not answer anything
from canvas.
That does help some. I need to confirm it doesn’t happen on other JVMs and then I can try a different allocation approach.
from canvas.
So I just tested spamming F3+A in a superflat world and I can confirm that with Canvas the RAM usage seems to go up over time (and especially buff/cache
).
So it indeed does seem like some of the allocations are not getting freed.
Both instances (with and without Canvas) started off at about ~850-900MB of RAM, the one without Canvas stayed at that value most of the time while the one with Canvas shot up to 1800MB fairly quickly.
The 'memory allocated' metric in the F3 debug screen stayed the same, along with the reported memory use. (Which I guess confirms the issue is with the MemoryUtil
allocations.)
from canvas.
@grondag any updates on this?
Currently looking into https://github.com/LWJGL/lwjgl3-wiki/wiki/2.5.-Troubleshooting#memory-allocator-debug-mode, could yield some more information
from canvas.
Should hopefully be better in build 354, available now on Curse: https://www.curseforge.com/minecraft/mc-mods/canvas-renderer/files/2756313
I found some scenarios where it may not have been properly deallocating. If that doesn't fix the problem, try enabling "safe memory allocation" on the debug config tab. That will use NIO buffers which are much slower but they automatically deallocated via JVM garbage collection.
Please let me know if the problem persists.
from canvas.
Just tested the new version and it's better! Memory usage still goes up over time though, albeit much slower than before.
With NIO buffers, the memory usage is still a bit higher but doesn't seem to go up as much.
One thing I did notice when spamming F3+A in rapid succession (rather fast), was that with Canvas the CPU usage goes up and FPS drops to ~19FPS, while without Canvas reloading chunks at that speed yields no FPS drop.
This happens both with default and NIO buffers. I don't recall this happening with previous versions, but I could be wrong and might test that out later.
from canvas.
Related Issues (20)
- Canvas ignores RenderSystem.runAsFancy()
- Canvas breaks Fabric dimensional renders
- Canvas crashes upon enabling Faithful 32x HOT 2
- Canvas causes graphics options can not to be set, causing compatibility issues HOT 6
- Unable to render some blocks/machine parts from Create HOT 1
- Mod is Incompatible with Chisels n Bits libarary mod Saecularia Caudices HOT 2
- .
- No entity shadows on 1.19.3 branch for all shadow pipelines HOT 2
- EXCEPTION_ACCESS_VIOLATION when reloading resource packs HOT 5
- Incompatible with Player Animator and Better Combat: Invisible hands in first person when animation uses third-person model
- Physics Mod doesn't show ragdolls or break particles. HOT 1
- [1.19.4] Light flicker at the start of world loading HOT 1
- [1.20-pre2] Boat rendering is broken again? HOT 3
- Crash at startup when using with Custom Machinery HOT 6
- Sign writing menu not correctly rendered
- Chunks not rendering in a perimeter around player on servers HOT 1
- Chunk pale rendering error
- Incompatible with Valkyrien Skies 2
- (1.20) Incompatible with any mod modifying MixinItemRenderer HOT 1
- Chunk grid moving as player camera moves.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from canvas.