Re: Review request for 4917309 and 6864003

[Karen Kinnear]

JVM_FindClassFromBootLoader is new with JDK7. Kumar added it.

thanks,
Karen

On Jul 24, 2009, at 11:07 AM, Paul Hohensee wrote:

Can't remove it unless it's fixed in jdk6 as well as 7.  Also, one  
of these days we'll
get around to shipping current hotspot in jdk5 and maybe 1.4.2.  How  
would these

be affected?

paul

Keith McGuigan wrote:


I would prefer that we avoid requiring synchronous pushes (so I  
guess I think we should leave that parameter in for now).


If anything, maybe file a low-priority RFE to remove that parameter  
later?


--
- Keith

Mandy Chung wrote:

David Holmes - Sun Microsystems wrote:

Hi Mandy,

661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
662   const char* name,
663   jboolean  
throwError))


Can't we now drop the throwError parameter altogether?

Yes, I could.  I agree it doesn't need this throwError  
parameter.   I decide to leave it since it helps to avoid the  
synchronized pushes.  JVM_FindClassFromBootLoader is already in a  
promoted build.   I can push the JDK fix and HotSpot fix at the  
same time.  Note that the JDK fix and HotSpot fix are pushed and  
integrated in two different gates and at different time.


If I modify the signature, I would have to push the HS fix first  
(say b68).  Wait until b68 is promoted, then I can push the JDK  
fix in b70.


If you strongly feel that I should drop the throwError parameter,  
I could make the change.


Thanks
Mandy


Pity we can't make a similar fix to the extensions loader ...

Cheers,
David

Mandy Chung said the following on 07/24/09 09:53:
This review request is for both the HotSpot runtime and the core  
libs teams.


Fixed 4917309: (cl) Reduce internal usage of  
ClassNotFoundExceptions during class-loading
Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null  
if class not found


Summary:
o Fix java.lang.ClassLoader to use the new VM entry point
  JVM_FindClassFromBootLoader for load a system class from
  the bootstrap classloader that will reduce the number
  of ClassNotFoundException objects thrown by the application
  class loader by 50%.  The remaining half of the  
ClassNotFoundException
  objects are thrown by the extension class loader which is the  
parent

  of the application class loader.
o ClassLoader.loadClass and ClassLoader.findSystemClass will
  throw ClassNotFoundException as they are specified.
o JVM_FindClassFromBootLoader is currently not used (going to
  used by the java launcher see 6864028). There is no issue
  of changing it to return null instead of throwing CNFE.

Webrev:
 http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
 http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/


Thanks
Mandy

Re: Review request for 4917309 and 6864003

[Mandy Chung]

Alan Bateman wrote:

Mandy,

I see in ClassLoader#loadClass that you still allow 
findBootstrapClassOrNull to throw CNF. I assume this is needed until 
there is a promoted build with the updated 
JVM_FindClassFromBootLoader, after which you will go back to clean it 
up - do I have this right? 
I leave the call to findBootstrapClassOrNull inside try-catch clause (1) 
to work with the existing VM and (2) I think it's better to leave it 
this way as opposed to do something like this:
  if (parent == null) { 
c = findBootstrapClassOrNull(name);

  } else {
try {
c = parent.loadClass(name, false);
} catch (ClassNotFoundException e) {
   // ClassNotFoundException thrown if class not found
   // from the non-null parent class loader
}
   }

So that's the final version and no need to clean up.

Mandy