Name: nt126004 Date: 04/18/2002
FULL PRODUCT VERSION :
java version "1.3.1_02"
web start version 1.0.1_01 (build b04)
FULL OPERATING SYSTEM VERSION :Microsoft Windows 2000
[Version 5.00.2195]
SP2
A DESCRIPTION OF THE PROBLEM :
We use WebStart to launch our apps. Some of our apps were
running out of memory (even when explicitly calling the
garbage collector) because the memory wasn't being returned
to the OS. Incremental garbage collection fixes this
problem. We verified this fix via a command-line launch of
our app by passing the "-Xincgc" parameter to the JVM.
But using WebStart we can't tell the JVM to use incremental
GC because WebStart won't pass that parameter on to the JVM!
Please add this support for us.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Start an app from WebStart that will allocate and free a
lot of memory
2. In the Windows Task Manager, in the Proccesses tab,
locate this process and watch the Mem Usage column.
3. Notice that memory usage grows and grows but even long
after the memory has been freed, the app's footprint is
much larger than it should be.
4. Repeat these steps by launching the app from a command
line, passing the "-Xincgc" parameter to the JVM.
5. Notice that the memory usage is much more reasonable.
6. Add a line to the app's jnlp file like this:
<property name="X" value="incgc"/>
7. Verify that you're getting this updated jnlp file from
your launch web page.
8. Run the test again by launching the app from WebStart
9. Notice that the memory usage matches the first WebStart
test and not the command line test.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Without incgc, memory usage is bad. With incgc, memory
usage is better. Specifying incgc via the jnlp file has no
effect on memory usage, so it doesn't look like WebStart
supports the passing of the -Xincgc flag to the jvm.
This bug can be reproduced always.
CUSTOMER WORKAROUND :
We haven't tried this yet, but we should be able to put an
alias (or batch file or something) on the users' machines
to launch "java -Xincgc" instead of simply "java". This is
an ugly hack and a lot of extra maintenance that we'd like
to avoid.
(Review ID: 144947)
======================================================================
- duplicates
-
JDK-4790673 allow arbitrary VM args if JNLP Client verifys they are safe.
-
- Resolved
-