Method info caching feedback, small performance updates

First I should explain some background. We are changing the presentation level 
architecture in OFBiz and instead of using JSPs we are using FreeMarker for 
templating, and BeanShell for the data preparation logic, triggered through 
BSF with JPublish coordinating things.

Anyway, we started using Rhino JavaScript, but after some profiling we found 
out that it was really slow, so we switched to BeanShell. There was an 
immediate performance increase, but with a few changes I have been able to 
eek some more speed/efficiency out of it.

One interesting thing I did was to create a custom BSF engine for BeanShell 
that has a custom eval method. It splits eval into a parse and execute phase, 
making it possible for us to cache parsed scripts. This didn't result in a 
huge performance increase because the BeanShell parsing is really quite good, 
but it did help quite a bit.

I have also updated to use the latest code from CVS. I noticed that some work 
has been done on caching method reflection data for method invocation. In the 
profiling I have been doing the slowest part seemed to be the 
class.getMethods calls. So, I made two changes there: copied the original 
before changing so it could be used the second time, and I introduced a 
HashMap to cache Method[]s that would normally come from the class.getMethods 
call.

This helped quite a bit with performance, but I think a little bit more work 
may be needed because using a HashMap like this for caching basicly assumes 
that the classes are constant, but bsh uses a dynamic class loader so it may 
not always be the case.

Re: Method info caching feedback, small performance updates

On Thu, Mar 06, 2003 at 02:47:20AM -0800, David E Jones wrote:
> I have also updated to use the latest code from CVS. I noticed that some work 
> has been done on caching method reflection data for method invocation. In the 
> profiling I have been doing the slowest part seemed to be the 
> class.getMethods calls. So, I made two changes there: copied the original 
> before changing so it could be used the second time, and I introduced a 
> HashMap to cache Method[]s that would normally come from the class.getMethods 
> call.

I'll take a look at your patch.  The optimizations in CVS for 1.3 are at
a higher level and they cover the method resolution code as well as low
level reflection...  during the "steady state" there shouldn't be any
reflective method lookup going on...  But I bet that the low level method 
info caching that you describe might speed the initial startup time.  Is
this what you're seeing? 

I'd also be interested to know how the simple, low level getMethod() caching
compares to the 1.3 code with the high level (more complicated) caching.
Perhaps we could apply your patch to the 1.2 codebase and compare...  The
primary thing that the high level caching avoids is a lot of reflective calls 
to Class.isAssignableFrom() during overloaded method resolution...

I'd really appreciate any feedback on the caching mechanism in the 1.3
CVS code.  If you could run the 1.2 code for comparison and see how much
difference there is that would help a lot.  I'm also curious as to whether
anyone has any concerns about memory consumption in caching the method
resolution based on the argument types.

Also, as far as caching and class reloading goes - we can deal with it by
placing the cache in the class manager... so that it gets flushed when

Re: Method info caching feedback, small performance updates

Pat,

In the 1.3 codebase (currently CVS head) is there something that must be done 
to enable the reflection cache? 

From my profiling tests with 1.2b7 I saw a small number of pain/bottleneck 
points related to getting reflection meta-data. The cache you describe should 
nab them all. The main slow ones are getMethods and getDeclaredMethod. When I 
say that I don't mean in general (they are all somewhat slow in general), I 
mean specifically for the way your code is written based on profiling data.

After playing with that I decided to get your latest code since you probably 
aren't too interested in changes based on old code. When I looked at your 
change log I noticed that you had this caching in place, so I dropped it in 
and did another profiling run. I didn't see any significant speed increase so 
I put in a really simple cache for the most time costly call: getMethods.

If you have a higher level cache in place that would certainly be better 
because there are other reflection meta-data calls that are getting in the 
way of performance. However, either there is something funny in the way it is 
written or it is not enabled because before I put my simple cache in the 
profiling data showed a lot of calls that could be avoided by the cache.

That sounds like a good idea, ie attaching the cache to the class loader so 
that when it is reloaded the reflection cache can be cleared out too.

As far as speed vs size issues go, I think this is a clear choice for this 
type of cache. We might find otherwise in testing, but my guess is that a 
cache like this will not take a significant amount of memory, even if it uses 

bsh, bsf 2.3, org.apache.bsf

hi beanshell,

i noticed the BSF engine in the 'bsf' directory is referencing
the old BSF package (com.ibm.bsf). since BSF was taken over by
apache (jakarta.apache.org/bsf/), the package has changed to--
surprise--org.apache.bsf. the API has not changed, so the only
thing to do is change the import statements.

the files affected are:
BeanShell/bsf/src/TestBshBSF.java
BeanShell/bsf/src/bsh/util/BeanShellBSFEngine.java

i don't think this is complex enough to submit a patch...

j.

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: bsh, bsf 2.3, org.apache.bsf

On Fri, Mar 14, 2003 at 02:30:30PM -0800, White, John K wrote:
> hi beanshell,
> 
> i noticed the BSF engine in the 'bsf' directory is referencing
> the old BSF package (com.ibm.bsf). since BSF was taken over by
> apache (jakarta.apache.org/bsf/), the package has changed to--
> surprise--org.apache.bsf. the API has not changed, so the only
> thing to do is change the import statements.
> 
> the files affected are:
> BeanShell/bsf/src/TestBshBSF.java
> BeanShell/bsf/src/bsh/util/BeanShellBSFEngine.java

Thanks.  I'm making this change for the 1.3 release and will provide 
an alternate package for those using the old BSf.

Pat

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Method info caching feedback, small performance updates

On Thu, 6 Mar 2003, Pat wrote:

> I'd really appreciate any feedback on the caching mechanism in the 1.3
> CVS code.  If you could run the 1.2 code for comparison and see how much
> difference there is that would help a lot.  I'm also curious as to whether
> anyone has any concerns about memory consumption in caching the method
> resolution based on the argument types.

I found a bug which was causing a NullPointer exception where you are
creating cache entries for methods using argument types. Basically, when
you make calls with 'null' values, a spurious cache entry is created. I
reported it and provided a patch to cvs1.3, but I didn't get any feedback
so far (reported as "[ 705300 ] Method signature caching fails with 'null'
arguments" in SF's bug tracker)

Cengiz Gunay
--
cengiz@...
Home: (337)482-7570 	Lab: (337)482-5079
http://www.cacs.louisiana.edu/~cxg9789
ICQ# 21104923
--

-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Remote session throws applet exception

javax.servlet does exist (builiding with J2SE)

I'm having difficulty building BeanShell retrieved via anonymous CVS on 
Win98SE, with J2SE 1.4.1_02 and Ant 1.5.2.  I've tried both the latest 
revision and branch_1_2_head.  In both cases, I get lots of error 
messages, starting with

     [javac] 
H:\Projects\BeanShell\BeanShell\src\bsh\servlet\BshServlet.java:4: 
package javax.servlet does not exist
     [javac] import javax.servlet.*;
     [javac] ^
     [javac] 
H:\Projects\BeanShell\BeanShell\src\bsh\servlet\BshServlet.java:5: 
package javax.servlet.http does not exist
     [javac] import javax.servlet.http.*;
     [javac] ^

in the middle of building target "compile:"

My Ant command-line is:

ant -l log -Dexclude-servlet=1

but apparently it is still trying to compile stuff under bsh/servlet 
which tries to import from javax.servlet.

With the latest CVS, I also have to define -Djjtree.notRequired=1, 
otherwise it dies earlier with

jjtree:
      [java] java.lang.NoClassDefFoundError: COM/sun/labs/jjtree/Main
      [java] Exception in thread "main"

Can anyone tell me what I need to do to build with J2SE?

I wasn't sure whether to ask this on the developers list or the users 
list.  My apologies in advance if this is the wrong place.

Thanks,
David

-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: javax.servlet does exist (builiding with J2SE)

David C. Fox wrote:
> I'm having difficulty building BeanShell retrieved via anonymous CVS on 
> Win98SE, with J2SE 1.4.1_02 and Ant 1.5.2.  I've tried both the latest 
> revision and branch_1_2_head.  In both cases, I get lots of error 
> messages, starting with
> 
>     [javac] 
> H:\Projects\BeanShell\BeanShell\src\bsh\servlet\BshServlet.java:4: 
> package javax.servlet does not exist
>     [javac] import javax.servlet.*;
>     [javac] ^
>     [javac] 
> H:\Projects\BeanShell\BeanShell\src\bsh\servlet\BshServlet.java:5: 
> package javax.servlet.http does not exist
>     [javac] import javax.servlet.http.*;
>     [javac] ^
> 
> in the middle of building target "compile:"
> 
> My Ant command-line is:
> 
> ant -l log -Dexclude-servlet=1
> 
> but apparently it is still trying to compile stuff under bsh/servlet 
> which tries to import from javax.servlet.

Well, I found out that it is possible to download the SDK for J2EE for 
internal evaluation without applying, so having done so and included 
j2ee.jar in my CLASSPATH, I no longer get the errors above.

However, now I'm getting similar errors:

     [javac] 
H:\Projects\BeanShell\BeanShell\bsf\src\bsh\util\BeanShellBSFEngine.java:13: 
package com.ibm.bsf does not exist
     [javac] import com.ibm.bsf.*;
     [javac] ^

related to the BSF package.  Again, setting exclude-bsf didn't seem to 
help, so I located BSF, downloaded and installed the binary of bsf-2.2, 
added bsf.jar to my CLASSPATH.  Unfortunately, this doesn't seem to 
help.  Maybe I need the source distribution of BSF, which I'll try next.

It still would be nice if

a) exclude-servlet and exclude-bsf actually did exclude all code 
depending on javax.servlet and bsf (unless it is no longer possible to 
build BeanShell without those dependencies)

and if

b) there was some INSTALL/BUILD documentation which at the very least 
listed the requirements for building BeanShell.  Maybe I'm just missing 
something, but I couldn't find any such documentation either in the 
files downloaded via CVS or on the BeanShell.org or 
beanshell.sourceforge.net sites.

David

-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: javax.servlet does exist (builiding with J2SE)

David C. Fox wrote:

> However, now I'm getting similar errors:
> 
>     [javac] 
> H:\Projects\BeanShell\BeanShell\bsf\src\bsh\util\BeanShellBSFEngine.java:13: 
> package com.ibm.bsf does not exist
>     [javac] import com.ibm.bsf.*;
>     [javac] ^
> 
> related to the BSF package.  Again, setting exclude-bsf didn't seem to 
> help, so I located BSF, downloaded and installed the binary of bsf-2.2, 
> added bsf.jar to my CLASSPATH.  Unfortunately, this doesn't seem to 
> help.  Maybe I need the source distribution of BSF, which I'll try next.

Oops.  This last bit was due to my stupid error: I had a typo in my 
CLASSPATH to bsf.jar.  Sorry to bother the list.

David

-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en