I've closed every window in NB until the problem disappeared and the
huge resource claim is caused by any of the treebased windows.
The project group contains 43 POMs. Smaller project groups, cause much
less resource claims.
Other L&F like FlatLaf don't have this issue at all.
I've looked
Oh, NetBeans is the java-lang-Thread.
It was taken on Ubuntu 23.04, on AMD GPU, using Wayland, and Java 17 as
runtime.
On 9/5/23 16:40, Laszlo Kishalmi wrote:
Just adding my data to here:
xrestop - Display: localhost
Monitoring 20 clients. XErrors: 0
Pixmaps: 145296K tot
Just adding my data to here:
xrestop - Display: localhost
Monitoring 20 clients. XErrors: 0
Pixmaps: 145296K total, Other: 40K total, All: 145337K
total
res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
160 44 7 1 13 87 40
A JFrame with a button on it creates 18 X11 graphics contexts according
to xrestop. (tested on JDK 21 build34)
Resizing it or pressing the button will very quickly produce more and
will overtake the NetBeans instance which I have running in the
background within a few seconds.
After reading
i've written in a previous email 9/5/23 23:50, how to reproduce in
netbeans, but i think you are looking for specifics of my X11
environment i guess?
Gr. Simon
On 9/5/23 23:39, Tamás Cservenák wrote:
Am using (somewhat limited, but still) Netbeans on Linux + Wayland (Intel
XE graphics), no
I'm unable to run with glx extensions. There i run so fast out of memory
that my whole X11 crashes (in about 6 hours or so).
See:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7626
Gr. Simon
On 9/5/23 23:39, Tamás Cservenák wrote:
Am using (somewhat limited, but still) Netbeans on Linux
xrestop - Display: localhost
Monitoring 47 clients. XErrors: 0
Pixmaps: 1407157K total, Other: 491K total, All: 1407648K
total
res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID
Identifier
180 930 27 84 594329K 2K 594332K 4070
On 05.09.23 23:29, Simon IJskes - QCG wrote:
If i disable the memory graph, the resource claim growth is
immediately reduced.
The GC i was talking about, are X11 Graphic Contexts.
ah I see :) I actually almost asked what you meant by "GC" since the
numbers didn't make sense to me, but since
Am using (somewhat limited, but still) Netbeans on Linux + Wayland (Intel
XE graphics), no problems so far. This is on laptops with Intel XE. My
desktop has an NVidia GeForce GFX so I use X11 as Wayland on nVidia is meh.
So, I can run NB on Wayland and X11. Linux on both are Fedora 38...
Can you g
If i disable the memory graph, the resource claim growth is immediately
reduced.
The GC i was talking about, are X11 Graphic Contexts.
Gr. Simon
On 9/5/23 23:16, Michael Bien wrote:
hi Simon,
On 04.09.23 11:00, Simon IJskes - QCG wrote:
It does take long before netbeans to rise to the top,
hi Simon,
On 04.09.23 11:00, Simon IJskes - QCG wrote:
It does take long before netbeans to rise to the top, and some time
later rendering artifacts start to occur. These are solved (so it
looks) by clicking on the graph forcing GC.
This would indicate that UI resources are freed during obj
Hi,
Please specify steps to reproduce this. "Large heap" is subjective.
"When looking at xrestop you can see 'it' growing every second" is also
ambiguous: what's exactly growing every second?
I installed xrestop and switched to the Metal Look and Feel, and the
xrestop line remains unchanged
I cant be absolute, but the majority of the graphic contexts is returned
with a garbage collection.
The problem is, with a large heap, the X11 server resources are
exhausted (so it seems) before a garbage collection occurs automatically.
Also the Xserver memory consumption can easily go over
It would be good if someone could try and reproduce this (I don't use
netbeans on Linux) but it seems like it might not be Netbeans to
blame? Also can you just clarify - are these X resources returned
after a GC or is there some amount which is permanently leaked?
On Mon, 4 Sept 2023 at 12:40, Sim
The rate of GC increments depends on if the performance toolbar is the
last in the toolbars, when i add a custom toolbar at the end, it is down
to 3 per second. When not about 30+ per second.
Using Metal Laf.
Gr Simon
On 9/4/23 13:19, Simon IJskes - QCG wrote:
Thanks,
had a look as well, a
Thanks,
had a look as well, and nothing looks like a forgotten dispose, in that
component.
I'm starting to think it is a broader problem. Maybe more a LAF thing,
if i 'hide' the window (i dont know the proper term, the display manager
shows a button with windowtitle in [] in the panel), th
On Mon, 4 Sept 2023 at 10:01, Simon IJskes - QCG wrote:
> The memory graph in the performance toolbar claims a huge amount of X11
> resources.
>
> To give an idea, it creates 30 X11 graphics contexts per second.
For information - this is implemented in
https://github.com/apache/netbeans/blob/0322
On 9/4/23 11:00, Simon IJskes - QCG wrote:
The memory graph in the performance toolbar claims a huge amount of X11
resources.
Some platform details:
Netbeans 18,
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM
Hi,
The memory graph in the performance toolbar claims a huge amount of X11
resources.
When looking at xrestop you can see it growing every second.
It will clear with a GC, but if you give netbeans a huge java heap, this
GC is delayed. And the claim on X11 resources grows. It does take long
19 matches
Mail list logo