Was my analysis so the question is do we still need to capture them like it or can we use more simple setters/getters?
Note: the code i pasted in my previous email is the one which is generated from the injector. Ps: maybe i looked too fast but i didnt see jaxb-impl in tomee - Romain Le 28 févr. 2012 06:36, "David Blevins" <[email protected]> a écrit : > > On Feb 26, 2012, at 11:59 PM, Romain Manni-Bucau wrote: > > > 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). > > That's a deceptively similar, but unrelated bit of code. Those are for > the java.lang.reflect API. > > I grabbed the JAXB RI source and dug around (svn co > https://svn.java.net/svn/jaxb~version2/tags/jaxb-2_1_9). This appears to > be the mechanism it uses to determine if the class has already been > generated: > > > http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java?av=f#112 > > Basically a weak hashmap of classloaders and "Injector" instances where > each "Injector" holds a hashmap of classes that have been generated. > > Not sure how we get around it other than an AccessorFactory. > > > Custom accessors is probably the key. > > Perhaps one that just instantiates the generated Accessors we've captured. > > > -David > > > > > 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 > >> > >> > >
