You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alex Blewitt <al...@gmail.com> on 2006/07/29 09:58:17 UTC
[rant] Memory options in VM -- why is the default not 'unlimited'
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 the point of calling them 'non-standard'
options is pretty much laughable.
2) That they felt the need to build another level of non-non-standard
into command line options such that -XX is even necessary
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?
I mean, what is the point in artificially limiting the size of these
anyway? I can see that there may be optimal tweaks that you'd want to
perform on some server systems (e.g. initial sizes) and maybe for some
constrained systems the maximal size too; but why isn't the default
'unlimited'? The only time I should see an OutOfMemoryError is when
the OS refuses to give any more memory to the app, not when some
artificial hard-coded limit is reached in some random defaults
hard-coded into a C file. Name one other language/system/application
that has such an arbitrary self-enforced maximal non-unlimited default
built in. Heck, even OS resources (like ulimit or #file handles) are
specified at the OS, not the application, level.
With any luck, open-source VMs like Harmony won't be as anal with
their memory management, and the default for such things will be
unlimited. Just one of the benefits of an open-source version; you
won't have to be artificially cramped by random decisions at the VM
level."
Alex.
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Alex Blewitt <al...@gmail.com>.
On 30/07/06, Xiao-Feng Li <xi...@gmail.com> 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 meaning `unlimit under
> certain limit'. Whatever the limit is can be defined by the clever OS
> (which returns a ENOMEM, for example) or user heuristics.
Infinite in a computer science, rather than mathematical sense :-)
For example, there may be practical reasons why 4Gb is the maximum (or
2Gb if signed pointers are used). But even if the OS has 512mb of
memory, and (say) 256m free, there's no reason to limit the amount of
memory that the JVM requests. The user will notice a slow-down in
performance as soon as the *practical* limit is transgressed, but
unless the user starts with a -Xmx option, the memory should be
'unlimited' in the 'largest amount of space that is possible'. Given
that most OSs have virtual memory, why should the JVM decide that it's
not going to use it?
I'd argue that if not specified, the limit should be unlimited in the
sense that the largest possible amount that the process can possible
acquire. If the user wants to limit the amount of memory to prevent
swapping, that's fine, but it has to be a user-supplied option and not
a JVM-enforced-default.
Let's face it, the only reason why -Xmx is used at all in almost all
JVMs is not to limit the amount of space, but rather a workaround
because the JVM gets it wrong.
Alex.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 limit is can be defined by the clever OS
(which returns a ENOMEM, for example) or user heuristics.
Thanks,
xiaofeng
On 7/30/06, Florian Weimer <fw...@deneb.enyo.de> wrote:
> * 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 it with backing storage with mprotect.
> (Initially, the reserved address space does not count against the
> reserved memory counter of the process.) Unfortunately, on 32-bit
> systems, the available address space will be somewhat fragmented, so
> you still need to support different regions.
>
> For robustness purposes, I fear you still need the maximum heap size
> on Linux, unless overcommitment is turned off (which is not the
> default). Otherwise, some process just dies (not necessarily the VM
> that has gone awry), which can have a huge impact on system stability.
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* 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 it with backing storage with mprotect.
(Initially, the reserved address space does not count against the
reserved memory counter of the process.) Unfortunately, on 32-bit
systems, the available address space will be somewhat fragmented, so
you still need to support different regions.
For robustness purposes, I fear you still need the maximum heap size
on Linux, unless overcommitment is turned off (which is not the
default). Otherwise, some process just dies (not necessarily the VM
that has gone awry), which can have a huge impact on system stability.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 as to keep the GC heap continuous.
2. there is an assumption that the JVM fully controls its heap of
given size, hoping they all resident in physical memory. The GC
algorithm sometimes requires full-heap walking, but doesn't want to
incur many page faults.
Basically these are because OS and JVM don't always cooperate
friendly. But this is changing. See links below for your reference
[1][2]. And I support to have a dynamic heap resizing in Harmony in
the future.
[1]http://www.bea.com/content/news_events/white_papers/BEA_JRockit_wp.pdf
[2]http://www.cs.umass.edu/~emery/pubs/automatic-heapsize-ismm2004.pdf
Thanks,
xiaofeng
On 7/29/06, Alex Blewitt <al...@gmail.com> wrote:
> 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 the point of calling them 'non-standard'
> options is pretty much laughable.
>
> 2) That they felt the need to build another level of non-non-standard
> into command line options such that -XX is even necessary
>
> 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?
> I mean, what is the point in artificially limiting the size of these
> anyway? I can see that there may be optimal tweaks that you'd want to
> perform on some server systems (e.g. initial sizes) and maybe for some
> constrained systems the maximal size too; but why isn't the default
> 'unlimited'? The only time I should see an OutOfMemoryError is when
> the OS refuses to give any more memory to the app, not when some
> artificial hard-coded limit is reached in some random defaults
> hard-coded into a C file. Name one other language/system/application
> that has such an arbitrary self-enforced maximal non-unlimited default
> built in. Heck, even OS resources (like ulimit or #file handles) are
> specified at the OS, not the application, level.
>
> With any luck, open-source VMs like Harmony won't be as anal with
> their memory management, and the default for such things will be
> unlimited. Just one of the benefits of an open-source version; you
> won't have to be artificially cramped by random decisions at the VM
> level."
>
> Alex.
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Mikhail Fursov <mi...@gmail.com>.
On 7/31/06, Santiago Gala <sg...@apache.org> 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 or above all nurseries, so that the
> old->new test can be done with a simple address comparison.
>
> So, while they are not fully contiguous, they make some assumptions on
> memory layout, even if it is just for efficiency.
>
> Testing if a pointer is inside any of a number of memory areas for each
> assignment is a fairly expensive operation.
>
Extra bit/byte in object header can solve this problem..
--
Mikhail Fursov
Re: Re: [rant] Memory options in VM -- why is the default not
'unlimited'
Posted by Santiago Gala <sg...@apache.org>.
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 be done with a simple address comparison.
So, while they are not fully contiguous, they make some assumptions on
memory layout, even if it is just for efficiency.
Testing if a pointer is inside any of a number of memory areas for each
assignment is a fairly expensive operation.
Regards
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Salikh Zakirov <Sa...@Intel.com>.
Alex Blewitt wrote:
> However, if the GC is generational, why does it need to be contiguous?
As far as I know, there are no theoretical obstacles in making GC heap
non-contiguous. The heap is created in contiguous address range mostly
because of practical reasons.
1) it is very convenient to be able to do assert(object >= heap_base && object < heap_ceiling)
2) a well-known design for heap traversal during garbage collection involves having so called
mark bit table, which has 1 bit for each potential object start location.
For example, in current DRLVM GC (called "GC v4"), objects are 4 bytes aligned, thus each
4-byte aligned address can potentially be a start of an object, and so has a corresponding
mark bit in the table.
To extend the mark bits techniques on non-contiguous heaps, one have to split the heap space
into 2^n byte blocks and allocate mark bit tables for each block.
GC v4 uses this techniques, with block size = 128k, and first 4k of the block keeping
the mark bit table. However, in case of GC v4, it has a design flaw.
It tries to organize the LOS (Large object space) uniformly with small object blocks, and has
large objects aligned at the block level. The objects larger than 1/2 of the block are considered
large. In the worst case, if the heap is filled with the objects of size about 1/2 of block,
more than 50% of the heap space is wasted for alignment.
I think that the space inefficiency can be fixed by introducing separate logic for handling
large objects, and aligning them to a smaller boundary, e.g. on a page size (4k).
---------------------------------------------------------------------
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
Re: Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Alex Blewitt <al...@gmail.com>.
On 30/07/06, Xiao-Feng Li <xi...@gmail.com> 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 another a factor. On one
> hand, the heap size has a minimal to keep all the live objects during
> the execution; on the other hand, a larger heap size trigers GC less
> frequently. So sometimes the GC needs to decide if it should increase
> the heap size or just trigger a collection, assuming the heap size is
> enough to hold all the live objects.
Yes, there are obvious conditions like this which need to be decided
:-) However, I'm sure that heuristics could play a part; if the GC
remembers what it did from the previous run/runs, then perhaps it
could guide what happens next. For example, if the last GC freed up
(say) less than 5% of memory, the next decision would be to request
more memory. Or, if a GC doesn't free up the requisite amount of
memory, then a request for more memory could follow on as part of the
same GC cycle.
I'm pretty sure that hashtables have a built-in load factor (about 70%
utilisation of buckets?) and that when the hashtable goes above the
load factor, it rehashes. Could we not have some kind of load factor
in the memory, such that a post-GC compaction triggers more memory
when the load factor goes above a certain percentage (e.g. 70%)?
Obviously, the numbers would have to be fine-tuned (or be subsituted
with another -XX:GCLoadFactor non-non-standard option ;-)
Of course, it's possible that this idea wouldn't work well at all ...
> Yes, to allocate/release blocks when needed is possible. I'd give you
> more cases that requires careful design. consider a case . For
> example, if the block is bigger than an OS page in size, even the GC
> design can perfectly allocate/release its blocks, the system memory is
> still fragmented.
I would assume that a VM block size would be a multiple of OS page
sizes, for obvious performance reasons, including the one that you
mention. I can't see there being any benefit in not doing so ... can
we determine what the OS page size is, either statically or
dynamically? For example, on Mac OS X the page size is 4k, as returned
by sysconf(_SC_PAGE_SIZE) in unistd.h ...
Perhaps 4k would be a bit small, so some multiple of those is probably
needed to round up the size. But some power-of-two multiple would
probably be useful; you could take the page size and <<1 until it was
bigger than a more reasonable number (e.g. 32k?)
> Another case is, GC sometimes needs to align the
> block to certain size boundary, which also leaves fragments in system
> space. Yet another case is, if the system memory space is already
> seriously fragmented, GC may not be able to utilize the remaining
> vacant space although the sum size of the fragments can be large.
Yes, all true. The same happens with filing systems, too. But note
that if the memory is already fragmented, asking the VM to start by
attempting to claim a large space on a heap is almost certainly
destined to fail. At least but having the memory split into blocks,
it's more likely that you'll be able to obtain memory space and/or use
it.
> Many of these point to OS/JVM interactions finally. I've been looking
> at this area. :-)
Cool :-) I'm just an ideas man, mostly -- my C background is pretty
slim, or else I'd like to help out. But I've still got to get the
Pack200 stuff up and running, first.
Speaking of ideas, I've often thought that allowing a VM to 'zone' out
pages of related code would be an excellent idea. For example, if each
ClassLoader had its own zone of pages, and that new instances of
classes owned by that ClassLoader were created in its zone, then
you'd have a way of partitioning the memory space without having to
change any Java code. So, instead of having a global memory space with
two or three generations, you'd have a set of them instead (perhaps
each with their own generations).
This would be great for J2EE servers that typically create their own
ClassLoaders, normally one per app. Furthermore, when the app is
stopped (and the ClassLoader unloaded) then all of the memory
'assigned to' that ClassLoader could be returned to the OS. It would
also mean that if a J2EE server had many apps, and not all of them
were being used, then the page(s) in the ClassLoader's zone could be
paged out, and they'd not be needed to be paged in again until the app
was requested.
Back to the file system analogy; instead of having a single filesystem
for all files (and the fragmentation that woudl go along with that),
it's like having a separate filesystem for each J2EE app so that the
app's files don't get mixed with each other.
I've often thought this would be a really cool thing to do. Does the
idea have any merit?
Alex.
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 8/1/06, Alex Blewitt <al...@gmail.com> 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 for both references from other generations
> > as well as other Class Loaders?
>
> I've no idea if it would cause a lot of overhead. It might do. I'd
> imagine that each zone would have a nursery and mature generation, but
> possibly share some permanent generation.
This is close to a GC for multitasking JVM. :-) It's too early to know
if the idea is well applicable to the dynamic heap resizing.
> > If you were to have a Web Application, would you basically need a write
> > barrier for every string you allocate, since the String Class is loaded
> > in a parent class loader? If so, this may cause more overhead than you
> > would want for the stated benefit.
>
> I suspect that if a write barrier was needed, this would quickly kill
> any of the efficiencies. Perhaps there would be some other
> optimisations that could avoid such things?
Write barrier doesn't necessarily kill any benefits. It's subject to
be measured if we have it implmented.
The basic idea I agree is, any hard limit is undesirable. It should be
dynamically adaptive according the system situation.
Thanks,
xiaofeng
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Chris Gray <ch...@kiffer.be>.
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 http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by will pugh <wi...@sourcelabs.com>.
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 <gs...@gmail.com> 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 may lead to confusion.
>>>
>>>
>>>
>>It can simply returns the freeMemory available to the Java object
>>allocation, if that's programmer wants.
>>
>>Basically I think this API is only for profiling hints purpose,
>>meaning it has no guarantee about the real memory situation. So it's
>>not recommended to program the application depending on its return
>>value.
>>
>>
>
>That's correct, afaict. Kaffe does not limit per default the amount of
>memory available, allowing the gc to grow the heap as necessary. That
>used to confuse some older Eclipse releases, but the bug has been fixed
>in Eclipse.
>
>cheers,
>dalibor topic
>
>
>
>>Thanks,
>>xiaofeng
>>
>>---------------------------------------------------------------------
>>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
>>
>>
>>
>
>---------------------------------------------------------------------
>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
>
>
>
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Dalibor Topic <ro...@kaffe.org>.
On Tue, Aug 01, 2006 at 10:39:03PM +0800, Xiao-Feng Li wrote:
> On 8/1/06, Gregory Shimansky <gs...@gmail.com> 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 may lead to confusion.
> >
>
> It can simply returns the freeMemory available to the Java object
> allocation, if that's programmer wants.
>
> Basically I think this API is only for profiling hints purpose,
> meaning it has no guarantee about the real memory situation. So it's
> not recommended to program the application depending on its return
> value.
That's correct, afaict. Kaffe does not limit per default the amount of
memory available, allowing the gc to grow the heap as necessary. That
used to confuse some older Eclipse releases, but the bug has been fixed
in Eclipse.
cheers,
dalibor topic
>
> Thanks,
> xiaofeng
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 8/1/06, Gregory Shimansky <gs...@gmail.com> 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 may lead to confusion.
>
It can simply returns the freeMemory available to the Java object
allocation, if that's programmer wants.
Basically I think this API is only for profiling hints purpose,
meaning it has no guarantee about the real memory situation. So it's
not recommended to program the application depending on its return
value.
Thanks,
xiaofeng
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Gregory Shimansky <gs...@gmail.com>.
On Tuesday 01 August 2006 01:53 Alex Blewitt wrote:
> On 31/07/06, Salikh Zakirov <Sa...@intel.com> 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 constant ...
> >
> > So, would you be satisfied if the VM defaulted to, say, 3/4 of total
> > physical memory available? (not a #define, but a value detected at
> > startup)
> >
> > I would like to get some concrete practical conclusion from the whole
> > discussion.
>
> The question should be: "Why have a maximum?" and not "What should the
> maximum be?" An algorithm that implicitly assumes a maximum is wrong.
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 may lead to confusion.
--
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Alex Blewitt <al...@gmail.com>.
On 31/07/06, Salikh Zakirov <Sa...@intel.com> 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 constant ...
>
> So, would you be satisfied if the VM defaulted to, say, 3/4 of total physical memory available?
> (not a #define, but a value detected at startup)
>
> I would like to get some concrete practical conclusion from the whole discussion.
The question should be: "Why have a maximum?" and not "What should the
maximum be?" An algorithm that implicitly assumes a maximum is wrong.
Alex.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by will pugh <wi...@sourcelabs.com>.
I would suggest
if -client
1/2 physical memory available
if -server
3/4 physical memory available
Seems like when you are using Java to run a client app, you need to play
more friendly with the apps around you.
If nothing is specified, should probabaly assume -client (since you
would hope folks are doing some amount of tuning before deploying).
--Will
Salikh Zakirov 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 constant ...
>>
>>
>
>So, would you be satisfied if the VM defaulted to, say, 3/4 of total physical memory available?
>(not a #define, but a value detected at startup)
>
>I would like to get some concrete practical conclusion from the whole discussion.
>
>
>---------------------------------------------------------------------
>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
>
>
>
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Salikh Zakirov <Sa...@Intel.com>.
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 defaulted to, say, 3/4 of total physical memory available?
(not a #define, but a value detected at startup)
I would like to get some concrete practical conclusion from the whole discussion.
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Alex Blewitt <al...@gmail.com>.
On 31/07/06, will pugh <wi...@sourcelabs.com> 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 my laptop available, and a lot more on my desktop. And
the problem with an arbitrary default is that if I want to disable
that, I have to supply extra parameters.
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 ...
> My understanding is that one of the important reasons for having a Max
> on the allocation availble to a VM from the beginning was to make sure
> the heap never used more than physical memory.
Agreed, but the strategy falls apart when Max << TotalAvailable. When
JVMs first started, 256m might have sound like a reasonable max, but
these days machines have >> 512m available. Thus, there shouldn't be a
Max by default.
You can't even do an analysis based on how much memory is currrently
free. If I'm running a JVM and there's (say) 400m available, would you
pick that? What happens if it was running out of memory, and I closed
down some memory hog or IDE to free up some space? Why limit it just
to 400m?
In fact, can you think of any other system with automatic memory
management (Smalltalk, C++ with GC, Python, Ruby, PHP, Basic, C#) that
decides on a random upper limit 'to protect the user'? I can't think
of a single instance when the default max has been helpful for me.
> Zones sound like an interesting strategy, but I'm not sure they help you
> much with wanting make the default memory option "unlimited".
> Generational is good at reducing the number of full GCs you do, but does
> not necassarily eliminate them.
Zones were a completely orthogonal idea; I merely brought it up
because they were something that I'd been thinking would be a good
idea w.r.t. VMs, and since there were a few people here that were
talking about low-level VM issues, thought it would be worth
mentioning :-)
> 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 for both references from other generations
> as well as other Class Loaders?
I've no idea if it would cause a lot of overhead. It might do. I'd
imagine that each zone would have a nursery and mature generation, but
possibly share some permanent generation.
> If you were to have a Web Application, would you basically need a write
> barrier for every string you allocate, since the String Class is loaded
> in a parent class loader? If so, this may cause more overhead than you
> would want for the stated benefit.
I suspect that if a write barrier was needed, this would quickly kill
any of the efficiencies. Perhaps there would be some other
optimisations that could avoid such things?
Alex.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by will pugh <wi...@sourcelabs.com>.
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 pages in virtual memory, you are going to do a ton of paging, and
baiscally make your machine unusable. My understanding is that one of
the important reasons for having a Max on the allocation availble to a
VM from the beginning was to make sure the heap never used more than
physical memory.
Zones sound like an interesting strategy, but I'm not sure they help you
much with wanting make the default memory option "unlimited".
Generational is good at reducing the number of full GCs you do, but does
not necassarily eliminate them.
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 for both references from other generations
as well as other Class Loaders?
If you were to have a Web Application, would you basically need a write
barrier for every string you allocate, since the String Class is loaded
in a parent class loader? If so, this may cause more overhead than you
would want for the stated benefit.
--Will
Alex Blewitt wrote:
> On 30/07/06, will pugh <wi...@sourcelabs.com> 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 laid out? Even if the JVM requests a single large
> contiguous space, it will still be treated as many pages by the OS,
> and you'll get a similar amount of page faults. It doesn't matter what
> virtual address space they're mapped into.
>
> One of the suggestions I put forward elsewhere was having several
> zones (one per classloader); the advantage would then be you could GC
> each zone separately, and potentially at different intervals.
>
> Alex.
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Alex Blewitt <al...@gmail.com>.
On 30/07/06, will pugh <wi...@sourcelabs.com> 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 laid out? Even if the JVM requests a single large
contiguous space, it will still be treated as many pages by the OS,
and you'll get a similar amount of page faults. It doesn't matter what
virtual address space they're mapped into.
One of the suggestions I put forward elsewhere was having several
zones (one per classloader); the advantage would then be you could GC
each zone separately, and potentially at different intervals.
Alex.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by will pugh <wi...@sourcelabs.com>.
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 higher
generations (some things will no longer be referenced, some will and
when you need the ones that are you will be pulling in mostly empty
pages), thus causing a larger working set, which can then cause many
more page faults, which can than distroy your performance?
--Will
Mikhail Fursov wrote:
> 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 expand
>
> 2) Memory usage of simple applications will be increased
>
> 3) GC needs continues memory blocks. (Why? From mutator's side neither
> bump
> pointer nor free-list allocators reqiure it?)
>
> 4) JVM has a different memory contract with
> OS, not like general applications: JVM allocates but never frees
> memory. Here we can
> teach GC to release memory to OS or teach
> JVMs to share memory to improve resources reuse.
>
> Anything missed?
>
> May be if we can solve all
> the problems above our JVM will become more attractive to users then
> others
> because it behave like a 'normal application' but not like a separate
> OS inside another OS? Why not to try?
>
>
>
>
> On 7/30/06, Xiao-Feng Li <xi...@gmail.com> 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 another a factor. On one
>> hand, the heap size has a minimal to keep all the live objects during
>> the execution; on the other hand, a larger heap size trigers GC less
>> frequently. So sometimes the GC needs to decide if it should increase
>> the heap size or just trigger a collection, assuming the heap size is
>> enough to hold all the live objects.
>>
>> Yes, to allocate/release blocks when needed is possible. I'd give you
>> more cases that requires careful design. consider a case . For
>> example, if the block is bigger than an OS page in size, even the GC
>> design can perfectly allocate/release its blocks, the system memory is
>> still fragmented. Another case is, GC sometimes needs to align the
>> block to certain size boundary, which also leaves fragments in system
>> space. Yet another case is, if the system memory space is already
>> seriously fragmented, GC may not be able to utilize the remaining
>> vacant space although the sum size of the fragments can be large.
>>
>> Many of these point to OS/JVM interactions finally. I've been looking
>> at this area. :-)
>>
>> Thanks,
>> xiaofeng
>>
>> On 7/30/06, Alex Blewitt <al...@gmail.com> wrote:
>> > On 29/07/06, Salikh Zakirov <Sa...@intel.com> 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 range it
>> could allocate.
>> > >
>> > > This is done because GC needs to have contiguous address range
>> for the
>> heap,
>> > > and allocates virtual address range upfront.
>> >
>> > It would seem that for an infinite amount of memory, attempting to
>> > allocate a contiguous address range for the heap would be a problem.
>> > It's also probably why other VMs have the -Xmx option, and attempt to
>> > obtain the range all in one go.
>> >
>> > However, if the GC is generational, why does it need to be contiguous?
>> > Why not allocate chunks per generation? Or, for that matter, why can't
>> > it be split into pages/blocks of memory? That way, you wouldn't need
>> > to attempt to allocate it all up front, but rather you could tack a
>> > new page/block onto the end of the memory list. Obviously, there would
>> > be special cases (like when allocating a large array that is greater
>> > than the page/block size) but all of these problems have been solved
>> > by filing systems in the past. I mean, it's not like creating a ZIP
>> > file attempts to allocate a contiguous block of 256Mb and then fills
>> > it up as files are added. (However, that is pretty much what happens
>> > when you create a DMG on Mac OS X ...)
>> >
>> > Incidentally, a very good book on file system design discusses the Be
>> > Filing System (BFS) and it's available at
>> > http://www.nobius.org/~dbg/practical-file-system-design.pdf
>> >
>> > Note that I'm mostly asking these questions in an attempt to find out
>> > why it can't be done, and/or how much would need to change to be able
>> > to do something like this instead. I can imagine that if there were
>> > some kind of page-on-demand memory obtaining, then you wouldn't need a
>> > -Xmx parameter (unless you wanted it), and that you'd be able to deal
>> > with this kind of DLL-in-the-middle problem that you saw on Windows.
>> >
>> > Alex.
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Mikhail Fursov <mi...@gmail.com>.
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 expand
2) Memory usage of simple applications will be increased
3) GC needs continues memory blocks. (Why? From mutator's side neither bump
pointer nor free-list allocators reqiure it?)
4) JVM has a different memory contract with
OS, not like general applications: JVM allocates but never frees
memory. Here we can
teach GC to release memory to OS or teach
JVMs to share memory to improve resources reuse.
Anything missed?
May be if we can solve all
the problems above our JVM will become more attractive to users then others
because it behave like a 'normal application' but not like a separate
OS inside another OS? Why not to try?
On 7/30/06, Xiao-Feng Li <xi...@gmail.com> 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 another a factor. On one
> hand, the heap size has a minimal to keep all the live objects during
> the execution; on the other hand, a larger heap size trigers GC less
> frequently. So sometimes the GC needs to decide if it should increase
> the heap size or just trigger a collection, assuming the heap size is
> enough to hold all the live objects.
>
> Yes, to allocate/release blocks when needed is possible. I'd give you
> more cases that requires careful design. consider a case . For
> example, if the block is bigger than an OS page in size, even the GC
> design can perfectly allocate/release its blocks, the system memory is
> still fragmented. Another case is, GC sometimes needs to align the
> block to certain size boundary, which also leaves fragments in system
> space. Yet another case is, if the system memory space is already
> seriously fragmented, GC may not be able to utilize the remaining
> vacant space although the sum size of the fragments can be large.
>
> Many of these point to OS/JVM interactions finally. I've been looking
> at this area. :-)
>
> Thanks,
> xiaofeng
>
> On 7/30/06, Alex Blewitt <al...@gmail.com> wrote:
> > On 29/07/06, Salikh Zakirov <Sa...@intel.com> 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 range it
> could allocate.
> > >
> > > This is done because GC needs to have contiguous address range for the
> heap,
> > > and allocates virtual address range upfront.
> >
> > It would seem that for an infinite amount of memory, attempting to
> > allocate a contiguous address range for the heap would be a problem.
> > It's also probably why other VMs have the -Xmx option, and attempt to
> > obtain the range all in one go.
> >
> > However, if the GC is generational, why does it need to be contiguous?
> > Why not allocate chunks per generation? Or, for that matter, why can't
> > it be split into pages/blocks of memory? That way, you wouldn't need
> > to attempt to allocate it all up front, but rather you could tack a
> > new page/block onto the end of the memory list. Obviously, there would
> > be special cases (like when allocating a large array that is greater
> > than the page/block size) but all of these problems have been solved
> > by filing systems in the past. I mean, it's not like creating a ZIP
> > file attempts to allocate a contiguous block of 256Mb and then fills
> > it up as files are added. (However, that is pretty much what happens
> > when you create a DMG on Mac OS X ...)
> >
> > Incidentally, a very good book on file system design discusses the Be
> > Filing System (BFS) and it's available at
> > http://www.nobius.org/~dbg/practical-file-system-design.pdf
> >
> > Note that I'm mostly asking these questions in an attempt to find out
> > why it can't be done, and/or how much would need to change to be able
> > to do something like this instead. I can imagine that if there were
> > some kind of page-on-demand memory obtaining, then you wouldn't need a
> > -Xmx parameter (unless you wanted it), and that you'd be able to deal
> > with this kind of DLL-in-the-middle problem that you saw on Windows.
> >
> > Alex.
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
--
Mikhail Fursov
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 minimal to keep all the live objects during
the execution; on the other hand, a larger heap size trigers GC less
frequently. So sometimes the GC needs to decide if it should increase
the heap size or just trigger a collection, assuming the heap size is
enough to hold all the live objects.
Yes, to allocate/release blocks when needed is possible. I'd give you
more cases that requires careful design. consider a case . For
example, if the block is bigger than an OS page in size, even the GC
design can perfectly allocate/release its blocks, the system memory is
still fragmented. Another case is, GC sometimes needs to align the
block to certain size boundary, which also leaves fragments in system
space. Yet another case is, if the system memory space is already
seriously fragmented, GC may not be able to utilize the remaining
vacant space although the sum size of the fragments can be large.
Many of these point to OS/JVM interactions finally. I've been looking
at this area. :-)
Thanks,
xiaofeng
On 7/30/06, Alex Blewitt <al...@gmail.com> wrote:
> On 29/07/06, Salikh Zakirov <Sa...@intel.com> 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 range it could allocate.
> >
> > This is done because GC needs to have contiguous address range for the heap,
> > and allocates virtual address range upfront.
>
> It would seem that for an infinite amount of memory, attempting to
> allocate a contiguous address range for the heap would be a problem.
> It's also probably why other VMs have the -Xmx option, and attempt to
> obtain the range all in one go.
>
> However, if the GC is generational, why does it need to be contiguous?
> Why not allocate chunks per generation? Or, for that matter, why can't
> it be split into pages/blocks of memory? That way, you wouldn't need
> to attempt to allocate it all up front, but rather you could tack a
> new page/block onto the end of the memory list. Obviously, there would
> be special cases (like when allocating a large array that is greater
> than the page/block size) but all of these problems have been solved
> by filing systems in the past. I mean, it's not like creating a ZIP
> file attempts to allocate a contiguous block of 256Mb and then fills
> it up as files are added. (However, that is pretty much what happens
> when you create a DMG on Mac OS X ...)
>
> Incidentally, a very good book on file system design discusses the Be
> Filing System (BFS) and it's available at
> http://www.nobius.org/~dbg/practical-file-system-design.pdf
>
> Note that I'm mostly asking these questions in an attempt to find out
> why it can't be done, and/or how much would need to change to be able
> to do something like this instead. I can imagine that if there were
> some kind of page-on-demand memory obtaining, then you wouldn't need a
> -Xmx parameter (unless you wanted it), and that you'd be able to deal
> with this kind of DLL-in-the-middle problem that you saw on Windows.
>
> Alex.
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Alex Blewitt <al...@gmail.com>.
On 29/07/06, Salikh Zakirov <Sa...@intel.com> 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 range it could allocate.
>
> This is done because GC needs to have contiguous address range for the heap,
> and allocates virtual address range upfront.
It would seem that for an infinite amount of memory, attempting to
allocate a contiguous address range for the heap would be a problem.
It's also probably why other VMs have the -Xmx option, and attempt to
obtain the range all in one go.
However, if the GC is generational, why does it need to be contiguous?
Why not allocate chunks per generation? Or, for that matter, why can't
it be split into pages/blocks of memory? That way, you wouldn't need
to attempt to allocate it all up front, but rather you could tack a
new page/block onto the end of the memory list. Obviously, there would
be special cases (like when allocating a large array that is greater
than the page/block size) but all of these problems have been solved
by filing systems in the past. I mean, it's not like creating a ZIP
file attempts to allocate a contiguous block of 256Mb and then fills
it up as files are added. (However, that is pretty much what happens
when you create a DMG on Mac OS X ...)
Incidentally, a very good book on file system design discusses the Be
Filing System (BFS) and it's available at
http://www.nobius.org/~dbg/practical-file-system-design.pdf
Note that I'm mostly asking these questions in an attempt to find out
why it can't be done, and/or how much would need to change to be able
to do something like this instead. I can imagine that if there were
some kind of page-on-demand memory obtaining, then you wouldn't need a
-Xmx parameter (unless you wanted it), and that you'd be able to deal
with this kind of DLL-in-the-middle problem that you saw on Windows.
Alex.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Salikh Zakirov <Sa...@Intel.com>.
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 needs to have contiguous address range for the heap,
and allocates virtual address range upfront.
> $ ./java Hello
> WARNING: final heap size is too large, reduced to 900 Mb
> Hello
The size is as low as 900 Mb on my laptop most probably due to some DLL sticking
in the middle of the process address space. I saw DRLVM working with 1300m heap
on some other machine.
What's more, there exists an unpleasant side effect of "infinite" -Xmx.
If you have a leaky native library (and we had!), then the amount
of memory available to the C heap is minimized, and the time range
before your program crashes becomes much shorter.
I saw Eclipse crashing after 1 hour with -Xmx1g, but working for more
than a day with -Xmx600m, which left 400m more megabytes to native heap.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Salikh Zakirov <Sa...@Intel.com>.
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 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.
$ ./java Hello
WARNING: final heap size is too large, reduced to 900 Mb
Hello
> Care to try?
--- a/vm/gc/src/gc_for_vm.cpp
+++ b/vm/gc/src/gc_for_vm.cpp
@@ -210,8 +210,8 @@ static void parse_configuration_properti
// set the initial and maximum heap size based on provided options and defaults
const int Mb = 1048576;
if (0 == final_heap_size_bytes && 0 == initial_heap_size_bytes) {
- // defaults -Xms64m -Xmx256m
- final_heap_size_bytes = 256*Mb;
+ // defaults -Xms64m -Xmx\infty
+ final_heap_size_bytes = (POINTER_SIZE_INT)-Mb;
initial_heap_size_bytes = 64*Mb;
} else if (0 == initial_heap_size_bytes) {
// -Xms64m or same as mx, whichever is less
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Salikh Zakirov <Sa...@Intel.com>.
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).
Care to try?
--- a/vm/gc/src/gc_for_vm.cpp
+++ b/vm/gc/src/gc_for_vm.cpp
@@ -210,8 +210,8 @@ static void parse_configuration_properti
// set the initial and maximum heap size based on provided options and defaults
const int Mb = 1048576;
if (0 == final_heap_size_bytes && 0 == initial_heap_size_bytes) {
- // defaults -Xms64m -Xmx256m
- final_heap_size_bytes = 256*Mb;
+ // defaults -Xms64m -Xmx\infty
+ final_heap_size_bytes = (POINTER_SIZE_INT)-1;
initial_heap_size_bytes = 64*Mb;
} else if (0 == initial_heap_size_bytes) {
// -Xms64m or same as mx, whichever is less
---------------------------------------------------------------------
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
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Alex Blewitt <al...@gmail.com>.
On 29/07/06, Salikh Zakirov <Sa...@intel.com> 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 similar for the defaults eventually, but
> have not got to it yet. Currently, it has hardcoded defaults of -Xms64m and -Xmx256m.
But the point is, this is a hardcoded default maximum of 256m for no
particularly good reason. Why should it not be infinity? In fact, it's
really a bad idea to have any non-infinte number by default, because
if your default is too small (which it will be for a number of
situations e.g. heavy server processing, massive Eclipse installs
etc.) then people *have* to override the default to allow their
applications to run.
> So, answering your question, if you do not want to put any artificial
> limit to the memory used by the java heap, then do not specify any -Xmx and -Xms
> options, and the JVM will decide itself.
The JVM will decide on another arbitrary default, though. If I don't
specify a maximum, I don't expect there to be a maximum. If I'm
running a J2EE system on a 3Gb PowerPC platform, why does the default
not allow me to run a J2EE server that takes advantage of all the
memory that I have? Why should it arbitrarily limit it to a small
percentage of what is currently available?
> However, if you *do* want to limit the amount of memory used for the JVM, then these
> options are very useful.
Agreed, when you do want to limit the resources (e.g. limiting each
process to a 1Gb chunk on a multi-processor, multi-core system) would
make sense. But if you *don't* want to limit it, you shouldn't specify
-Xmx and there should be no limit.
Let's face it, the only reason why J2EE servers (or indeed, Eclipse)
allow you to put in your own VM args for -Xmx is because the default
is too low for that particular use. There is absolutely no reason why
an upper limit is needed from a user's perspective, and the fact that
the VM chooses Math.random() as an upper limit for you is no help at
all.
If you do specify -Xmx2056m then the VM will agressively take up all
that memory without releasing pages back to the OS, and for some VMs,
will actually try to request that much memory when the VM starts up.
Why not just request more memory when it's needed, and release it when
it's not? Then the only maximum is how much the operating system can
give.
When was the last time you saw the message: "I'm sorry, Word cannot
load the document. You will have to re-run Word with -Xmx1024m in
order to be able to load it"
Alex.
---------------------------------------------------------------------
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
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Posted by Salikh Zakirov <Sa...@Intel.com>.
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 that used -mx and -ms options
instead of -Xmx and -Xms. I don't remember what it was. Could it have been java 1.1?
> 2) That they felt the need to build another level of non-non-standard
> into command line options such that -XX is even necessary
I agree, -XX looks ugly to me too. Sinse these options are "two times non-standard",
we don't have the need to have any of those.
Regarding the -X and standard options in DRLVM, it strives to
have all "standard" options, both de jure and de facto, and has
all its own non-standard options starting with -X.
> 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,
and do not require you to specify any default.
BEA jRockit defaults to 64m initial size, and 3/4 of physical memory maximum size,
according to their user documentation. And this looks reasonable to me.
In DRLVM, I plan to do something similar for the defaults eventually, but
have not got to it yet. Currently, it has hardcoded defaults of -Xms64m and -Xmx256m.
So, answering your question, if you do not want to put any artificial
limit to the memory used by the java heap, then do not specify any -Xmx and -Xms
options, and the JVM will decide itself.
However, if you *do* want to limit the amount of memory used for the JVM, then these
options are very useful.
---------------------------------------------------------------------
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