P4
We have had to increase many of the constants in the CodeBuffer
constructors which are used to generate the interpreter and
other assembly stubs. The CodeBuffer code should be changed
so that the caller can grab a large piece of code and have the
end point be set once the code is generated. This would allow
us to get away from hard coding the size of stub and interpreter
code buffers.
I've noticed that the size of the generated code on sparcv9 64 bit
VMs varies even based on the size of the stack limit!! This means
that performance of the sparc interpreter may vary depending on the
stack size. I believe this is due to the code required to perform
a call and pointer load in the 64 bit VM. This should be looked at
and fixed at the same time as this RFE.
constructors which are used to generate the interpreter and
other assembly stubs. The CodeBuffer code should be changed
so that the caller can grab a large piece of code and have the
end point be set once the code is generated. This would allow
us to get away from hard coding the size of stub and interpreter
code buffers.
I've noticed that the size of the generated code on sparcv9 64 bit
VMs varies even based on the size of the stack limit!! This means
that performance of the sparc interpreter may vary depending on the
stack size. I believe this is due to the code required to perform
a call and pointer load in the 64 bit VM. This should be looked at
and fixed at the same time as this RFE.
- relates to
-
JDK-6316807 Its baaack - See 6282076 jdi_regression/nsk.jvmti failures ONLY on machine minh.sfbay
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-