Skip to main content

Method Area keeps expanding.

6 replies [Last post]
Anonymous

Hi,

I evaluate the phoneME Advanced Software (CDC/FP only) on Linux.

In this software, Method Area for Class pool is separated from Heap Area
for Instance pool.
And, the Method Area keeps expanding until JavaVM is killed by Linux or
"ulimit" function.

So, I want to set the maximum size of Method Area like Heap Area.
Do you have any solutions ?

If the Method area is full, I want to notify Java Application of
java.lang.OutOfMemoryError.

Regards,
Kazuyuki Ito

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
xyzzy
Offline
Joined: 2006-08-30
Points: 0

Exceeding the limit set by ulimit should cause malloc to fail,
not kill the JVM. So you should be able to use this to prevent
the JVM from using more memory than you would like, but
you won't have fine-grained control over just the Method Area.
(I think you would want to use RLIMIT_DATA as defined by
setrlimit, not RLIMIT_AS, which will interfere with automatic
stack growth.)

Dean

> Hi,
>
> I evaluate the phoneME Advanced Software (CDC/FP
> only) on Linux.
>
> In this software, Method Area for Class pool is
> separated from Heap Area
> for Instance pool.
> And, the Method Area keeps expanding until JavaVM is
> killed by Linux or
> "ulimit" function.
>
> So, I want to set the maximum size of Method Area
> like Heap Area.
> Do you have any solutions ?
>
> If the Method area is full, I want to notify Java
> Application of
> java.lang.OutOfMemoryError.
>
> Regards,
> Kazuyuki Ito
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail:
> advanced-help@phoneme.dev.java.net

mlam
Offline
Joined: 2006-10-13
Points: 0

Hi Kazuyuki-san,

In order for us to give useful advice, it would be great if you could answer a few questions to help us understand what the problem is:

1. Which version of pMEA (phoneME Advanced) are you running?
2. What is the memory capacity of the device you're running pMEA on?
3. How much free memory was available before you started pMEA?
4. Does your device support swap space to secondary storage? If so, how much are you using and how much is available?
5. Please describe briefly what your Java application does, specifically its allocation and classloading profile.
6. How did you come to the conclusion that it is the "Method Area" that keeps expanding? What are you measuring as the "Method Area"?

Note that in pMEA, there is no official Method Area. Class meta data is simply allocated from the C heap via malloc. There is currently no limit on the usage of the C heap other than that which is set by the OS. Note that the VM isn't the only entity that allocates from the C heap. OS and other runtime libraries that the VM sits on top of could allocate such memory as well. The allocation usage of these libraries are beyond the control of the VM.

I find your question interesting because class data is not usually something that keeps expanding. So, I would like to understand your situation better in order to help figure out what is actually causing your problem.

Regards,
Mark

Kazuyuki.I@jp.yokogawa.com

Hi Mark,

Thank you for the quick answer.

> 1. Which version of pMEA (phoneME Advanced) are you running?

phoneME Advanced MR1
- Java ME CDC 1.1.1
- Foundation Profile 1.1

> 2. What is the memory capacity of the device you're running pMEA on?

64MB.

> 3. How much free memory was available before you started pMEA?

20MB

> 4. Does your device support swap space to secondary storage?
> If so, how much are you using and how much is available?

it doesn't support swap space.

> 5. Please describe briefly what your Java application does,
> specifically its allocation and classloading profile.

I created the test application for evaluating memory usage of JavaVM.
The application loads ten diffrent classes.
The file size of loading class is each 1MB.

> 6. How did you come to the conclusion that it is the "Method Area"
that keeps expanding?
> What are you measuring as the "Method Area"?

Operating System is Linux 2.6.10.
I confirmed it by using /proc/XXX/maps.
One address block kept expanding while the classes are loaded.
I called the block "Method Area".
As you say, it is a area for Class meta data.
Also, "calloc" was executed at CVMallocClassSpace() in classcreate.c .

I want to set the maximum size of the area for Class meta data
so that JavaVM should not terminate abnormally.
Java applications can't recognize the allocation usage.
So, If the area is full, I want to make JavaVM notify Java Application
of java.lang.OutOfMemoryError.

Regards,
Kazuyuki

> -----Original Message-----
> From: phonemeadvanced@mobileandembedded.org
> [mailto:phonemeadvanced@mobileandembedded.org]
> Sent: Thursday, June 14, 2007 4:28 PM
> To: advanced@phoneme.dev.java.net
> Subject: Re: Method Area keeps expanding.
>
> Hi Kazuyuki-san,
>
> In order for us to give useful advice, it would be great if
> you could answer a few questions to help us understand what
> the problem is:
>
> 1. Which version of pMEA (phoneME Advanced) are you running?
> 2. What is the memory capacity of the device you're running pMEA on?
> 3. How much free memory was available before you started pMEA?
> 4. Does your device support swap space to secondary storage?
> If so, how much are you using and how much is available?
> 5. Please describe briefly what your Java application does,
> specifically its allocation and classloading profile.
> 6. How did you come to the conclusion that it is the "Method
> Area" that keeps expanding? What are you measuring as the
> "Method Area"?
>
> Note that in pMEA, there is no official Method Area. Class
> meta data is simply allocated from the C heap via malloc.
> There is currently no limit on the usage of the C heap other
> than that which is set by the OS. Note that the VM isn't the
> only entity that allocates from the C heap. OS and other
> runtime libraries that the VM sits on top of could allocate
> such memory as well. The allocation usage of these libraries
> are beyond the control of the VM.
>
> I find your question interesting because class data is not
> usually something that keeps expanding. So, I would like to
> understand your situation better in order to help figure out
> what is actually causing your problem.
>
> Regards,
> Mark
> [Message sent by forum member 'mlam' (mlam)]
>
> http://forums.java.net/jive/thread.jspa?messageID=222065
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

mlam
Offline
Joined: 2006-10-13
Points: 0

Kazuyuki-san,

It sounds like you're trying to run the VM under conditions where there's not enough memory to run your application. A point to note: MR1 does not have an auto-resizing heap, MR2 does. Assuming you're running with default heap sizes and loading 10 unique Java classes about 1M in size each (or the same class in 10 separate classloaders and keeping all classes alive at the same time), I think the memory footprint you will incur will be close to 20M. It could be a bit more depending on internal fragmentation of the C heap and other factors. So, running out of memory is not unreasonable in this case.

I take it that you are trying to test how the pMEA VM responds to such a situation. Currently, the pMEA VM does not offer an explicit way to limit the amount of memory used for loading class data. The VM expects malloc() to return NULL (i.e. failed an allocation) when system memory is low or unavailable. In such cases, the VM will throw an OutOfMemoryError. If the OS chooses simply to terminate the VM instead, there is currently no simple recourse for this.

In the future, we may add this class data limit constraint feature to the pMEA VM. Alternatively, since this is an open source project, you're welcomed to add the feature yourself and contribute to the project. If you're interested, let me know, and I'll try to walk you through the steps of doing so (or ask a colleague to do so with you).

Regards,
Mark

Kazuyuki.I@jp.yokogawa.com

Hi Mark,

> It sounds like you're trying to run the VM under conditions
> where there's not enough memory to run your application.

It is not my purpose that the Java application can keep running on the
conditions.
This condition was set for the investigation about the class loading of
pMEA VM.

> In the future, we may add this class data limit constraint feature to
the pMEA VM.

I think that the feature is very important,
because a serious following problem is solved.

Java applications can load class data by using class loaders, whenever
necessary.
Also, the size of the class data depends on Java applications.
However, when pMEA VM kept unconditionally using C heap depending on an
application's demand,
other important applications on the same device receive the influence by
being not able to use C heap.
For example, other applications are the important system service
functions
which are implemented by native languages.

This feature can solve this serious problem,
because the limit for no influence on other important applications can
be set beforehand.
If a java application is beyond the limit, the application can catch an
OutOfMemoryError.
So, the java application can do necessary handling.
For example, the loaded class can be unloaded.

Therefore, in the devices which managed the memory resource in
premeditation, this feature is indispensable.
Similarly, I think that JNI developed by user is not suitable according
to situations in such devices.
It is difficult to control the memory usage of such JNI.

How do you think about what I mentioned on the above ?
I'd like to get your comment by all means.

> Alternatively, since this is an open
> source project, you're welcomed to add the feature yourself
> and contribute to the project. If you're interested, let me
> know, and I'll try to walk you through the steps of doing so
> (or ask a colleague to do so with you).

Thank you for your proposal.
I'll consider whether I do that or not.
I have a question.
To add the feature, a "src/share/javavm/" directory will be updated.
Generally, influences on java specification and differences with
licensee source code that Sun Microsystems manages
may occur by the update.
What policy about it does this open source project have ?

Regards,
Kazuyuki

> -----Original Message-----
> From: phonemeadvanced@mobileandembedded.org
> [mailto:phonemeadvanced@mobileandembedded.org]
> Sent: Friday, June 15, 2007 4:01 AM
> To: advanced@phoneme.dev.java.net
> Subject: Re: RE: Re: Method Area keeps expanding.
>
> Kazuyuki-san,
>
> It sounds like you're trying to run the VM under conditions
> where there's not enough memory to run your application. A
> point to note: MR1 does not have an auto-resizing heap, MR2
> does. Assuming you're running with default heap sizes and
> loading 10 unique Java classes about 1M in size each (or the
> same class in 10 separate classloaders and keeping all
> classes alive at the same time), I think the memory footprint
> you will incur will be close to 20M. It could be a bit more
> depending on internal fragmentation of the C heap and other
> factors. So, running out of memory is not unreasonable in this case.
>
> I take it that you are trying to test how the pMEA VM
> responds to such a situation. Currently, the pMEA VM does
> not offer an explicit way to limit the amount of memory used
> for loading class data. The VM expects malloc() to return
> NULL (i.e. failed an allocation) when system memory is low or
> unavailable. In such cases, the VM will throw an
> OutOfMemoryError. If the OS chooses simply to terminate the
> VM instead, there is currently no simple recourse for this.
>
> In the future, we may add this class data limit constraint
> feature to the pMEA VM. Alternatively, since this is an open
> source project, you're welcomed to add the feature yourself
> and contribute to the project. If you're interested, let me
> know, and I'll try to walk you through the steps of doing so
> (or ask a colleague to do so with you).
>
> Regards,
> Mark
> [Message sent by forum member 'mlam' (mlam)]
>
> http://forums.java.net/jive/thread.jspa?messageID=222235
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Hinkmond Wong

Hi Kazuyuki-san,

From Kazuyuki.I@jp.yokogawa.com:
>> Alternatively, since this is an open source project, you're welcomed
>> to add the feature yourself and contribute to the project. If you're
>> interested, let me know, and I'll try to walk you through the steps
>> of doing so (or ask a colleague to do so with you).
>
> Thank you for your proposal.
> I'll consider whether I do that or not.

Here is more info on making a contribution to the project:

Just follow these instructions to submit code to contribute to the project:
https://mobileandembedded.dev.java.net/content/contribute.html#submit

Before that, please also make sure to sign and return the following
contributor's form:
https://mobileandembedded.dev.java.net/content/sca.html

> I have a question.
> To add the feature, a "src/share/javavm/" directory will be updated.
> Generally, influences on java specification and differences with
> licensee source code that Sun Microsystems manages
> may occur by the update.
> What policy about it does this open source project have ?

Only code changes that do not adversely affect the TCK tests will be
accepted. Therefore, we ensure the compatibility with the existing Java
ME specifications, and there will be no differences with licensee source
code in terms of compatibility.

Hinkmond

> Regards,
> Kazuyuki
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net