P5
A DESCRIPTION OF THE REQUEST :
It would be a great feature if the JVM could be told to actually release allocated memory back to the system, so that the actual system memory footprint was reduced.
The JVM now steadily increases memory usage up to -Xmx (plus all other shared stuff). In some scenarios, it would be very fortunate if one could get it to decrease its usage drastically "upon request".
System.gc() asks the JVM to do a garbage collect. A System.release() (or something like that) could ask the JVM to actually release the allocated memory.
JUSTIFICATION :
My need revolves round a "systray" feature, where the application will "minimize to tray" but still have an limited feature set while it's docked there. However, if the user doubleclicks, it should "load up" again, going back to full functionality.
However, in this specific scenario, the "full application" is a huge memory-hog (its a high-caching image-oriented thingy), and will try to gobble up as much memory as possible while fully active. Thus, it's very unfortunate that if the user "minimizes to tray" to leave the application's main functionality, the application still have allocated 1 GB or more of the system's memory (which even if swapped to disk will give the user a problem).
Such a memory-releasing feature would thus be great: When the user "minimizes to tray", the application would let go of all its memory-buffers and other resources, ditch the full app's classloader to unload most classes, and then do a System.release() (or whatever procedure that was deemed the correct here) to actually fully release memory back to the OS.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Upon System.release(), the JVM would shrink its memory allocation down to absolute minimum (or -Xmn if set) to contain the currently active set of objects and classes.
ACTUAL -
The JVM will allocate memory up to the -Xmx mark (and obviously way above due to the JVM and dependent libs itself), but wont shrink.
CUSTOMER SUBMITTED WORKAROUND :
Have some small native application (or another instance of the JVM) that executes the application, where "minimize to tray" actually exits the full app JVM.
A couple of solutions for how the tray features would be handled compared to the full-app:
1) The tray-features is contained in this wrapper application
2) The tray-features is contained in another application, so the wrapper application basically alternates between starting the full-app or the tray-app.
2) The wrapper simply restarts the main app, which then starts in minimized mode by not loading the full app, and not allocating all its buffers and whatevers. Then when the user clicks "activate", it loads the rest of the app.
PS: Why can't this annoying junky bug database load my "sun online account id" itself when I'm logged in?!
It would be a great feature if the JVM could be told to actually release allocated memory back to the system, so that the actual system memory footprint was reduced.
The JVM now steadily increases memory usage up to -Xmx (plus all other shared stuff). In some scenarios, it would be very fortunate if one could get it to decrease its usage drastically "upon request".
System.gc() asks the JVM to do a garbage collect. A System.release() (or something like that) could ask the JVM to actually release the allocated memory.
JUSTIFICATION :
My need revolves round a "systray" feature, where the application will "minimize to tray" but still have an limited feature set while it's docked there. However, if the user doubleclicks, it should "load up" again, going back to full functionality.
However, in this specific scenario, the "full application" is a huge memory-hog (its a high-caching image-oriented thingy), and will try to gobble up as much memory as possible while fully active. Thus, it's very unfortunate that if the user "minimizes to tray" to leave the application's main functionality, the application still have allocated 1 GB or more of the system's memory (which even if swapped to disk will give the user a problem).
Such a memory-releasing feature would thus be great: When the user "minimizes to tray", the application would let go of all its memory-buffers and other resources, ditch the full app's classloader to unload most classes, and then do a System.release() (or whatever procedure that was deemed the correct here) to actually fully release memory back to the OS.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Upon System.release(), the JVM would shrink its memory allocation down to absolute minimum (or -Xmn if set) to contain the currently active set of objects and classes.
ACTUAL -
The JVM will allocate memory up to the -Xmx mark (and obviously way above due to the JVM and dependent libs itself), but wont shrink.
CUSTOMER SUBMITTED WORKAROUND :
Have some small native application (or another instance of the JVM) that executes the application, where "minimize to tray" actually exits the full app JVM.
A couple of solutions for how the tray features would be handled compared to the full-app:
1) The tray-features is contained in this wrapper application
2) The tray-features is contained in another application, so the wrapper application basically alternates between starting the full-app or the tray-app.
2) The wrapper simply restarts the main app, which then starts in minimized mode by not loading the full app, and not allocating all its buffers and whatevers. Then when the user clicks "activate", it loads the rest of the app.
PS: Why can't this annoying junky bug database load my "sun online account id" itself when I'm logged in?!