5

I am developing java swing application on Windows 8.1 64bit with 4GB RAM with JDK version 8u20 64bit.

The problem is when I launched the application with Netbeans profiler with Monitor option.

When the first Jframe is loaded the application Memory Heap is around 18mb and the JVM process size around 50mb (image1).

Then when I launch the other Jframe which contains a JFxPanel with webView the Heap jumps to 45mb and the JVM proccess jumps to 700mb very fast (image2) which is very confusing. Then when I close the second JFrame and it get disposed and a System.gc() is called and the JVM perform a GC (in most times) the heap drops to around 20mb but the JVM proccess never drops (image3).

Why there is a huge difference between memory Heap (45 Mb) and JVM proccess (699 Mb)? Why the JVM needs all that Memory? And how to reduce that amount? And I am launching the app with those vm options: 

-Xms10m  -Xmx60m -Xss192k
-XX:+UseG1GC -XX:MinHeapFreeRatio=5
-XX:MaxHeapFreeRatio=10  -XX:PermSize=20m
-XX:MaxPermSize=32m

EDIT :- I just read the question in that link JVM memory usage out of control and he have the same problem but the situation is different his heap size is arround 33% of the total JVM process memory size which is in my case less than 7% and he is doing multiple jobs simultaneously (Tomcat webapp) which I don't (java swing application) and he didn't launch his application with the same VM arguments I did.

UPDATE :- after the first JFrame is launched (image1)

First JFrame launched

after the second JFrame is launched (image2)

Second JFrame launch

after the second JFrame is closed (image3)

Second JFrame closed

EDIT 2 :- I just tried the same application with the same VM arguments above and added 

-client 
-XX:+UseCompressedOops

and used JDK 8u25 32-bit because as mentioned in this answer https://stackoverflow.com/a/15471505/4231826 the 64-bit version doesn't include client folder in the JRE and will ignore -client argument.

The result is that the total memory process jumped to 540Mb when the second JFrame was open and the heap sizes (in the the three points) were almost the same numbers as in the 64-bit version, Does this confirm that this is a problem related to the JVM (The same heap sizes and a 260Mb difference in total process sizes)?

Community
  • 1
  • 1
Waxren
  • 2,002
  • 4
  • 30
  • 43
  • Although you may not have the identical problem, the answers and comments on that question still apply to your problem. If no you need to bring in a lot more detail to have this question reopened as a non-duplicate question. – Mark Rotteveel Dec 12 '14 at 07:49
  • No the solution to his problem was to STOP simultaneous jobs and run each one individually which is a problem realted to his code, but I reviwed my code and It's just a swing application with two Jframes and it's seems a problem related to the JVM unless there is something I'm missing. – Waxren Dec 12 '14 at 07:57
  • The accepted answer explains IMHO clearly why memory usage is larger than just the heap size. Think of things like a lot of threads or other native stuff, swing probably requires some native stuff as well, etc). – Mark Rotteveel Dec 12 '14 at 08:03
  • Thanks for the reply, you are right about that, the total memory usage of the JVM process will be more than the heap size but as mentioned in this article https://plumbr.eu/blog/why-does-my-java-process-consume-more-memory-than-xmx the total process memory should be : Max memory = [-Xmx] + [-XX:MaxPermSize] + number_of_threads * [-Xss] = 60Mb + 32Mb + 20*192K = 95.75Mb as you notice in my case the difference is HUGE – Waxren Dec 12 '14 at 08:45
  • I agree it is extreme, but I am not sure if it is simple (or on topic) to troubleshoot that through SO. However you might want to consider rewriting your question with more details, focusing more on identifying exactly what is consuming the memory, then on the why. – Mark Rotteveel Dec 12 '14 at 09:17
  • I will update the question with Image from Netbeans Profiler and more details. – Waxren Dec 12 '14 at 09:41
  • First of all, HotSpot 8 has the Metaspace which is non-heap. All the class metadata/code/compiled code is there. The usage won't go down once you have used some classes for the first time (this seems to be the case you are describing). Second, how can you be sure that the JVM is really *using* all that memory? Allocating blocks in the virtual memory space is very different from actually using it. It may have no measurable impact on your system. – Marko Topolnik Dec 12 '14 at 20:33
  • @MarkoTopolnik Thanks for the reply, you are right but as far as I know the heap should be the biggest part of the process size not 7%, it is obvious that the JVM is allocating memory more and more that will never be used by the application,and I know that the JVM isn't using all that memory,but for the END USER it's using that memory. – Waxren Dec 13 '14 at 06:26
  • I don't see the point with the END USER. I would think that the end user only cares about the responsiveness/performance of their system, and would never even find out about such a low-level detail as virtual address space allocation. – Marko Topolnik Dec 13 '14 at 07:48
  • I meant that the END USER will see that the application already taking 699MB in the task manager. – Waxren Dec 13 '14 at 07:59

1 Answers1

3

Virtual memory allocation is mostly irrelevant (see for an explanation this answer) and very different from actual memory usage. The JVM is not designed to limit virtual memory allocation, see the question about limiting virtual memory usage.
The end-user may see a lot of virtual memory usage in the task-manager, but that is mostly meaningless. The different numbers for memory usage shown in the Windows task manager are explained in this article. In summary: in the Windows task manager look at the "Memory (Private Working Set)" and "Page Fault Delta" (the relevance of the latter is explained in this answer).

Community
  • 1
  • 1
vanOekel
  • 6,358
  • 1
  • 21
  • 56
  • Thanks for the great Answer.That explains a lot "The JVM is not designed to limit virtual memory allocation". – Waxren Dec 13 '14 at 18:30