-Xmx is hurting java

[phil swenson]

http://eblog.chrononsystems.com/xmx-is-hurting-the-usability-of-java

I've been saying this since I first discovered the terrible
OutOfMemoryException in 1999. Xmx makes java inherently unstable.
You can't rely on your app to stay up until you find the magic Xmx
setting. WTF!?

Dick/Carl/Tor/Joe - when you talk to Mark Reinnhold, can you bring this up?

[Jess Holle]

It's just like the pre-OS-X Mac OS in this regard :-)

Though I can understand why it is hard to avoid -Xmx for various GC
algorithms whereas the pre-OS-X Mac OS really had no excuse.

[PhilDin]

I've always wondered about this, before I encountered OOM, I just
assumed that the JVM would keep asking for memory until the underlying
OS refused to give it any more. Then, when I found the -Xmx switch, I
assumed that there was an option to specify "as much as you can get
from the OS" but again, no.

I imagine the people working on the JVM are a little smarter than the
average bear so there's probably good, non-trivial reasons for
requiring -Xmx but I don't know what they are. Can anyone give some
pointers on this? Also, what does the .Net CLR do? Does it impose any
constraints on memory allocation? Does it suffer from poorer garbage
collection or allocation performance at the expense of its strategy?

Thanks,
Phil

[Joseph Ottinger]

TheServerSide picked this up: http://www.theserverside.com/news/thread.tss?thread_id=62799

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Joseph B. Ottinger
http://enigmastation.com

[Michael Barker]

I agree wholeheartedly agree.  I like Azul's approach, just give it 40 gig (-Xmx40g) and their GC sorts out the rest.  They even hand memory back to the OS.

http://www.infoq.com/presentations/Java-without-the-GC-Pauses

[mbien]

see it as performance optimisation. A GC impl which would have to deal
with fragmented, non continuous and resizing heap would have a hard
time to compete with the current VM. A JVM is a operating system for
java applications. You can't plug in new RAM brick in your system
easily at runtime for the same reasons.

I would go even further and say that writing java applications with
unknown memory requirements is not that professional :P

[Reinier Zwitserloot]

On Friday, August 12, 2011 11:37:15 PM UTC+2, mbien wrote:

see it as performance optimisation. A GC impl which would have to deal
with fragmented, non continuous and resizing heap would have a hard
time to compete with the current VM. A JVM is a operating system for
java applications. You can't plug in new RAM brick in your system
easily at runtime for the same reasons.

I would go even further and say that writing java applications with
unknown memory requirements is not that professional :P

This is spot on. For large server apps. For client apps or quick command line tools, being forced to prepick total memory load (and treating the JVM that's going to start up to host your app as an OS-in-a-OS), is ridiculous.

[Alan Kent]

Not a great analogy really is it? I don't know of any widely used OS that requires every process to say how much memory it's going to use before it even starts running.

In fact this post really highlighted to me how restrictive the approach is! Forget writing an app that can adapt to different inputs dynamically!!! You have to pick memory size first. No wonder java is only serious for server side stuff.

Alan

Sent from my iPhone

[Michael Barker]

see it as performance optimisation. A GC impl which would have to deal
with fragmented, non continuous and resizing heap would have a hard
time to compete with the current VM.

Where's it written that the current VM has a continuous, non-fragmented static heap.  This would only be possible if -Xms == -Xmx and I doubt this is handled as a special case.  More modern garbage collectors (C4 & G1) deal with memory as pages or regions already and could (as C4 does) recycle unused pages back to the OS.  I'm not intimately familiar with hotspot, but the bits of code I've read suggest it does all of it's allocation on a page by page basis, presumably to try and match the boundaries set out by the CPU/OS.

Mike

[Casper Bang]

> In fact this post really highlighted to me how restrictive the approach is! Forget writing an app that can adapt to different inputs dynamically!!! You have to pick memory size first.  No wonder java is only serious for server side stuff.

I was going to point out the same thing, how really lots of these
little things contributed to Java being such an underachiever on the
desktop. It's fair enough to allow hints to be passed along as tweaks
from the outside world for when it's needed, but the default behavior
of a *managed* runtime, should obviously *not* be to blow up when
Moore's law transcends policies of the past. And don't even get me
started on PermGen!

I've never run into these things when using Mono or .NET, the runtime
is no more different than a native application in this aspect. The GC
is expected to do the best job it can within the confines of available
memory as regulated by the underlying OS.

[Fabrizio Giudici]

On 08/13/2011 01:32 AM, Reinier Zwitserloot wrote:

Agreed. Michael is right in general, but as Reiner says Java apps for
the desktop are seriously impacted by this. The problem is not that you
can't figure out in advance a setting for -Xmx, but the fact that it's a
single "average" setting that won't work for all users. For instance, if
you create a desktop app with large memory requirements (such as an
image processing tool) either you set a low limit (say, 1GB) and you get
people with 4GB of RAM in their PC complaining about the fact that your
app is not able to use all of them, or you set a high limit (say, 4GB)
and unfortunately the app will allocate all of the memory even though it
doesn't need it, because the current GC is designed like that. This will
cause paging in machines with less memory, impacting the performance of
the app... and you end up with people saying that Java is slow. In my
experience, you have to provide a way for the user to set his own
setting, which also implies the need of a configurable launcher (no
rocket science, but an annoyance). The bigger problem, anyway,

That's why I'm completely uninterested in language improvements, such as
Project Coin or closures, things where other languages can provide
innovation, while some basic weaknesses of the VM (where others can't
provide innovation) aren't dealt with after sixteen years.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Puybaret]

I'm happy Phil launched this subject, since users suffer with this -
Xmx option in Sweet Home 3D application as soon as they want to create
big projects. I set the default Xmx value to 512 MB or 1 GB depending
on the system, but in fact it's not enough and I had to add the FAQ
"How can I adjust the memory used by Sweet Home 3D?" because of that
(see http://www.sweethome3d.com/faq.jsp#increaseMaxMemory ).

> I like Azul's approach, just give it 40 gig (-Xmx40g) and their GC
> sorts out the rest.  They even hand memory back to the OS.

Miserably, it won't work in some 32 bits OS! And as the Xmx value must
be given before program launch, this obliges you to program a
complicated system (with an installer or a special script for example)
to find out what value will be accepted. And of course such a system
can't be used in an applet environment.
Under Windows, I've even seen users unable to run Sweet Home 3D with -
Xmx1024m! As I never found out why, I was obliged to set -Xmx to 512
under this system. :-(

> I would go even further and say that writing java applications with
> unknown memory requirements is not that professional :P

How can I require people to have a 64 bits machine with 4 GB of
memory, if Sweet Home 3D works great with less than 256 MB in most
situations?

I agree there should be a JVM option that would say "use as much
memory as the system will let you". If this option implies more GC, I
don't mind, at least users won't have a bad feeling about how a Java
program works. Do you know any way to push Oracle to implement this
option?

[Fabrizio Giudici]

On 08/13/2011 10:38 AM, Fabrizio Giudici wrote:
> set his own setting, which also implies the need of a configurable
> launcher (no rocket science, but an annoyance). The bigger problem,
> anyway,

Whoops, missing sentence. It was:

The biggest problem, anyway, is that you have to force your users to
understand a technicality of the application tuning. When an end user
launches the average desktop application, he doesn't have to tune it.
So, immediately your application goes in the category of "cumbersome stuff".

[mgkimsal]

Why, then, on my JVM web app, when I specify -Xmx2g, do I see a Java
process
eating up 10g on my system? -Xmx doesn't seem to honor anything I
give it -
it just uses up all the memory on my server.

[mbien]

On Aug 13, 9:37 am, Michael Barker <mike...@gmail.com> wrote:
> > see it as performance optimisation. A GC impl which would have to deal
> > with fragmented, non continuous and resizing heap would have a hard
> > time to compete with the current VM.
>
> Where's it written that the current VM has a continuous, non-fragmented
> static heap.

i should have used "contiguous" which would have made it easier to
google it
http://blogs.oracle.com/moazam/entry/why_can_t_i_allocate

of course its not specified if thats what you meant with "written
down".

for jrockit:
http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

i remember quite well as we had to tweak the boot process of windows
to move some statically allocated addresses around just to make the
mem contiguous after boot.
(couldn't find a good link for this one)
-michael

>
> Mike

[mbien]

On Aug 13, 4:26 am, Alan Kent <alan.james.k...@gmail.com> wrote:
> Not a great analogy really is it? I don't know of any widely used OS that requires every process to say how much memory it's going to use before it even starts running.
>
> In fact this post really highlighted to me how restrictive the approach is! Forget writing an app that can adapt to different inputs dynamically!!! You have to pick memory size first.  No wonder java is only serious for server side stuff.

Its not as restrictive as it might seem. -Xmx is the max memory the
JVM is allowed to take its not what it takes at startup. There is also
-Xms which is the start size.

Java is not on the desktop since it has serious deployment issues.
Once they are solved nobody will complain about things like those
flags anymore since they could be easily picked by the launcher (@see
NetBeans which picks -Xmx for you).

Don't get me wrong, a resizing heap would be nice to have but i bet
almost everyone will try to disable it. If we would have it right now
we would complain about things like:
- eclipse eats all my memory and never frees anything
- everytime when i hit "rafactor" the jvm stops, my heap grows and if
i stop refactoring the jvm stops again and the heap shrinks.. lets add
a feature called -Xmx :)

regards,
michael

>
> Alan
>
> Sent from my iPhone
>

[Reinier Zwitserloot]

I'm guessing you don't know how to read memory usage of an app. Any shared libraries used by any process, including all the memory it uses and all the shared libraries it brings in, all 'count'. So, the same library shows up for lots of processes. These days just the core OS library is gigantic, for example. This isn't really memory used by the app of course, and java links into a _lot_ of shared libraries. It's not as simple as just showing a process' own usage minus all the shared libraries, because some 'shared' libraries are really just used by the one app, so they should count. Art, not a science. Best thing to do is to measure free mem, then fire up a JVM, do some stuff, and recheck, except that too is problematic, as free mem is itself a wobbly number; OSes will keep processes around in case they are soon restarted, and all sorts of freed memory isn't actually freed because its more efficient to do so in batch form.

The upshot of all this is that it's virtually impossible to accurately measure memory load for any given app with the tools that ship with OSes to do so. Sounds like the kind of thing that ought to be trivial to measure but it isn't.

[Kirk]

Man, this thread contains a lot of FUD about how GC works (or doesn't work).

First point, Java heap must be contiguous for the current GC implementations. Which means you have to specify -Xmx right at startup. At start, the JVM will reserve -Xmx amount of C heap for Java heap. Java heap is then expanded from reserved memory when Hotspot determines that it could benefit or needs more memory. Java heap will *never* grow bigger than the setting of -Xmx. If you don't specify -Xmx, the default is to set it to 1/4 of physical ram starting with a portion allocated (depending on which hotspot engine is invoked).

The parallel collector is more ergonomic than the default CMS collector. This means that while CMS generally won't resize to be smaller, the parallel collector will adapt to pause time and throughput goals. I've got a gc log lying about some where that clearly demonstrates the spaces resizing based on load.

Memory is generally never given back to the OS as it's a very very tricky thing to do. To give memory pack you need to guarantee 100% that you have no pointers to anything in the space you're about to give back or you risk a SEGV. In some cases, dealloc does nothing.

C applications will take as much memory as the OS will give them. Since the JVM is a C application, it will take as much memory as the OS will give it. And it sometimes does take more memory than you'd expect. However, Java heap -Xmx setting is *always* honored. If your JVM is 10g with a 2g -Xmx heap setting it is the C heap that is consuming the other 8gigs. You've got an NIO or JNI or some thing else causing a native C heap leak.

Should one let a JVM take as much heap as is possible? I think it's a pretty dangerous thing to do. If you let the JVM take *all* memory, what happens when it runs out. Current if the JVM runs out of memory (not native C heap but Java heap) there is still something the JVM can do to try to recover. Even is native heap is seemingly exhausted, there are guard pages put into the process that allow the JVM to try to do something reasonable. Current implementations (including Azul's) are all encumbered by these restrictions. Azul just happens to be a bit smarter at the moment in how they manage it. But even they are constrained as to what they can do by the underlying hardware/OS. In fact, they run in a hacked up OS that is specifically tuned for their JVM. Nothing wrong with this but....

I could go on.

Regards,
Kirk

[Michael Barker]

Man, this thread contains a lot of FUD about how GC works (or doesn't work).

First point, Java heap must be contiguous for the current GC implementations.

I'll hold my hand up, I'm definitely wrong on that case (should check my assumptions first).

Memory is generally never given back to the OS as it's a very very tricky thing to do. To give memory pack you need to guarantee 100% that you have no pointers to anything in the space you're about to give back or you risk a SEGV. In some cases, dealloc does nothing.

I would of thought that is something the GC needs to do anyway.  If it's not 100% certain that a segment of memory is free of back references doesn't it risk data corruption if the memory reused for more managed objects in the same VM?  I may be missing something, but seems like both problems are equally hard (or essentially the same).

Should one let a JVM take as much heap as is possible? I think it's a pretty dangerous thing to do. If you let the JVM take *all* memory, what happens when it runs out. Current if the JVM runs out of memory (not native C heap but Java heap) there is still something the JVM can do to try to recover. Even is native heap is seemingly exhausted, there are guard pages put into the process that allow the JVM to try to do something reasonable.

If an implementation was not constrained by requiring a contiguous heap and there was plenty of resources available, then a reasonable action could be to reserve more memory from the OS.  It needn't take all the memory, it could be smart and look at available resources and system configuration (e.g. over-commit limits) and fall back to existing means to dealing with a rapidly exhausting heap, before the OOM killer kicks in.  This would allow the default configuration of a JVM to be much more conservative with its initial startup defaults.  The 1/4 of resources always seemed to me like an overly aggressive default.

Current implementations (including Azul's) are all encumbered by these restrictions. Azul just happens to be a bit smarter at the moment in how they manage it. But even they are constrained as to what they can do by the underlying hardware/OS. In fact, they run in a hacked up OS that is specifically tuned for their JVM. Nothing wrong with this but....

The way that Gil Tene's explains it, their OS changes would be generally applicable to all managed VMs.  I.e. it is an API change for the interaction between the user application and OS for managing memory.  However, I guess that it may only be applicable if the GC compacted memory in a pattern similar to Azul's.

[Michael Neale]

Even for server apps it is at odds with, well, everything else. If you
want to limit resource usage on a per process (JVM, in this case)
there are plenty of tools that do that for you, give the system admin
more control etc... the JVM is a unique pain in the rear in this
regard ;)

There really is no good reason for it from a system management/
perspective - like all other "odd" things most reasons given are
speculation after the fact - I am sure there is a real reason and
probably some ancient decision to do with running applets in
constrained devices...

the fact that is is a -X means that it is meant to be a non core
settings too ?

[Kirk]

Hi,

Memory is generally never given back to the OS as it's a very very tricky thing to do. To give memory pack you need to guarantee 100% that you have no pointers to anything in the space you're about to give back or you risk a SEGV. In some cases, dealloc does nothing.

I would of thought that is something the GC needs to do anyway.  If it's not 100% certain that a segment of memory is free of back references doesn't it risk data corruption if the memory reused for more managed objects in the same VM?  I may be missing something, but seems like both problems are equally hard (or essentially the same).

I was tired and sick... ha, sick and tried ;-) when I first responded. how about I put it more succinctly , GC works in Java heap, which is a data structure built in a contiguous chunk of memory allocated from C heap. It reserves *all* the memory it needs and then mallocs out of the reserved space. Java heap data structure does resize it's self using ergonomics settings (the parallel collector data structures are easily adaptive because the algorithm requires application thread to be halted while CMS being mostly concurrent has to struggle with using a multi-threaded thread safe data structure (not easy)). The OOP (ordinary object pointer) does not have to be a direct pointer into memory. However, in openJDK it happens to be so. Which means that as objects are moved by the collector, the collector is obliged to find everything pointing to that object and swizzle the pointer or in the case of G1, lay down a pointer in the remembered set. In the case of the old Azul VM, they set an OS trap that was triggered when something attempted to use that address. The trap swizzled the pointer in hardware. So, memory is still allocated but the top of heap marker is moved according to what hotspot resets it to at the end of a GC cycle (another reason why CMS is less adaptive, the resetting of data structures happens during an non-STW phase).

With G1 came the move to use regions. Regions are maintained on a free list so while it seems like it maybe possible to return regions back to the OS, that would only be possible if the right regions were put onto the free list. So, it might be a future option but we're not there just yet.

BTW, it's very common to have data structures that size themselves at startup and then remain fixed in size for the duration of the run time. A number of them are found in the kernel such as process heap, bit map for file descriptors....

Should one let a JVM take as much heap as is possible? I think it's a pretty dangerous thing to do. If you let the JVM take *all* memory, what happens when it runs out. Current if the JVM runs out of memory (not native C heap but Java heap) there is still something the JVM can do to try to recover. Even is native heap is seemingly exhausted, there are guard pages put into the process that allow the JVM to try to do something reasonable.

If an implementation was not constrained by requiring a contiguous heap and there was plenty of resources available, then a reasonable action could be to reserve more memory from the OS.  It needn't take all the memory, it could be smart and look at available resources and system configuration (e.g. over-commit limits) and fall back to existing means to dealing with a rapidly exhausting heap, before the OOM killer kicks in.  This would allow the default configuration of a JVM to be much more conservative with its initial startup defaults.  The 1/4 of resources always seemed to me like an overly aggressive default.

That is the way it current works, you take what you need and reserve the rest. If you have an OOME you've generally got a problem, a bug in your application and it would behove you to fix the bug. If you have a temporary high water mark, use the parallel collector. It handles this situation very very well. I've got evidence of that from a JVM supporting a website that I bet everyone on this list uses (sorry can't name it) that is subject to spikes in load every time something happens in webosphereland.

Current implementations (including Azul's) are all encumbered by these restrictions. Azul just happens to be a bit smarter at the moment in how they manage it. But even they are constrained as to what they can do by the underlying hardware/OS. In fact, they run in a hacked up OS that is specifically tuned for their JVM. Nothing wrong with this but....

The way that Gil Tene's explains it, their OS changes would be generally applicable to all managed VMs.  I.e. it is an API change for the interaction between the user application and OS for managing memory.  However, I guess that it may only be applicable if the GC compacted memory in a pattern similar to Azul's.

Gil has a dream and a dream team that can implement it. However, what he wants to do requires that he gets a number of groups out side of his sphere of influence to accept his vision. I am totally in Gil's camp w.r.t the changes that he'd like to see coming from Intel and the Linux camp. However, both groups seem to have other priorities at the moment. I predict that Gil will be successful with the Linux camp. I'm not so sure about Intel. That said, Azul is pushing the boundaries of what a collector can do but they've not solved the problems that the Oracle HotSpot team and the IBM team haven't been able to solve just yet. I suspect once they do, the artificial OOM errors that you all are complaining about will go away.

Regards,

Kirk

[Kirk]

On Aug 15, 2011, at 3:58 AM, Michael Neale wrote:

> Even for server apps it is at odds with, well, everything else. If you
> want to limit resource usage on a per process (JVM, in this case)
> there are plenty of tools that do that for you, give the system admin
> more control etc... the JVM is a unique pain in the rear in this
> regard ;)

will, it means that the JVM needs to be understood by those deploying it. But guess what, that is the same for just about every machine on the planet.

>
> There really is no good reason for it from a system management/
> perspective - like all other "odd" things most reasons given are
> speculation after the fact - I am sure there is a real reason and
> probably some ancient decision to do with running applets in
> constrained devices...

correct, but there are good GC ergonomic reasons in the current implementations for having a max memory, min memory and incremental resizing option.

BTW, I think I saw someone mention setting -Xmx == -Xms in an earlier thread. For 1.6.0 I would not recommend it as a starting point when tuning GC as it will turn off ergonomics. Which means, GC will not be adaptive.

>
> the fact that is is a -X means that it is meant to be a non core
> settings too ?

The -X means that the setting is non-standard. FYI, you don't need to have a collector to be compliant with the JVM specification (I believe there is one implementation that in fact doesn't have a collector and -Xmx setting makes no sense in that case) which would make it hard to have a standard switch setting ;-)

>
>
>
> On Aug 13, 9:32 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
>> On Friday, August 12, 2011 11:37:15 PM UTC+2, mbien wrote:
>>
>>> see it as performance optimisation. A GC impl which would have to deal
>>> with fragmented, non continuous and resizing heap would have a hard
>>> time to compete with the current VM. A JVM is a operating system for
>>> java applications. You can't plug in new RAM brick in your system
>>> easily at runtime for the same reasons.
>>
>>> I would go even further and say that writing java applications with
>>> unknown memory requirements is not that professional :P
>>
>> This is spot on. For large server apps. For client apps or quick command
>> line tools, being forced to prepick total memory load (and treating the JVM
>> that's going to start up to host your app as an OS-in-a-OS), is ridiculous.
>

[Mikael Grev]

Maybe this clears some things up regarding returning memory to the OS.

http://www.stefankrause.net/wp/?p=14

Cheers,
Mikael

[Kirk]

The graphs are from VisualVM and the views are of Java Heap. The graphics very nicely show Java heap utilization and the collector resizing heap space to adapt. I just skimmed skimmed but if the author is claiming that memory is being returned to the OS and this is proof, he's mistaken. It does *not* show memory being returned to the OS.

Regards,
Kirk

[Joseph Ottinger]

Another issue to consider, besides Kirk's very good explanations, is that GC requires a condition to run. If it's "all memory," the condition becomes very ... iffy to specify. You can't just say "X% of memory is Eden" because that X% is X% of *all* memory, so GC becomes tenuously predictable.

You want that predictability.

[Kirk]

Hi Joe,

Well, GC runs on an occupancy threshold based on the current heap size (not max heap). It resizes based on how much free space is available after the collection ends. So you don't a max heap size for this behavior. The range is defaults to 30%-60%. If you're outside of those ranges, heap size will be reset to make it so.

Regards,

Kirk

[Kirk]

I should have added that CMS uses current occupancy + expected promoted > initiating occupancy threshold as a trigger to start. CMS is scheduled as a just in time completion. IOWs, one should schedule CMS to start so that it finishes *just* before heap would fill. A promotion failure indicates CMS was started too late and is followed by a full STW GC. Spaces are subject to resizing after the full GC. That and fragmentation are the two primary reasons for CMS failures.

Some where someone mentioned issues with Cassandra. There is a way to fragment heap such that it can't be compacted (Mark Sweep Compact or MSC) to create enough useful space. Apparently nosql implementations are susceptible to this condition. I've seen teams try to stuff cassandra data into C heap using NIO direct buffers. At the end of the day they have to solve *all* the same issues the GC guys have to solve. Oh right, before I forget, EHCache released by Terracotta suffers from the same issues as it uses the same techniques.

Regards,

Kirk

On Aug 15, 2011, at 11:30 AM, Joseph Ottinger wrote:

[Jan Bareš]

Under Windows, I've even seen users unable to run Sweet Home 3D with -
Xmx1024m! As I never found out why, I was obliged to set -Xmx to 512
under this system. :-(

 

The reason was already mentioned in Kirk's first reply. JVM needs continuous virtual memory space for the value you specified by -Xmx. Usually you will get something around 1300M on 32-bit Windows and I also have seen machines where 1024M won't work. You can use VMMAP from WinInternals to see free and reserved virtual memory regions.

 

Jan

[Jan Bareš]

As far as I know, in .NET you can use as much memory as you want, there is no hard limit (by .NET process). So it can be done, Java's GCcurrent implementations simply doesn't allow it. Also, only the SerialGC will de-commit not used pages. All the other GC will never release memory even if not used.

 

Jan

[Matthew Farwell]

2011/8/15 Kirk <kirk.pe...@gmail.com>

If an implementation was not constrained by requiring a contiguous heap and there was plenty of resources available, then a reasonable action could be to reserve more memory from the OS.  It needn't take all the memory, it could be smart and look at available resources and system configuration (e.g. over-commit limits) and fall back to existing means to dealing with a rapidly exhausting heap, before the OOM killer kicks in.  This would allow the default configuration of a JVM to be much more conservative with its initial startup defaults.  The 1/4 of resources always seemed to me like an overly aggressive default.

That is the way it current works, you take what you need and reserve the rest. If you have an OOME you've generally got a problem, a bug in your application and it would behove you to fix the bug. If you have a temporary high water mark, use the parallel collector. It handles this situation very very well. I've got evidence of that from a JVM supporting a website that I bet everyone on this list uses (sorry can't name it) that is subject to spikes in load every time something happens in webosphereland.

I would disagree with 'If you have an OOME you've generally got a problem, a bug in your application'. This may be true in some circumstances, but not in all. In some applications, you can't predict how much memory the user has, and also you can't predict what they will do with it.

Let's take the example of a successful Java desktop application: Eclipse. Sometimes I get an OOME from Eclipse, because I've run a long running process, and haven't increased the -Xmx parameter. So I get an OOME. So I have to manually increase the -Xmx. And rerun. And repeat until I give up and just use the maximum value possible for -Xmx.

The choice by default that Eclipse (or indeed the JVM) makes is incorrect for my usage pattern. I think that is really what people are complaining about. As a developer of an application, this complicates my life to have to work out a strategy to allow the user to change the memory allocation, which has to include restarting the application.

I understand why the -Xmx parameter exists. I've had experience in the past of a value of -Xmx which was greater than the available memory, which made the GC run like a dog.

But I would like to be able to say on occasion 'Just take what you need'.

Matthew.

[Kirk]

Man I hate that you've used an IDE as an example ;-) That said, I regularly bump up the amount of memory my IDE's are using and I switch from the default to a parallel collector. Since I'm an interactive user I generally don't notice the pause times. Having loads of memory means my IDE is pretty snappy. I use adaptive sizing. I don't set -Xms. I leave my IDE running for well.. as long as I don't reboot and I don't reboot all that often. Agreed would be better if all that happened automagically but that's not today's implementation. Maybe by 10 we will see something better.

Regards,

Kirk

[Casper Bang]

> will, it means that the JVM needs to be understood by those deploying it. But guess what, that is the same for just about every machine on the planet.

Except, not every IT org can devote a deployment engineer to
understanding the Java memory model and intricate details about
generations and collector strategies. This leads to countless real-
world developers arbitrarily bumping up memory per trial n' error
fashion. And really, if I am given a vmware instance for my server,
where the system admins (or the vmware governor itself) can and will
tweak available memory, how am I going to specify optimal -X arguments?

[Kirk]

On Aug 15, 2011, at 3:41 PM, Casper Bang wrote:

>> will, it means that the JVM needs to be understood by those deploying it. But guess what, that is the same for just about every machine on the planet.
>
> Except, not every IT org can devote a deployment engineer to
> understanding the Java memory model and intricate details about
> generations and collector strategies.

there are so many things wrong with this statement I'm not even going to start.

Regards,
Kirk

[Sven Reimers]

On Mon, Aug 15, 2011 at 3:48 PM, Kirk <kirk.pe...@gmail.com> wrote:
>
> On Aug 15, 2011, at 3:41 PM, Casper Bang wrote:
>
>>> will, it means that the JVM needs to be understood by those deploying it. But guess what, that is the same for just about every machine on the planet.
>>
>> Except, not every IT org can devote a deployment engineer to
>> understanding the Java memory model and intricate details about
>> generations and collector strategies.
>

Send them to a training - it's worth every penny...

Sven

> there are so many things wrong with this statement I'm not even going to start.
>
> Regards,
> Kirk
>

> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
>

--
Sven Reimers

* Senior System Engineer and Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html
* Community Leader  NetBeans: http://community.java.net/netbeans
* Duke's Choice Award Winner 2009
* Blog: http://nbguru.blogspot.com

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=1860468
                   http://www.linkedin.com/groups?gid=107402
                   http://www.linkedin.com/groups?gid=1684717
* Oracle: https://mix.oracle.com/groups/18497

[Kirk]

Hi Sven,

Any particular training in mind ;-)

Speaking of which, I hear that is still room for a few more people at the up coming open spaces conference we'll both be at.
Since it's a free (as in beer) open spaces conference, I'll spam the group with this shameless plug ;-)

<shameless plug>
http://www.javaspecialists.eu/wiki/index.php/JavaSpecialistsSymposium2011#Thursday_1st_of_September
</shameless plug>

Regards,
Kirk

[Casper Bang]

> there are so many things wrong with this statement I'm not even going to start.

Heh, there are the real world trenches and the ivery tower developers.
You proved which one you belong to with that sweeping statement.

[Kirk]

I've been in many trenches and trust me, the way to go in is with all your toys.. and if you don't have them you've no business in the trench.

Regards,
Kirk

[Casper Bang]

Toys? Ehh... Ok you've lost me. If you've indeed been in the trenches,
then you'd certainly know that not all companies can afford a
dedicated deployment team. There can be something wrong with that
statement in your head, but that doesn't make it any less true buddy.

[Ricky Clarkson]

The analogies in this thread seem to have a flat tyre.

[Michael Neale]

really?? every machine on the planet? that attitude is a worry, and a
good example of what I feared is still the prevailing attitude.

[Michael Barker]

Hi Kirk,

Thank you for the detailed reply.

With G1 came the move to use regions. Regions are maintained on a free list so while it seems like it maybe possible to return regions back to the OS, that would only be possible if the right regions were put onto the free list. So, it might be a future option but we're not there just yet.

I live in hope :-).  I guess a lot of the venting on this thread is a result of the difference between the constraints of the current implementations and being able to see what is possible (or different elsewhere).

 

BTW, it's very common to have data structures that size themselves at startup and then remain fixed in size for the duration of the run time. A number of them are found in the kernel such as process heap, bit map for file descriptors....

Yep, we do that too, mostly bounded buffers between threads.

 

That is the way it current works, you take what you need and reserve the rest. If you have an OOME you've generally got a problem, a bug in your application and it would behove you to fix the bug.

I guess what I find annoying is the memory reservation is, from the user's perspective, only a constraint.  It obviously simplifies the implementation, however as a user it doesn't buy me anything.  Set the value to low and I can run out of memory with resources still available on the box, set it too high, either the app doesn't start or (as happened yesterday in one of our test environments) the guest OS can over commit virtual memory and the host OS's OOM killer takes out the guest.  Not much that Java can do in that case.

To be more objective, you're right, if you experience an OOME you're missing a step in the understanding of your software.  Maybe a missing load test.

 

Gil has a dream and a dream team that can implement it. However, what he wants to do requires that he gets a number of groups out side of his sphere of influence to accept his vision. I am totally in Gil's camp w.r.t the changes that he'd like to see coming from Intel and the Linux camp. However, both groups seem to have other priorities at the moment. I predict that Gil will be successful with the Linux camp. I'm not so sure about Intel. That said, Azul is pushing the boundaries of what a collector can do but they've not solved the problems that the Oracle HotSpot team and the IBM team haven't been able to solve just yet. I suspect once they do, the artificial OOM errors that you all are complaining about will go away.

It always inspiring to speak to Gil.  I like that Azul are not content to settle with what's available and are constantly reaching for what's possible.  I think their proposed memory interface changes will get through sooner rather than later, although the scheduler changes will be a tougher sell to the linux crowd.  As for the Intel side, who knows.  If they could see the potential for a hardware load value barrier outside of Java, perhaps.  Although there are a hugh number of features in the Intel chips driven by the gaming industry (e.g. write-combining buffers), so perhaps the Java crowd could have some influence too :-).  I think that it's awesome that Gil and his team are even trying.

Mike.

[Kirk]

 

That is the way it current works, you take what you need and reserve the rest. If you have an OOME you've generally got a problem, a bug in your application and it would behove you to fix the bug.

I guess what I find annoying is the memory reservation is, from the user's perspective, only a constraint.  It obviously simplifies the implementation, however as a user it doesn't buy me anything.  Set the value to low and I can run out of memory with resources still available on the box, set it too high, either the app doesn't start or (as happened yesterday in one of our test environments) the guest OS can over commit virtual memory and the host OS's OOM killer takes out the guest.  Not much that Java can do in that case.

I think that there are a few things we say here

1) Every application I run has come with the stipulation that it need a certain minimal amount of hardware in order to run properly.

2) Complex systems require knowledgeable and often customized if not one off installations

3) We want 0 admin for things we give to end users

4) Java is not 0 admin

It always inspiring to speak to Gil.  I like that Azul are not content to settle with what's available and are constantly reaching for what's possible.  I think their proposed memory interface changes will get through sooner rather than later, although the scheduler changes will be a tougher sell to the linux crowd.  As for the Intel side, who knows.  If they could see the potential for a hardware load value barrier outside of Java, perhaps.  Although there are a hugh number of features in the Intel chips driven by the gaming industry (e.g. write-combining buffers), so perhaps the Java crowd could have some influence too :-).  I think that it's awesome that Gil and his team are even trying.

IMHO, this is the competitive spirit that Sun was originally trying to inspire. IBM has a new GC algorithm (Balance) that I know nothing about. We gave IBM a slot at JavaONE to explain what they've done. Creating better methods of memory management problems is an interesting topic.

The only way Intel will take Gil's suggestions to heart is if Java is very important to helping them sell processors and/or solving the Java write bandwidth problems helps solve other write bandwidth (and other real estate related) problems in the general application population.

Regards,

Kirk

Mike.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/bDGDQOGBVNYJ.

[Kirk]

On Aug 16, 2011, at 5:31 AM, Michael Neale wrote:

> really?? every machine on the planet? that attitude is a worry, and a
> good example of what I feared is still the prevailing attitude.

I don't understand.. et me restate this. End users may do the final install of an application on their phone, tablet, desktop,.. what ever.. but some expert some where as looked into the issues of how to get that done. The more complex the system, the more one off or customized the deployment, the more expertise is needed.

Regards,
Kirk

[Michael Neale]

I mean that the JVM isn't "special" in deployment - there are many
other systems that have to be dealt with - but it is one of the most
problematic.

The explanations to do with GC implementation make sense - that is
fine - but that doesn't mean it has to be like that for ever (as Azul
are showing, and I am sure others will).

[Kirk]

How about deploying Oracle RDB?

Regards,
Kirk

[Mikael Grev]

The VM does return memory, at least some GCs. How much and when is up
to the GC. The 30-60% rule is very simplistic and can be improved upon
if Xmx should go higer by default.

Current heuristic for memory release isn't good if you remove Xmx. I
don't claim it is and I would never suggest to remove Xmx in the GC's
current shape.

But GC logic for returning memory could be made to return more quickly
if memory gets low in the OS. Of course that work needs to be made
first, then Xmx should be made optional.

Cheers,
Mikael