JDK-4354492 : instanceof should not cause class loading
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-07-19
  • Updated: 2020-02-06
  • Resolved: 2001-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 beta2Fixed
Related Reports
Relates :  
JDK-6592631 - instanceof should not cause class loading in the interpreter
Description
Currently using the instanceof operator can cause a class to be loaded.  The runtime could check to see if the class was loaded, and if it was not the runtime would know there were no instances, and thus the object in question couldn't be an instance of that class.

Phil Milne observed this problem where many extra Swing classes were loaded due to an instanceof check.  Fixing this could help footprint/startup time.
Comments
[~serb] Right, it seems this optimization would break the JVM spec, and the fix might not even have made it into 1.4 GA (I couldn't get 1.4.0 to run on my machine, but 1.4.2 works and loads classes referenced only in instanceof). See comments in the linked bug, JDK-6592631
06-02-2020
[~redestad] It looks like this bug was not fixed, right? At least the simple test case shows that the classes used in the instanceof are actually loads.
06-02-2020
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004
EVALUATION Performance issue needing attention. david.stoutamire@Eng 2000-08-12 Note that this is not as straightforward as it seems due to loader delegation. Assume that class A is loaded by loader L1, that a method in A contains an "obj instanceof B" check, and that the SystemDictionary doesn't contain a (B,L1) entry. Concluding that obj couldn't be an instance of (B,L1) is not correct: If asked to load B, L1 could decide to delegate to L2, and the SystemDictionary could contain a (B,L2) entry which would then be returned. (B,L1) and (B,L2) would then be the same class object, and "obj" would indeed be an instance of (B,L1)! Note that this happens often for L2 being the system (NULL) loader and L1 beign the default Java level application loader. The optimization does apply when the VM knows that delegation will not occur, for instance when L1 is the NULL loader. steffen.grarup@eng 2001-02-04 Instead of restricting this optiumisation to the NULL class loader we can implement a slightly different test if we know the delegate of the class loader L1. We first test the VM for class (B, L1). If this exists there is no optimisation to be made. If it does not exist we check for (B, L2), where L2 is the delegate of L1. If, after following the chain of delegates, we arrive at the NULL class loader, and no entry is found for (B, NULL) we may conclude that the value of "instanceof" is false without loading the class. philip.milne@eng 2001-02-05 fred.oliver@East 2001-02-26 (a) It is not possible to determine how an arbitrary classloader may delegate to other classloaders. We have run into customer classloaders which do some very odd things. We could make special arrangements for our own classloaders, or start adding to the API, but this is a non-trivial change for an unidentified gain (and a maintenance problem?). (b) By declining to load the class, we are exchanging a one-time performance penalty (and some footprint) for a penalty on each invocation of "instanceof" refering to that class, particularly if we need to access multiple classloader objects each time. (c) For the system classloader specifically, the check makes more sense, because the JVM has direct access to the classpath elements and can check them quickly, though this may involve system calls and multiple hashtable lookups. On the flip side, (a) loading from the system classpath is relatively quick, (b) since verification does not apply, no additional classes need be loaded, and (c) future work (e.g. resource sharing) may make the system class load much quicker still. At this point, it is not clear to me that avoiding the class load is the way to go. fred.oliver@East 2001-06-18 Fixed for merlin-beta2. If obj's class was loaded by the boot classloader, then if class (or interface) Foo has not been loaded by the boot classloader, return FALSE **without** loading Foo. Array classes are not considered for optimization. In the SwingSet2 demo, all occurances of arrays refered to java/lang/Object (already loaded). Performance notes - based on SwingSet2 demo startup: C1: The operator instanceof was evaluated 25,891 times. Of these, 3,381 (13%) refered to a class which was not loaded. 31 classes don't get loaded that otherwise would. C2: The operator instanceof was evaluated 69,865 times. Of these, 8,648 (12%) refered to a class which was not loaded. 31 classes don't get loaded that otherwise would. Interp: The operator instanceof was evaluated 85,240 times. Of these, 10,200 (12%) refered to a class which was not loaded. 31 classes don't get loaded that otherwise would.
11-06-2004