Geir Magnusson Jr. wrote:
I am not sure that we need to do something about this. The default
initial
stack size on Windows is 1M,
Yikes! There's our problem on windows...
The same OOME is thrown on Linux as well, but I am not sure if it
happens because of reaching virtual space limit or because of some other
reason. I don't have a good process monitor for Linux to see the number
of running threads and virtual memory size.
and that is the recommended init size for real
applications. The fact that our threads start with a larger intial stack
mapped( default ) than RI is a design issue, it is not a bug. We could
start
with 2K and create many more threads!
That's right. The fact that the VM crashes and burns is the bug, and a
serious one, IMO.
We should not use this test ( which is not a
real app ) as guidance to tune the initial stack size. My suggestion
is to
lower the test duration so that we can create about a 1000( or whatever
magic number ) threads at least. That is the stress condition we
should test
for.
The big thing for me is ensuring that we can drive the VM to the limit,
and it maintains internal integrity, so applications that are designed
to gracefully deal with resource exhaustion can do so w/ confidence that
the VM isn't about to crumble out from underneath them.
I agree with Geir that we should try to handle out of C heap condition
gracefully. The problem is that there is no clearly defined contract for
many functions that use memory allocation about what to do in case of
out of memory condition.
To maintain integrity all VM functions which allocate memory from C heap
should return gracefully all the way up the stack until they hit Java
code that called them and then OOME exception shall be seen by the Java
code. It is not an easy task because all code paths should support it,
including JIT and GC.
--
Gregory
