RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3
ioi.lam at oracle.com
Tue Aug 12 06:10:43 UTC 2014
On 8/11/14, 4:01 PM, Mandy Chung wrote:
> On 8/11/14 2:15 PM, Ioi Lam wrote:
> I would like to avoid adding private methods for VM to call
> as fewer as possible.
> Can you use the existing private getProtectionDomain(CodeSource)
> method instead? The VM can call the public CodeSource(URL,
> constructor. I doubt an additional up call from the VM to Java
> may cause performance degradation as much while I think it's
> a good tradeoff. It also allows this be extended to signed JARs
> if it's considered.
> Manifest.getManifest(byte buf)
> Is saving one additional upcall from VM to Java very critical?
> I prefer the VM to use public APIs to minimize such dependency
> in the library.
> This is a convenient method for VM. If VM calls getFileURL(File),
> it's still a new dependency. Is there any other way doing it?
I agree we should avoid adding new private Java methods if possible.
I've rewritten the 3 calls in C. It's a little messy: a single line of
Java code needs to be written like:
// JAVA: CodeSource cs = new CodeSource(url, null);
InstanceKlass* cs_klass =
Handle cs =
JavaCalls::call_special(&result, cs, KlassHandle(THREAD, cs_klass),
url, Handle(), CHECK_(protection_domain));
There's some minimal checking with argument types (default in debug
build, -XX:+CheckJNICalls in product build), but I think there's no
check if you forget to call the <init> method.
We could probably add a new JavaCalls::new_instance() function to make
the code a little cleaner (and make sure the <init> is called). I can do
this as a separate clean-up bug.
> 438 * NOTE: the logic used here has been duplicated in the VM
> native code
> 439 * (search for invocation of definePackageInternal in the
> HotSpot sources).
> 440 * If this is changed, the VM code also need to be modified.
> Is the definePackageInternal only logic duplicated in the VM?
> I wonder if this comment can be clear what is duplicated.
I'll reword it and send out a new webrev, along with the rest of the code.
More information about the hotspot-runtime-dev