did you look
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/reflect/NativeMethodAccessorImpl.java
?
seems this class usage/generation is not a simple try { loadClass() } catch
(...) { generate(); }
it is generated if it is often used (> 15 times by default if i didnt look
too quickly).
Custom accessors is probably the key.
- Romain
2012/2/27 David Blevins <[email protected]>
>
> On Sep 26, 2011, at 12:43 AM, David Blevins wrote:
>
> > # JAXB Accessors
> >
> > One of the biggest polluters of the class space is JAXB as it generates
> accessors for all the fields. First thought is, gee, I wonder if we can do
> that at build time and keep the class definitions. If there's some way we
> could write down those classes, it could save us a lot of trouble at
> runtime. We'd get a great speed boost on the cold start -- which is where
> unit test performance lives.
> >
> > A while back I did some perf testing of our OpenEJB 3.0 speed and JAXB
> was nearly half of the time it took to boot. We have a bigger JAXB tree
> than we did and that can easily account for a sliver of the slightly slower
> embedded speed.
> >
> > The classes exist, so there has to be some way to write them to disk
> even if there is no magical flag that will make the JAXB RI do it for us.
> Would be great to know if such a flag did exist. If someone is looking
> for a research problem, this would be a great one.
>
> Did some work on this. https://issues.apache.org/jira/browse/TOMEE-143
>
> With a JavaAgent, we monitor all classes created and their bytecode.
> Anything that is a "$JaxbAccessor" class is written to disk. The new
> openejb-jee-accessors module contains all these accessors.
>
> $ ls -lh target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar
> -rw-r--r-- 1 dblevins dblevins 596K Feb 26 15:48
> target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar
>
> $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | grep
> 'WebApp'
> 666 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_absoluteOrdering.class
> 608 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_contextParam.class
> 652 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_dataSource.class
> 610 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_distributable.class
> 654 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbLocalRef.class
> 644 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbRef.class
> 648 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_envEntry.class
> 602 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_errorPage.class
> 596 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_filter.class
> 610 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_filterMapping.class
> 640 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_icon.class
> 602 Sun Feb 26 15:48:22 PST 2012
> org/apache/openejb/jee/WebApp$JaxbAccessorF_jspConfig.class
> [....]
>
> $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | grep
> -c 'class$'
> 966
>
> Soo... all that and it doesn't seem to work :)
>
> mingus:~/openejb/examples 04:13:17
> $ for n in simple-stateless* ; do (cd $n && mvn clean install); done |
> egrep 'Time elapsed|JAXBContext'
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.918
> sec
> JAXBContext.newInstance 403 org.apache.openejb.jee.EjbJar
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.341
> sec
>
> I think we're darn close though.
>
> I'd like to shift gears and work on more classpath scanning performance
> boosts, if someone wants to pickup this task and see what we might have to
> do to get JAXB to see the classes we've generated, that'd be great.
>
> Could shave half a second or a second off of even a simple test.
>
>
> -David
>
>
