harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] what's next?
Date Wed, 28 Jun 2006 18:12:36 GMT
On Wednesday 28 June 2006 21:05 Andrey Chernyshev wrote:
> (2) Handling out of C memory conditions
> VM must throw OutOfMemoryException when there is a lack of C memory.
> For example, if local or global handle cannot be allocated then OOME
> should be thrown � OutOfMemoryException must be thrown (this is
> required by JNI/JVMTI spec).

This is not really anywhere in JNI spec, but that is how RI behaves when 
NewGlobalRef or NewLocalRef cannot be executed because of lack of C heap. It 
is probably good to follow this behavior instead of crashing.

JVMTI spec requires returning JVMTI_ERROR_OUT_OF_MEMORY, not throwing an 
exception but this is a minor difference.

> (7) Unify C Memory management.
> Native memory is currently allocated in DRLVM by ~10 different means
> at different places. Some of examples are using APR memory pools, C
> mallocs, C++ new operator e.t.c. This complicates the communication
> between the different modules within DRLVM since there is no
> consideration how to deallocate the memory being allocated by other
> component and may trigger memory leaks in the system.
> I wonder if there could be any ideas how the memory management
> approach could be unified in the DRLVM? It may also help to monitor
> and eliminate possible memory leaks in the system.

I can share some interesting observation from my experience on this topic. 
I've analyzed a stress test when JNI functions mentioned above are used in 
stressed heap conditions, when no memory is available. To reach this result 
the test's native code used malloc until malloc returned NULL, then started 
to call NewLocalRef.

When running this test on JRockit on windows which doesn't gracefully handle 
such situation, it crashes and produces a crash analysis dump to the 
terminal. One of the lines in it stated that 1 malloc with 1000 (whatever was 
the size used for exhausing C heap) bytes has failed. I didn't try this test 
on linux.

This means that JRockit somehow replaced malloc used in Java native function 
of the test to register the condition that it has failed once. I wonder how 
it can be done. It would allow complete C heap memory management unification 
both for VM and Java native API and user code.

Gregory Shimansky, Intel Middleware Products Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message