Strategy for object reusing
I am parsing thousands of XMLs and loading data in my application. Can anyone suggest tested strategy to reuse objects.
I have to generate java source files from XSD using Castor and then load data from castor generated classes to my other classes. I wont be able to replace my classes with castor generated classes.
In above scenarios the memory and time taken in object creation is haunting me as there will be thousands of XMLs coming in and for every request whole lot of objects will be created. Once data is loaded in my classes then castor objects will become eligible for garbage collection
If any one has tried using object pools and reusing the objects, please let me know. I want to avoid reinventing wheel. Writing a method in each and every class to refresh the instance is very painful.
If any one has tried using object pools and reusing the objects, please let me know. I want to avoid reinventing wheel. Writing a method in each and every class to refresh the instance is very painful.
Yes, it was one of the primary original justifications for stateless session beans (EJB's). Long since discredited.
However, if you do need object pooling, you can download Jakarta Commons Pool. It is a fully fledged object pool with multiple configuration options. It is also the pool that implicitly powers the DBCP (database connection pool) also released by Jakarta.
- Saish
Saisha at 2007-7-16 23:34:50 >
>
I am parsing thousands of XMLs and loading data in
> my application. Can anyone suggest tested strategy
> to reuse objects.
>
>
I have to generate java source files from XSD
> using Castor and then load data from castor generated
> classes to my other classes. I wont be able to
> replace my classes with castor generated classes.
>
>
In above scenarios the memory and time taken in
> object creation is haunting me as there will be
> thousands of XMLs coming in and for every request
> whole lot of objects will be created. Once data is
> loaded in my classes then castor objects will become
> eligible for garbage collection
>
>
If any one has tried using object pools and
> reusing the objects, please let me know. I want to
> avoid reinventing wheel. Writing a method in each and
> every class to refresh the instance is very
> painful.
If the Objects are short-lived, the cost of GC is not going to be that high. An Object pool using the concurrent libraries available in 1.5 will probably do better but there is a catch.
In 1.6 there is a planned enhancement to HotSpot to implement 'escape analysis' in the JIT. What this will do is if a reference to an Object can never escape the stack, the Object will be allocated on the Stack instead of the Heap. This eliminates the need for garbage collection entirely for such Objects.
I would seriously check your assumptions before you attempt to optimize this. The cost of IO is likely to completely overwhelm the cost of creating and reclaiming Objects. Use a modern VM (1.4, or 1.5) and try different VM options and mostly test to make sure this is going to be an issue.
http://blogs.sun.com/roller/resources/watt/jvm-options-list.html
> What this will do is if a reference to an Object can never escape the stack, the Object will be allocated on the Stack instead of the Heap. This eliminates the need for garbage collection entirely for such Objects.
How would it detect this? I always wondered if a Singleton would ever be garbage collected (my assumption is no as the reference to itself is static and final). Interesting stuff!
- Saish
Saisha at 2007-7-16 23:34:50 >
> How would it detect this?
Here's where I found out about this:
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
There's a paper that descibes it in detail (a little to academic for my tastes) referenced in the paper. The pictures in the paper pretty much tell the whole story.
In short, he Vm looks at a variable declared on the stack. If that variable is never passed to an Object on the heap or to a class i.e. the reference is never passed outside of the stack, the variable is said to not escape the stack. If the stack passes the reference to another method, the othe method can be examined to determine whether the reference escapes that. This is done recursively and whole methods can be marked 'not escape'. If a method only calls not escape methods and does not have any escapes itself, it's marked 'not-esacpe'.
They also do it for threads in order to strip synchronization overhead and there's a third type. I forget what. it wasn't as interesting.
> I always wondered if a
> Singleton would ever be garbage collected (my
> assumption is no as the reference to itself is static
> and final). Interesting stuff!
I don't think it's possible without unloading the class from the VM. I think whether this is possible is VM dependent. I'm not sure where the class data is stored but the class data is reachable from the root set of references. I know from experience that one of the problems with using a Singleton in an application container with hot deploy is that the old Singleton doesn't go away when the class is reloaded.
In short, he Vm looks at a variable declared on the stack. If that variable is never passed to an Object on the heap or to a class i.e. the reference is never passed outside of the stack, the variable is said to not escape the stack. If the stack passes the reference to another method, the othe method can be examined to determine whether the reference escapes that. This is done recursively and whole methods can be marked 'not escape'. If a method only calls not escape methods and does not have any escapes itself, it's marked 'not-esacpe'.
Interesting. Presumably, that should significantly reduce garbage collection overhead for those objects (as it will not occur any more). Each release, it seems Java borrows a bit more from C++.
- Saish
Saisha at 2007-7-16 23:34:50 >
> Interesting. Presumably, that should significantly
> reduce garbage collection overhead for those objects
> (as it will not occur any more). Each release, it
> seems Java borrows a bit more from C++.
I don't really see that being the case. C++ allows stack based allocation but you have to tell it to do so, from what I understand. This is just another optimization in the JIT. Stack-based allocation is faster and I don't think it's specific to C++.
Guess that is my own impression. Any time I hear 'stack' or 'heap', I think of C.:^)- Saish
Saisha at 2007-7-16 23:34:50 >
> Guess that is my own impression. Any time I hear
> 'stack' or 'heap', I think of C.
Well there's no doubt that Java has borrowed heavily from C/C++ but I don't think this addition makes Java more like C++. It actually might make Java able to outperform explicit memory mangement.
I would also imply that developers should try to limit the scope of their Objects as much as possible (reasonable).
> Well there's no doubt that Java has borrowed heavily
> from C/C++ but I don't think this addition makes Java
> more like C++. It actually might make Java able to
> outperform explicit memory mangement.
>
Now *that* would be turning the tables around for a change.I await with baited breath.
> I would also imply that developers should try to
> limit the scope of their Objects as much as possible
> (reasonable).
Probably a good goal even before Mustang. Even without discussions of garbage collection or memory management. Why allow an object to persist if it is no longer needed?
- Saish
Saisha at 2007-7-16 23:34:50 >
> Probably a good goal even before Mustang. Even
> without discussions of garbage collection or memory
> management. Why allow an object to persist if it is
> no longer needed?
Yes, for sure. But before we could only make fuzzy aguments based on theory. Now there's a concrete reason.
If JDK 6 will have performance improvements that significant, perhaps they should call it Ferrari rather than Mustang. (Though being from Detroit, I am partial to the muscle cars as well). :^)- Saish
Saisha at 2007-7-16 23:34:50 >
