FWD » Core Development » Base Language

First run:
- baseline: java.lang.NoSuchMethodException  14723
          : java.lang.ClassNotFoundException 6903
- 9032a   : java.lang.NoSuchMethodException  11833
          : java.lang.ClassNotFoundException 5908
- 9032c   : java.lang.NoSuchMethodException  14723
          : java.lang.ClassNotFoundException 6903

After warmup:
- baseline: java.lang.NoSuchMethodException  52
          : java.lang.ClassNotFoundException 471
- 9032a   : java.lang.NoSuchMethodException  51
          : java.lang.ClassNotFoundException 471
- 9032c   : java.lang.NoSuchMethodException  51
          : java.lang.ClassNotFoundException 471

9032a brings a slight improvement of 20% less NoSuchMethodException and 14% ClassNotFoundException for the first run of the test.

When it comes to the origins of these exception, this is my analysis:
In callMethod

            // attempt to use simple reflection for all super classes
         while (itClass != null)
         {
            try
            {
               method = itClass.getDeclaredMethod(methodName, parTypes);  // the origin of NoSuchMethodException

               // if we found the method, exit the while loop
               break; 
            }
            catch (NoSuchMethodException e)
            {
               // do nothing, expected exception if method not defined here
            }

            itClass = itClass.getSuperclass();
         }

In RuntimeJastInterpreter.callCtor:

    for (String path : imports)
            {
               // load class, prepare constructor
               String ctorClass = path + ctorNode.getText();
               try
               {
                  queryClass = classForName(ctorClass); // // the origin of ClassNotFoundException
                  break; // found it
               }
               catch (ClassNotFoundException e)
               {
                  // not the right package this class, try next package
               }
            }

Ovidiu, is there a strong reason to use reflections instead of a manual lookup?

I am not sure what "manual lookup" means?

• a set of paths (added by conversion, similar to import statements);
• a name of a class whose package is unknown, but normally should be one of the paths/packages above.

The solution I quickly implemented is by brute force, I admit. I did not take the time to optimize it, and let the caching (the runtime annotation) to provide a quick lookup on subsequent calls. Taking each of the 'paths' and inspecting whether there is a class there with a specific name (using reflection, as well) does not look like a better/faster approach. You may try implementing this and compare the lookup for 1000 classes to decide the winner.

I welcome any another ideas...

Manual lookup is something I saw in the comments, I did not dive too deep.
If the reflection fails, this happens:

 if (method == null)
         {
            // attempt to do it manually (because of null values most likely)
            method = findMatchingMethod(aClass, methodName, parTypes, minargs);
         }

Looks into the list of methods of a class for the one that matches name and the list of argument types

If you look at the findMatchingMethod method you'll see that it is a far more CPU intensive routine. It will go up the inheritance tree and try to get a match from all methods based on the (name and) provided signature. Even so, a perfect match is not always available, so a 'compatibility matrix' is used (for example invoking setLong(long) using an int parameter or throwException(Throwable) using an SQLException).

This would actually be a good candidate for performance improvements. Note that the call end up in Function.matchSignatire() and it is used in different other places (for example in TRPL) for method lookup in interpretative execution is required.