RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3
david.holmes at oracle.com
Tue Aug 12 06:23:50 UTC 2014
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!
> 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 core-libs-dev