RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3
mandy.chung at oracle.com
Tue Aug 12 06:26:22 UTC 2014
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:
>> 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.
> 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?
>> 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?
>> 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.
More information about the hotspot-runtime-dev