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

[David Holmes]

Hi Mandy,

On 12/08/2014 9:01 AM, Mandy Chung wrote:
> 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.

An extra upcall per class loaded from the archive may indeed be a 
significant performance degradation!

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

Ditto.

David
-----

> 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
>