RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

[Mandy Chung]

On 8/11/14 2:15 PM, Ioi Lam wrote:

>> http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/

I would like to avoid adding private methods for VM to call
as fewer as possible.

SecureClassLoader.getProtectionDomain(URL)
    Can you use the existing private getProtectionDomain(CodeSource)
    method instead?  The VM can call the public CodeSource(URL, CodeSigner[])
    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.

Launcher.getFileURL(String)
    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?

URLClassLoader.defineClass
    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.

Mandy