Author Topic: Replacing a texture leads to (Native memory leak)  (Read 2601 times)

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: Replacing a texture leads to (Native memory leak)
« Reply #15 on: February 09, 2015, 12:37:15 pm »
I don't think that it's related to BufferedImages. Are these handles lost forever or will they be reclaimed when garbage collection kicks in? Apart from that, i've identified the problem that causes the re-upload of actually unloaded textures. It's related to the double buffering of rendering commands that the AWTGLRenderer does. I'll try to find a fix for it this evening. Maybe that fixes the handle problem as well.

Offline Mr_Chaos

  • int
  • **
  • Posts: 55
    • View Profile
Re: Replacing a texture leads to (Native memory leak)
« Reply #16 on: February 09, 2015, 01:41:08 pm »
They are lost forever, never reclaimed.

When my program reached about 2500 handles it's using > 5GB native memory

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: Replacing a texture leads to (Native memory leak)
« Reply #17 on: February 09, 2015, 07:27:42 pm »
What puzzles me is that it actually uses native memory. If it's really a texture-remains-on-the-gpu-problem, i would expect it to eat up the gpu memory and not the main memory and you won't see any OS memory handles for that (maybe unless it's some onboard chipset...). And if it just keeps the reference to the Texture instance, it would consume VM memory, not native memory. The only native memory that's being used when dealing with textures is the memory that's used to upload them...and that's only a temp buffer, it's not persistent. And even if it were, i would expect it to be counted as VM memory as well because it's reserved by it.

Anyway, i've uploaded a new jar: http://jpct.de/download/beta/jpct.jar. This one fixes two potential problems:

  • Textures get unloaded that have never been unloaded. In former versions, such textures would have remained in the unload queue forever, because you can't be sure that it won't be uploaded in the next frame. In this version, these references will be removed after a short timeout.
  • Textures that are still present in one of the AWTGLRenderer's buffers. In former versions, these would have been unloaded->uploaded->forgotten on the gpu. Now, the unloading will be delayed until they are no further references to them in the buffers.

Both operations will be logged in debug mode if they happen.

I'm not sure if this helps in your case, but it's worth a try. If it doesn't help: Have you tried not to use BufferedImage? Just to be sure...
« Last Edit: February 11, 2015, 12:39:02 pm by EgonOlsen »

Offline Mr_Chaos

  • int
  • **
  • Posts: 55
    • View Profile
Re: Replacing a texture leads to (Native memory leak)
« Reply #18 on: February 09, 2015, 07:49:55 pm »
It works now, handle count is completely stable and the same is my Memory usage

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: Replacing a texture leads to (Native memory leak)
« Reply #19 on: February 09, 2015, 09:46:11 pm »
Cool! I'm glad we found it. I still don't get why it consumed native memory instead of GPU memory, but anyway...