This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js and have Paul Jensen on-line!
See this thread for details.
Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JRE Memory Footprint Bug  RSS feed

 
Joseph Goodman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I reported a bug against the JRE 5.0:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5107500

If there is anybody else who is frustrated with the memory footprint of a simple Swing application on a Windows O/S, please take a look at this bug and vote on it. If you know of a similar bug report that already has more votes, let me know and I will vote on it. I think if we can fix this bug, or at least explain it, it will go a long way toward putting more Java applications on the desktop.

Thanks
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Start a very big program, like eclipse, which uses 5 times the memory than your simple frame.
If you don't start 20 small apps simultanously, I think there is no big practical problem in the memory-usage.

If you have to start 20 small apps, start them with a super-app, so that they may share the jvm.
[ October 08, 2004: Message edited by: Stefan Wagner ]
 
Joseph Goodman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I disagree. I think the developer should not have to get the memory footprint down for his/her small app by writing a hack. Sun should make the JREs share the memory. I know that they were supposed to do something like that for JRE 5.0 but it doesn't look like they did. Sun should also explain what is causing such large amounts of memory to be used. One answer I received was that Shell32.dll, a Windows DLL, was using 5x more memory than other DLLs loaded by the JRE. My question is why? Is this intentional or a bug? Why not reduce the amount of memory use if it is possible?

I think if people are serious about Java on the desktop then they need to make Java more competitive with native applications. This means faster execution speed, which looks good in JRE 5.0, and smaller memory footprint.

Just my two cents
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Joseph Goodman:
One answer I received was that Shell32.dll, a Windows DLL, was using 5x more memory than other DLLs loaded by the JRE. My question is why? Is this intentional or a bug? Why not reduce the amount of memory use if it is possible?


Sun doesn't have any impact on the size of that dll - it's from microsoft.

Dll's are already shared between programs, so that shouldn't be a problem, anyway.
 
Joseph Goodman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sun's comment in the bug report claims that Shell32.dll is being used by the JRE and that Shell32.dll is what is allocating a majority of the memory.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5107500
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Joseph Goodman:
Sun's comment in the bug report claims that Shell32.dll is being used by the JRE and that Shell32.dll is what is allocating a majority of the memory.


Yes.

But it isn't only used by the JVM, it would be shared between JVMs, it actually might already be loaded before you start Java (if it is used by a non-Java program) - and Sun couldn't do something about its size, anyway. It's part of your Windows installation.
 
Joseph Goodman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:


Yes.

But it isn't only used by the JVM, it would be shared between JVMs, it actually might already be loaded before you start Java (if it is used by a non-Java program) - and Sun couldn't do something about its size, anyway. It's part of your Windows installation.



I am realize that Shell32.dll is part of the Windows installation. I believe that the code of the DLL is shared between processes and not any heap memory.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_libraries.asp

Why does Sun claim that Shell32 is allocating a large portion of the memory in the JRE process? I would think that the JRE would have to be calling some methods in the DLL to cause the memory allocation to be so high. Furthermore, if you use the Depends application on notepad.exe, you see that notepad uses Shell32.dll. If you look at the memory footprint of notepad.exe it doesn't appear to be very large at all. Which brings me back to the point of the bug report, somebody needs to explain what is causing such a large memory footprint with the JRE.
 
R�mi Forax
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On windows, the memory usage display by the taskmanager
take into account DLL loaded by the program.

So if a program have a size of 10 Megs, in memory
because DLL are shared between programs perhaps
the program have a real size of 3 Megs.

I think with this explanation, you can better
understand the SUN comment.

Furthermore, reading the comment below the bug report,
this comment seems not coming from a SUN guy.

In summary, the size displayed by the taskmanager is
not the real size as the comment says, if you iconify your
app the size change ??
 
Joseph Goodman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are right Remi. The comment may have come from an anonymous poster and not a Sun Microsystems person. I still think that it is important that Sun fully explain this issue so that the developer's can defend their applications.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!