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

[Mandy Chung]

On 8/11/2014 11:23 PM, David Holmes wrote:
> 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!
>

Is it called per URL (jar file)?  Same for manifest?

Mandy

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