On Thursday 13 January 2005 15:08, Artur Biesiadowski wrote: > Sascha Brawer wrote: > > I was just re-reading the FAQ [1] -- what would speak against > > pre-allocating thread-specific OutOfMemoryException objects when > > creating a thread? (Probably more a VM-specific thing, but since it's > > mentioned in the Classpath FAQ...) > > You have basically two choices with implementing OOME. You can go > stacktrace-less route (only throw it, do not provide entire stack trace > with it) - then you can get away with single instance per entire jvm, as > it has no state. Or you can try to fit stack in there - but place for it > has to be preallocated. Memory usage can start to sum up if you will > preallocate it for every thread out there. This looks like optimizing > for very rare case for me and making more garbage in the heap that it is > needed for all normal jvm runs.
This was my conclusion too in the end - the thread-specific OOME object with preallocated stack trace ties up a lot of memory without actually solving the problem. So either do nothing and let nature take its course, or have a truly lightweight solution which will allow the OOME to be thrown without a stack trace (could be as little as a 1-bit flag in the thread control block), > I'm not sure if danger of many threads throwing OOME at the same time is > really so big. Every sane jvm will trigger full gc before throwing OOME > - and to have full gc going, there has to be some kind of > synchronization on memory allocation between all threads [...] A VM with a mostly-concurrent GC might not conform to this model. Chris -- Chris Gray /k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 3 216 0369 Visit us at�Embedded World 2005 <http://www.embedded-world.de/> 22--24 Feb. 2005 at the N�rnberg Messe (Germany), booth 10-504 _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
