On 21/05/2013 2:50 PM, Dean Long wrote:
Right, unless there is a way to inject them conditionally.
You can inject them conditionally based on the JRE version, but then why
bother moving to the Java level if you will still need the code in the VM ?
On 5/20/2013 9:02 PM, Ioi Lam wrote:
But if you move these fields into Class.java (in JDK8), then hsx25
will not run on JDK7 anymore, unless these fields are also added in
Class.java in JDK7.
As I understand it hs25 is already limited in the versions of jdk7 that
it can run in.
David
-----
- Ioi
On 05/20/2013 05:42 PM, Dean Long wrote:
It seems like you could take this opportunity to make these declared
fields of java.lang.Class,
allowing, for example, getProtectionDomain0() to be a simple Java
method instead of a native method.
dl
On 05/20/2013 03:39 PM, Coleen Phillimore wrote:
Summary: Inject protection_domain, signers, init_lock into
java_lang_Class
Net footprint change is zero except that these fields are in Java
heap rather than metaspace. This helps a little with InstanceKlass
size which is in fixed size space with UseCompressedKlassPointers.
Included serviceability because there were SA changes to code that I
don't know is used.
Future work is to remove the signers field and the unused
SetProtectionDomain function.
open webrev at http://cr.openjdk.java.net/~coleenp/8003421/
bug link at http://bugs.sun.com/view_bug.do?bug_id=8003421
Tested with vm.quick.testlist, JPRT, jtreg java/security tests and
jck8 tests.
Thanks,
Coleen
