JDK-6902539 : the initial Java heap size option in 6u17
Type:Bug
Component:tools
Sub-Component:javac
Affected Version:6u17-rev
Priority:P3
Status:Closed
Resolution:Duplicate
OS:windows
CPU:x86
Submitted:2009-11-18
Updated:2011-06-23
Resolved:2011-06-23
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
EVALUATION
resolved by the fix for 6558476 in 6u27.
23-06-2011
WORK AROUND
Following a workaround I do not see the issue as a clear product regression in the latest 6u17/18 builds. In the same time the test's jvm -Xms option value that makes it passed is variable against a particular Build on the same OS. It's always reproducible.
The acceptable value variation against (6u15,6u17,6u18) on one system is from -Xms184 to -Xms197 and it's always reproducible for a particular Build on the same OS.
This value is -Xms57m (not bigger) against 6u06-rev-b03
javac version itself does not make a difference if be used from 6u06 to 6u18.
The acceptable value for the test status has a dependency on jvm build version the class file is implemented on.
There is no customer escalation against it. The value -Xms200m defined should be modified (reduced) if you see it as not critical anymore for the test as per CR 5071352 customer's requirement. Otherwise it produces unstable results. I can't justify at this stage how critical at present the initial jarfile closure issue per 5071352 with relation to -Xms value defined.