On Friday 04 August 2006 15:32, Guilhem Lavaux wrote:
Dalibor pointed me to this thread on harmony-dev. I can answer that kaffe
does not yet make a difference between weak references and soft references.
They are both cleared when the GC detects that the object is not anymore
strongly
On Tuesday 01 August 2006 01:53 Alex Blewitt wrote:
On 31/07/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Alex Blewitt wrote:
Don't get me wrong; being able to specify minimum/maximum is a
reasonable idea for optimising a VM if you know what to put; but by
default, there shouldn't be
On 8/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
There is a method Runtime.freeMemory() which returns the memory available in
the heap. I wonder what it should return when there is no limit.
Some applications may rely on the value which this method returns. Just
returning Long.MAX_VALUE
On Tue, Aug 01, 2006 at 10:39:03PM +0800, Xiao-Feng Li wrote:
On 8/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
There is a method Runtime.freeMemory() which returns the memory available
in
the heap. I wonder what it should return when there is no limit.
Some applications may rely on
How did Kaffe deal with SoftReferences? Did they ever go away when you
did not have a memory limit?
Dalibor Topic wrote:
On Tue, Aug 01, 2006 at 10:39:03PM +0800, Xiao-Feng Li wrote:
On 8/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
There is a method Runtime.freeMemory() which
On Tuesday 01 August 2006 18:07, will pugh wrote:
How did Kaffe deal with SoftReferences? Did they ever go away when you
did not have a memory limit?
Why are we discussing Kaffe in the past tense?
--
Chris Gray/k/ Embedded Java Solutions BE0503765045
Embedded Mobile Java, OSGi
-Original Message-
From: Chris Gray [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 3:16 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [rant] Memory options in VM -- why is the
default not 'unlimited'
On Tuesday 01 August 2006 18:07, will pugh wrote:
How did
Yes. I apologize. I stated it in the past because the issue was
resolved in the past. More precise english probably would have been either:
How did Kaffe decide to deal with SoftReferences?
or
How does Kaffe deal with SoftReferences?
Although, still interested in the answer to either of
What does matter is whether you are using more virtual memory than you
have physical memory. The second you get in a spot where you have to GC
and go through the entire object tree, you need to load in every page.
If you have space for N pages in memory, and have objects allocated on
N+1
On 31/07/06, will pugh [EMAIL PROTECTED] wrote:
What does matter is whether you are using more virtual memory than you
have physical memory.
I agree completely. But the VM developer (in C) does not know how much
memory I have present. Why should it assume 256m? I have more memory
than that on
Alex Blewitt wrote:
Don't get me wrong; being able to specify minimum/maximum is a
reasonable idea for optimising a VM if you know what to put; but by
default, there shouldn't be any arbitrary limitations based on the
value of a #define constant ...
So, would you be satisfied if the VM
On 31/07/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Alex Blewitt wrote:
Don't get me wrong; being able to specify minimum/maximum is a
reasonable idea for optimising a VM if you know what to put; but by
default, there shouldn't be any arbitrary limitations based on the
value of a #define
On 8/1/06, Alex Blewitt [EMAIL PROTECTED] wrote:
The zones strategy you suggest may work well with apps that have a lot
of class loaders and allocate somewhat evenly across them, but I think
it may cause a lot of overhead. Would your approach be generational?
Would you need Write Barriers
As we see with -Xmx unlimit we have a lot of new issues that are not clear
right now.
IMO the best solution to make them clear is to support this option (but not
default) and to have an experience.
I'll try to summarize the problems stated above:
1) It's unclear for GC when to collect or when to
* Xiao-Feng Li:
1. the GC design usually hopes to have continuous memory space. The
dynamic heap increase and decrease may have difficulty to interact
with OS so as to keep the GC heap continuous.
At least on Linux, you can mmap with PROT_NONE to reserve an address
range, and later populate
Agree that maximum size is still desirable for system stability
reason. :-) ( I hope the OS MM can be more intelligent to deal with
overcommitment.) But here in this specific discussion context, I
think the word `unlimit' or `infinite' is meaning `unlimit under
certain limit'. Whatever the
On 30/07/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Alex, you made good point. It is definitely possible to design GC with
dynamic heap size, we will need is careful design for both convenience
and performance. Besides the points I mentioned previously,
performance tradeoff with heap size is yet
On 30/07/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Agree that maximum size is still desirable for system stability
reason. :-) ( I hope the OS MM can be more intelligent to deal with
overcommitment.) But here in this specific discussion context, I
think the word `unlimit' or `infinite' is
El dom, 30-07-2006 a las 00:16 +0100, Alex Blewitt escribió:
(...)
However, if the GC is generational, why does it need to be contiguous?
Some (most?) implementations of write barriers for generational GC
assume that all old memory is below or above all nurseries, so that the
old-new test can
On 7/31/06, Santiago Gala [EMAIL PROTECTED] wrote:
El dom, 30-07-2006 a las 00:16 +0100, Alex Blewitt escribió:
(...)
However, if the GC is generational, why does it need to be contiguous?
Some (most?) implementations of write barriers for generational GC
assume that all old memory is below
Isn't Full GCs a big problem? If have a bunch of pages in virtual
memory, and need to do a full heap walk. Won't you basically have an
exercise in page faults?
If you never do a full GC, aren't you going to potentially leak memory
forever, and potentially get super fragmentation in the
On 30/07/06, will pugh [EMAIL PROTECTED] wrote:
Isn't Full GCs a big problem? If have a bunch of pages in virtual
memory, and need to do a full heap walk. Won't you basically have an
exercise in page faults?
Realistically, doesn't that happen for any full GC though, regardless
of how they're
I believe this might be of general interest and worth debating here,
from a post on EclipseZone:
http://www.eclipsezone.com/eclipse/forums/t77021.html#92035043
Am I the only one that's frustrated that:
1) The -X options even exist at all. After all, they're so standard
now (e.g. -Xmx256m) that
This makes much sense to me, Alex, I mean a dynamic heap size. In my
understanding, there are following reasons to explain current hard
limit status:
1. the GC design usually hopes to have continuous memory space. The
dynamic heap increase and decrease may have difficulty to interact
with OS so
Alex Blewitt wrote:
1) The -X options even exist at all. After all, they're so standard
now (e.g. -Xmx256m) that the point of calling them 'non-standard'
options is pretty much laughable.
I agree that -Xmx and -Xms are de facto standard now.
I have also seen some java implementation long ago
On 29/07/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
3) That it's necessary to put limits on a system that uses garbage
collection and should be able to release memory back to the OS at all?
This point is quite moot.
Most existing JVMs have sensible defaults,
In DRLVM, I plan to do something
Salikh Zakirov wrote:
Alex Blewitt wrote:
But the point is, this is a hardcoded default maximum of 256m for no
particularly good reason. Why should it not be infinity?
The following patch does what you are asking for (untested).
Sorry, the first version would lead to integer overflow and
Salikh Zakirov wrote:
Sorry, the first version would lead to integer overflow and the to assertion
failure. The updated patch should work. It runs Hello on Windows/ia32 with a
warning
about reducing maximum heap size to the virtual address range it could
allocate.
This is done because GC
On 29/07/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Salikh Zakirov wrote:
Sorry, the first version would lead to integer overflow and the to assertion
failure. The updated patch should work. It runs Hello on Windows/ia32 with a
warning
about reducing maximum heap size to the virtual address
Alex, you made good point. It is definitely possible to design GC with
dynamic heap size, we will need is careful design for both convenience
and performance. Besides the points I mentioned previously,
performance tradeoff with heap size is yet another a factor. On one
hand, the heap size has a
30 matches
Mail list logo
