Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2131677 | 5.0u7 | Paul Hohensee | P5 | Closed | Fixed | b01 |
JDK-2131678 | 1.4.2_11 | Paul Hohensee | P5 | Closed | Fixed | b02 |
For sparc32 and x86, InitialCodeCacheSize = 160kb and
ReservedCodeCacheSize = 32mb. For sparc64, amd64,
and ia64 the values are 1mb and 1gb, which seem (except
maybe for ia64) relatively too large. Sun's System
Resource Manager counts reserved memory as actual memory
allocated, even though only committed memory actually
takes up swap. So SRM can refuse to run the vm if its
va limit is set too low.
For sparc64 and amd64, we can drop them to double
the 32-bit values: 320kb and 64mb. The code expansion
from 32-bit to 64-bit in each case is less than double,
nor do I believe that we compile any more methods in
64-bit mode than in 32-bit mode. If anyone's worried
that double is too small, triple (480kb and 96mb) would
be ok too. Or, we could use triple initial and double reserved
(480kb and 64mb).
###@###.### 2005-03-24 21:22:02 GMT
ReservedCodeCacheSize = 32mb. For sparc64, amd64,
and ia64 the values are 1mb and 1gb, which seem (except
maybe for ia64) relatively too large. Sun's System
Resource Manager counts reserved memory as actual memory
allocated, even though only committed memory actually
takes up swap. So SRM can refuse to run the vm if its
va limit is set too low.
For sparc64 and amd64, we can drop them to double
the 32-bit values: 320kb and 64mb. The code expansion
from 32-bit to 64-bit in each case is less than double,
nor do I believe that we compile any more methods in
64-bit mode than in 32-bit mode. If anyone's worried
that double is too small, triple (480kb and 96mb) would
be ok too. Or, we could use triple initial and double reserved
(480kb and 64mb).
###@###.### 2005-03-24 21:22:02 GMT
- backported by
-
JDK-2131677 Reduce default code cache sizes on 64-bit platforms
- Closed
-
JDK-2131678 Reduce default code cache sizes on 64-bit platforms
- Closed