You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by David Blevins <da...@visi.com> on 2010/12/03 00:39:02 UTC
Re: Possible static elimination
On Aug 29, 2010, at 10:34 PM, David Blevins wrote:
>
> On Aug 29, 2010, at 9:45 PM, Mark Struberg wrote:
>
>> Yes David. As posted in some Jira issue I'd like to aim for moving all those
>> little helper classes as members to BeanManager and giving them a back reference
>> to 'their' BeanManager. So all the 'helpers' can accessed via e.g.
>> bm.getDefinitionUtil(); and definitionUtil can easily access the BeanManager via
>> the back reference it got with the constructer as bm.
>>
>> This way we would be able to keep utils which are perfectly pre-configured for
>> each webapp and additionally eliminate most of the unnecessary calls.
>>
>> wdyt?
>
> Count me in for helping with that :) Would be a fantastic change.
>
>> Oh yea, all work on this will be done after -alpha-2 of course ;)
>
> Anxiously waiting :)
Picking this thread up again as I see there's renewed interest in taking this on (i.e. Mark's weekend task :)
Created a JIRA for us: https://issues.apache.org/jira/browse/OWB-503. Didn't bother assigning it to myself as it's not really a one person task -- we could all hammer on it.
Checked in a little something to get us going. Basically just attempting to strongly type that second hashmap. I'm a big fan of incremental refactoring and this seemed like a nice baby-step that didn't require us to break the existing WebBeansFinder API, yet still get moving on going where we want to go.
It may turn out we want to keep some API like the finder. We have a few statics in OpenEJB. Sometimes that's the more pragmatic design choice.
Anyway, as usual, changing anything you like.
Will continue hacking on it for the remainder of the week. Won't be hacking on it in the weekend (wedding anniversary this saturday), so Mark can hack all he wants without fear of bumping into me :)
-David
Re: Possible static elimination
Posted by David Blevins <da...@visi.com>.
On Jan 20, 2011, at 10:40 AM, Mark Struberg wrote:
> Btw,...
>
>
> ... a biiig thanks for your work on this topic! Really great stuff!
No problem. It's been fun.
> And also to djencks for the integration stuff and TCK work!
Thanks to Gurkan as well. It pretty much started with him, went to me and then to David.
Thanks for the help getting the standalone TCK running. Our regular build was down to about 11 static calls per test with a total of about 4000~. With the TCK enabled I have some new targets:
OWB-503 status: 524 code uses
Total of 7756 static synchronized accesses and 8941 hashed calls in 898 tests
Average of 8 static synchronized accesses and 9 hashed calls per test
mingus:~/work/jcdi/openwebbeans 05:17:32
$ bash usage.sh
1 org.apache.webbeans.event.EventImpl
2 org.apache.webbeans.conversation.ConversationImpl
2 org.apache.webbeans.el.ELContextStore
4 org.apache.webbeans.intercept.InterceptorComparator
15 org.apache.webbeans.test.tck.ContextsImpl
17 org.apache.webbeans.config.WebBeansContext
17 org.apache.webbeans.el.WebBeansELResolver
44 org.apache.webbeans.ejb.component.OpenEjbBean
47 org.apache.webbeans.xml.XMLUtil
79 org.apache.webbeans.util.AnnotationUtil
86 org.apache.webbeans.container.InjectableBeanManager
271 org.apache.webbeans.lifecycle.AbstractLifeCycle
381 org.apache.webbeans.test.mock.MockManager
384 org.apache.webbeans.test.tck.StandaloneContainersImpl$2
577 org.apache.webbeans.test.tck.StandaloneContainersImpl
1024 org.apache.webbeans.xml.WebBeansXMLConfigurator
2214 org.apache.webbeans.config.EJBWebBeansConfigurator
The above is the build with the standalone TCK enabled (mvn clean install -Ptck).
-David
Re: Possible static elimination
Posted by Mark Struberg <st...@yahoo.de>.
Btw,...
... a biiig thanks for your work on this topic! Really great stuff!
And also to djencks for the integration stuff and TCK work!
LieGrue,
strub
--- On Thu, 1/20/11, David Blevins <da...@gmail.com> wrote:
> From: David Blevins <da...@gmail.com>
> Subject: Re: Possible static elimination
> To: dev@openwebbeans.apache.org
> Date: Thursday, January 20, 2011, 4:58 AM
> Ok, we're getting down to the last
> bits. Here are the remaining
> non-test references:
>
> 1
> org.apache.webbeans.context.SessionContext
> 1
> org.apache.webbeans.context.creational.DependentCreationalContext
> 1
> org.apache.webbeans.inject.impl.InjectionPointImpl
> 1
> org.apache.webbeans.intercept.InterceptorHandler
> 3
> org.apache.webbeans.conversation.ConversationImpl
> 3
> org.apache.webbeans.test.tck.StandaloneContainersImpl
> 4
> org.apache.webbeans.container.SerializableBean
> 47 org.apache.webbeans.xml.XMLUtil
> 57 org.apache.webbeans.util.AnnotationUtil
> 80 org.apache.webbeans.lifecycle.AbstractLifeCycle
> 123
> org.apache.webbeans.context.creational.CreationalContextImpl
> 184 org.apache.webbeans.inject.instance.InstanceImpl
> 384 org.apache.webbeans.test.mock.MockManager
> 431 org.apache.webbeans.config.ManagedBeanConfigurator
> 500 org.apache.webbeans.el.WebBeansELResolver
> 551 org.apache.webbeans.intercept.InterceptorUtil
> 594 org.apache.webbeans.xml.WebBeansXMLConfigurator
>
> Some of the above are true static references that can't be
> removed
> (serialization), mostly the ones with 1 or 4 hits.
>
> Our stats:
>
> OWB-503 status: 550 code uses
> Total of 5535 static synchronized accesses and 5958
> hashed calls in 340 tests
> Average of 16 static synchronized accesses and 17
> hashed calls per test
>
> Will keep hacking but the end is in sight!
>
>
> -David
>
Re: Possible static elimination
Posted by Mark Struberg <st...@yahoo.de>.
on my list for 1.1 is to remove ALL the old XML stuff. This really is completely outdated and shall be dropped. So out of my head you can really ignore WebBeansXMLConfigurator. The InterceptorUtil is a really good candidate, because this will also get invoked millions of times at runtime. Our performance might really heavily benefit from this change.
LieGrue,
strub
--- On Thu, 1/20/11, David Blevins <da...@gmail.com> wrote:
> From: David Blevins <da...@gmail.com>
> Subject: Re: Possible static elimination
> To: dev@openwebbeans.apache.org
> Date: Thursday, January 20, 2011, 4:58 AM
> Ok, we're getting down to the last
> bits. Here are the remaining
> non-test references:
>
> 1
> org.apache.webbeans.context.SessionContext
> 1
> org.apache.webbeans.context.creational.DependentCreationalContext
> 1
> org.apache.webbeans.inject.impl.InjectionPointImpl
> 1
> org.apache.webbeans.intercept.InterceptorHandler
> 3
> org.apache.webbeans.conversation.ConversationImpl
> 3
> org.apache.webbeans.test.tck.StandaloneContainersImpl
> 4
> org.apache.webbeans.container.SerializableBean
> 47 org.apache.webbeans.xml.XMLUtil
> 57 org.apache.webbeans.util.AnnotationUtil
> 80 org.apache.webbeans.lifecycle.AbstractLifeCycle
> 123
> org.apache.webbeans.context.creational.CreationalContextImpl
> 184 org.apache.webbeans.inject.instance.InstanceImpl
> 384 org.apache.webbeans.test.mock.MockManager
> 431 org.apache.webbeans.config.ManagedBeanConfigurator
> 500 org.apache.webbeans.el.WebBeansELResolver
> 551 org.apache.webbeans.intercept.InterceptorUtil
> 594 org.apache.webbeans.xml.WebBeansXMLConfigurator
>
> Some of the above are true static references that can't be
> removed
> (serialization), mostly the ones with 1 or 4 hits.
>
> Our stats:
>
> OWB-503 status: 550 code uses
> Total of 5535 static synchronized accesses and 5958
> hashed calls in 340 tests
> Average of 16 static synchronized accesses and 17
> hashed calls per test
>
> Will keep hacking but the end is in sight!
>
>
> -David
>
Re: Possible static elimination
Posted by David Blevins <da...@gmail.com>.
Ok, we're getting down to the last bits. Here are the remaining
non-test references:
1 org.apache.webbeans.context.SessionContext
1 org.apache.webbeans.context.creational.DependentCreationalContext
1 org.apache.webbeans.inject.impl.InjectionPointImpl
1 org.apache.webbeans.intercept.InterceptorHandler
3 org.apache.webbeans.conversation.ConversationImpl
3 org.apache.webbeans.test.tck.StandaloneContainersImpl
4 org.apache.webbeans.container.SerializableBean
47 org.apache.webbeans.xml.XMLUtil
57 org.apache.webbeans.util.AnnotationUtil
80 org.apache.webbeans.lifecycle.AbstractLifeCycle
123 org.apache.webbeans.context.creational.CreationalContextImpl
184 org.apache.webbeans.inject.instance.InstanceImpl
384 org.apache.webbeans.test.mock.MockManager
431 org.apache.webbeans.config.ManagedBeanConfigurator
500 org.apache.webbeans.el.WebBeansELResolver
551 org.apache.webbeans.intercept.InterceptorUtil
594 org.apache.webbeans.xml.WebBeansXMLConfigurator
Some of the above are true static references that can't be removed
(serialization), mostly the ones with 1 or 4 hits.
Our stats:
OWB-503 status: 550 code uses
Total of 5535 static synchronized accesses and 5958 hashed calls in 340 tests
Average of 16 static synchronized accesses and 17 hashed calls per test
Will keep hacking but the end is in sight!
-David
Re: Possible static elimination
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
David,
Thank you for great work!
--Gurkan
----- Original Message ----
From: David Blevins <da...@visi.com>
To: dev@openwebbeans.apache.org
Sent: Wed, December 8, 2010 2:05:52 AM
Subject: Re: Possible static elimination
On Thu, Dec 2, 2010 at 3:39 PM, David Blevins <da...@visi.com> wrote:
>
> Basically just attempting to strongly type that second hashmap. I'm a big fan
>of incremental refactoring and this seemed like a nice baby-step that didn't
>require us to break the existing WebBeansFinder API, yet still get moving on
>going where we want to go.
Ok, here's where we are overall. Had mentioned in one of my commits
we were near half the number of hash lookups. That was really just
tracking that second hashmap lookup.
Overall we still have a bit of work to do:
r1041633 (the start)
-----------------------------
554 code uses
Total of 265183 static synchronized accesses and 530365 hashed gets in 340 tests
Average of 779 static synchronized accesses and 1559 hashed calls per test
r1043210 (today)
-----------------------------
563 code uses
Total of 263643 static synchronized accesses and 331125 hashed gets in 340 tests
Average of 775 static synchronized accesses and 973 hashed calls per test
The "static synchronized accesses" are calls to
WebBeansFinder.getSingletonInstance. For the DefaultSingletonService
these are statically synchronized, meaning only one thread per vm can
make the call. This is probably where we are losing our performance
as so many calls to BeanManager.getManager(), etc., all cause
contention with every other thread in the vm. Something we wouldn't
notice in a build environment, but definitely at production when there
are many users threads executing all at once.
What will affect that '775' number the most is consolidating calls to
'WebBeansContext.getInstance()' which is now the inlined version of
all the previously existing 'getManager()' and 'getInstance()' calls.
Here are our top 20 code usages of that method:
35 WebBeansUtil
27 BeansDeployer
13 WebBeansXMLConfigurator
9 TestContext
9 OpenWebBeansEjbInterceptor
7 AbstractLifeCycle
6 XMLDefinitionTest
6 InterceptorHandler
6 InjectionPointFactory
6 EjbBeanProxyHandler
6 BeanManagerImpl
5 WebBeansDecoratorConfig
5 WebBeansAnnotatedTypeUtil
5 StandaloneContainersImpl
5 LoggerSpecializationTest
4 XMLUtil
4 WebBeansInterceptorConfig
4 WebBeansInterceptor
4 ServiceLoader
4 ObserverMethodImpl
Runtime usage is likely to show some different numbers as some of
these classes are used less frequently or not at all after deployment.
For example BeansDeployer is #2 in the usage list, but really
wouldn't contribute anything to the runtime hits past deployment.
Anyway, as you dig through the code, feel encouraged to eliminate
duplicate WebBeansContext.getInstance() calls you encounter. Will be
a long process trimming those down but the biggest impact on
performance.
Meanwhile I'm going to try and get some runtime usage stats to see
what paths trigger the most hits so we can hopefully do some more
quick refactors that lead to the most benefit. I.e. looking for more
low hanging fruit we can easily pick.
-David
Re: Possible static elimination
Posted by David Blevins <da...@visi.com>.
On Thu, Dec 2, 2010 at 3:39 PM, David Blevins <da...@visi.com> wrote:
>
> Basically just attempting to strongly type that second hashmap. I'm a big fan of incremental refactoring and this seemed like a nice baby-step that didn't require us to break the existing WebBeansFinder API, yet still get moving on going where we want to go.
Ok, here's where we are overall. Had mentioned in one of my commits
we were near half the number of hash lookups. That was really just
tracking that second hashmap lookup.
Overall we still have a bit of work to do:
r1041633 (the start)
-----------------------------
554 code uses
Total of 265183 static synchronized accesses and 530365 hashed gets in 340 tests
Average of 779 static synchronized accesses and 1559 hashed calls per test
r1043210 (today)
-----------------------------
563 code uses
Total of 263643 static synchronized accesses and 331125 hashed gets in 340 tests
Average of 775 static synchronized accesses and 973 hashed calls per test
The "static synchronized accesses" are calls to
WebBeansFinder.getSingletonInstance. For the DefaultSingletonService
these are statically synchronized, meaning only one thread per vm can
make the call. This is probably where we are losing our performance
as so many calls to BeanManager.getManager(), etc., all cause
contention with every other thread in the vm. Something we wouldn't
notice in a build environment, but definitely at production when there
are many users threads executing all at once.
What will affect that '775' number the most is consolidating calls to
'WebBeansContext.getInstance()' which is now the inlined version of
all the previously existing 'getManager()' and 'getInstance()' calls.
Here are our top 20 code usages of that method:
35 WebBeansUtil
27 BeansDeployer
13 WebBeansXMLConfigurator
9 TestContext
9 OpenWebBeansEjbInterceptor
7 AbstractLifeCycle
6 XMLDefinitionTest
6 InterceptorHandler
6 InjectionPointFactory
6 EjbBeanProxyHandler
6 BeanManagerImpl
5 WebBeansDecoratorConfig
5 WebBeansAnnotatedTypeUtil
5 StandaloneContainersImpl
5 LoggerSpecializationTest
4 XMLUtil
4 WebBeansInterceptorConfig
4 WebBeansInterceptor
4 ServiceLoader
4 ObserverMethodImpl
Runtime usage is likely to show some different numbers as some of
these classes are used less frequently or not at all after deployment.
For example BeansDeployer is #2 in the usage list, but really
wouldn't contribute anything to the runtime hits past deployment.
Anyway, as you dig through the code, feel encouraged to eliminate
duplicate WebBeansContext.getInstance() calls you encounter. Will be
a long process trimming those down but the biggest impact on
performance.
Meanwhile I'm going to try and get some runtime usage stats to see
what paths trigger the most hits so we can hopefully do some more
quick refactors that lead to the most benefit. I.e. looking for more
low hanging fruit we can easily pick.
-David