[Mesa-dev] [Bug 98831] Constantly increasing memory consumption in JavaFX applications

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98831

--- Comment #5 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to Itai from comment #3)
> The problem disappears completely when using SW rendering in Java
> (-Dprism.order=sw), which as far as I understand surpasses Mesa, but I'm not
> sure. 

It's not using Mesa's SW rendering?


> I don't know if it is of any help, but the last lines are attached here: 
> 
> ==18204== 16,793,616 bytes in 1 blocks are possibly lost in loss record
> 6,235 of 6,237
> ==18204==    at 0x4C2BBCF: malloc (vg_replace_malloc.c:299)
> ==18204==    by 0x2A344779: _swrast_CreateContext (s_context.c:775)

This is a single-time alloc done when application asks for compatibility
profile instead of the core profile (like modern GL apps do).  It's not the
problem.

Could you try Valgrind Massif instead?


(In reply to Itai from comment #4)
> Replaying with Apitrace does not exhibit the problem.

This means that either:
- the leak is on JavaFX side, or
- Apitrace trace/replay changes something in the JavaFX GL calls (e.g. context
setup or how multiple contexts are handled)


> Additionally, it seems
> to perform altogether much better, hardly taxing my CPU, while the original
> seems to constantly use up a whole core (~24% CPU usage).  

Java + leaking being slower could be due to swapping, if you don't have enough
RAM for the resulting app memory usage.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161123/ac69ac99/attachment.html>