optimizing introspection/reflection

[aloubyansky]

Ugly use of introspection/reflection API has been cleaned-up a bit. Plus, support for java.bean.BeanInfo has also been added.
I had to write another variation of 'FieldInfo', though very simple. And abstract out the way the property is written or read, i.e. using Field or Method.
We do need to promote the introspection API Adrian wrote.

Also, there is a new library dependency for XB which is oswego concurrent.jar.

PS: hasn't committed the changes yet because of svn authorization issues.

[heiko.braun]

Previously (using XercesXSMarshaller) the reflection wrapper have been cached in the MappinObjectModelProvider. This could eagerly be populated and reused throughout several Marshaller invocations. Especially the WS usecases did benefit from this, because otherwise the same classes would have been introspected over and over again.

When optimizing XB regarding the use of the reflection API, wouldn't it makes sense to extend the API that the callee could actually provide that mapping model, similar to what has been possible with the MappinObjectModelProvider?

IMO usecases that work on the same object model /schema would greatly benefit in terms of performance.

[aloubyansky]

Probably, you are right. But before going that way let's make sure we are not leaving behind more critical performance issues that should be addressed first. Why don't we come up with a series of most common use-cases (probably, you already have them), run the tests and identify the bottlenecks and their severity?

[bill.burke]

the biggest performance improvement would be the ability to serialize schema models to disk so that the XML wouldn't have to be parsed for the schema. A profiling run of E-EJB3 showed that schema parsing took 10% of boottime.

[aloubyansky]

That's true. However, for the next release I am just gonna do what the WS guys want...
In fact that may help them too. But I'll let them to decide.

[heiko.braun]

Well, after the last improvement (LinkedList->ArrayList), it became evident that creating the reflection wrapper (getter, setter, field access) is the biggest bottleneck. I did some quick prototype, similiar to what you did with ClassInfo and FieldInfo and it turned out that performance increased significantly.

IMO you are on the right way. Although i would suggest to cache this information per Marshaller/Unmarshaller instance and not statically/globally. This way we can additional synchronisation and it would still be possible for the callee to reuse particular instances per usecase.

[heiko.braun]

This way we can avoid additional synchronisation...

[heiko.braun]

Alex says:

I've added ClassInfos.disableCache(), enableCache(), isCacheEnabled(),
flushCache() and flushCache(String className) methods.
You can disable caching or flush it before running a test as part of setUp(), for example.

Does this work for you?

[heiko.braun]

This does still work on the static ConcurrentHashMap, right?

This will probably work for testing, but how do you want to prevent unexpected results in production? Basically everyone can enable/disable caching of XB all the time.

Plus there's a synchronization overhead and probably a memory leak when the map grows over time.

Why don't we associate ClassInfos with Marshaller/Unmarshaller instances?
ThreadLocal would be another option.

I think the suggested API works, but I am concerned about unwanted side effects due to this static member.

[aloubyansky]

heiko wrote:
Why don't we associate ClassInfos with Marshaller/Unmarshaller instances?

Makes sense to look into. But right now, we would have to use ThreadLocal's. Otherwise, changes in the public API would have to be done. Let's investigate this after the bugs are fixed.

In the mean time, static ConcurrentHashMap was replaced with synchronized WeakHashMap.