• Post Reply Bookmark Topic Watch Topic
  • New Topic

ResourceBundled being loaded

 
Gregg Wachter
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When running our application with -verbose:class I can see that when the ResourceBundle class gets loaded the total memory allocation shown in 'top' ( Solaris 7 ) jumps about 13M.
After tracing through the code to find out what uses this, I can see that Date.toString() or ( Date + "a str" ) causes the application to take this big memory hit.
Short of replacing all Date.toString() calls (lg app, could take a while to find) is there another way to avoid the loading of the ResourceBundle?
 
Peter Reinhardt
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think you can do it. I don't really see whats the performance problem anyway, the memory consumption of a resource bundle is (normally) not changing (so you need just these 13MB and thats it). More dangerous is code which causes memory leaks and increasing memory usage (leading to an OutOfMemory-Exception).
Usually a server application has about 1GB of memory available, so 13MB is not really much.
Peter.
 
Gregg Wachter
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Reinhardt:
I don't think you can do it. I don't really see whats the performance problem anyway, the memory consumption of a resource bundle is (normally) not changing (so you need just these 13MB and thats it). More dangerous is code which causes memory leaks and increasing memory usage (leading to an OutOfMemory-Exception).
Usually a server application has about 1GB of memory available, so 13MB is not really much.
Peter.

Thanks for the feedback.
The performance concern in this area is exactly memory. And, although our server has plenty of memory the server also houses our database and many other java processes. Obviously, if this was an idea J2EE environment our apps might not be on the same server as our database, but they are and money for new servers is not available like it once was.
Additionally, this app must support serveral different versions of our software in production at all times. With potential volume spikes there may be 2-3 instances of the most current release running. Therefore, there are usually 5 instances of this application running and it just seems unnecessary to give up 13M per instance for developers that don't format dates in trace statements.
This is a further concern as our other Java application running on the same server probably have the same date.toString() issue. If it could be solved for one and applied to all the overall impact could be substantial. 30 java apps X 13M (per) = 390M of memory wasted for date.toString()???
Can you see my concern now?
 
Peter Reinhardt
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the behaviour has only slightly to do with date. What happens in date.toString() is that all the localized resources (resourcebundle) is loaded. If you use a locale, a timeformat, a numberformat, a date, a calendar etc. the resourcebundle will be loaded. So if you perform any type of logging (Log4J for example) and happen to use dates the resourcebundle will be loaded as well (by the logging component).
The other thing is: you have to run the garbage collector to find out how much memory the call "date.toString()" really used up.
Peter.
[ August 08, 2002: Message edited by: Peter Reinhardt ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!