RFR: JDK-8222373 Improve CDS performance for custom class loaders

[Ioi Lam]

On 6/20/19 10:35 AM, Alan Bateman wrote:
> On 20/06/2019 17:50, yumin qi wrote:
>> Hi, Alan and Ioi
>>   Thanks. Forget to add core-libs-dev for the review.
>>   If add a public API, surely it should be discussed in detail the 
>> design, implementation and effects. One question, will adding a 
>> public API for ClassLoader need go some process like CSR?
>>   I did not add public API here and tried to avoid such process, that 
>> may not be a good choice for this case.
>>
> You've add a protected member to java.lang.ClassLoader and also 
> changed one of the protected defineClass methods to allow the class 
> bytes be null so this is changing the Java SE API. But yes, API 
> changes will require CSR approval. I think we first need fo figure out 
> the right approach. I see Ioi's mail with a sketch of an API that 
> provides the location in some form and so requires the VM/runtime to 
> know how to read class bytes that that location. Providing a location 
> and supplier of class bytes is another variant of that to avoid 
> needing the VM to ability to load the class bytes when the class is 
> not in the CDS archive. There are several options that need to be 
> exploded to see if it make sense for the standard API.
>
> -Alan


Alan, do you mean something like

protected Class defineClass(String name, ClassDataSupplier data, 
ProtectionDomain pd) {
     String location = data.getLocation();
     Class c = vminternal.findSharedClass(name, location, pd);
     if (c == null) {
         byte buffer[] = data.fetch();
         c = defineClass(name, buffer, 0, buffer.length(), pd);
     }
     return c;
}


Thanks
- Ioi