This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Jacks, gij and the GC

From: Bryce McKinlay <mckinlay at redhat dot com>
To: Ranjit Mathew <rmathew at gmail dot com>
Cc: java at gcc dot gnu dot org
Date: Thu, 22 Apr 2004 11:41:45 -0400
Subject: Re: Jacks, gij and the GC
References: <c686ne$96e$1@sea.gmane.org>

Ranjit Mathew wrote:

Anyways, to cut a long story short, I have
these questions:
1. Doesn't anyone else see this behaviour on Linux?

2. Why should the GC print out the "GC Warning" if we are throwing an OutOfMemoryError anyway?

It shouldn't. I think we should be able to fix things so that an OutOfMemoryError gets thrown correctly, if you have set a maximum heap size. Like Andrew says, its harder to get things right when the heap is unbounded. I suspect the kernel should probably end up killing your app before virtual memory is really exhausted.

4. Is there an option corresponding to "-mx" to limit the heap size for natively compiled executables?

There is the GC_MAXIMUM_HEAP_SIZE environment variable. However one thing I want to add is a GCJ_ARGS environment variable so that you can specify runtime arguments when running a gcj compiled application in a similar way to what you'd do when running gij. For example:

GCJ_ARGS="-mx=64m" ./mygcjapp

Regards

Bryce.

Follow-Ups:
- Re: Jacks, gij and the GC
  - From: Christopher Marshall

References:
- Jacks, gij and the GC
  - From: Ranjit Mathew

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]