Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35182

Re: Memory usage

Show all headers | View raw

On 02/08/16 21:48, Cecil Westerhof wrote:
> I have a Java application which I start with the parameters:
>      -Xms4M -Xmx8M
>
> So the initial heap size will be 4 MB and the maximum will be 8 MB.
> But some strange things happen.
>
> Almost immediately the GC is running:
>      2016-07-09T10:14:34.537+0200: 0.257: [GC (Allocation Failure)  512K->488K(3584K), 0.0029586 secs]
>      2016-07-09T10:14:34.771+0200: 0.491: [GC (Allocation Failure)  1000K->496K(3584K), 0.0012720 secs]
>      2016-07-09T10:14:34.815+0200: 0.535: [GC (Allocation Failure)  1008K->552K(3584K), 0.0014619 secs]
>      2016-07-09T10:14:35.496+0200: 1.216: [GC (Allocation Failure)  1064K->656K(4096K), 0.0017656 secs]
>      2016-07-09T10:14:36.035+0200: 1.755: [GC (Allocation Failure)  1680K->1048K(4096K), 0.0023148 secs]
>
> But why? Minimum size is 4 MB, so why does it run when there is only
> half an MB allocated?

The algorithm for default GC is complicated, and in general of little interest. The main thing is that it goes on quietly in the background, and you don't really notice. For a nice overview, look here http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

The reason GC is running is given: Allocation Failure. The eden portion of the heap is full and the JVM needs space to allow new objects to be constructed.
This implies that your code is creating and freeing objects quickly, i.e. lots of very short lived objects in the young generation of the heap which need to be cleared out by GC to make room for more. Because you have a very small heap, you presumably have a proportionally very small eden.

The important question, though, is why do you care?
Unless GC is causing problems just let it get on with its business in the background, using spare CPU cycles that you probably won't notice.
If you do try to mess with GC, beware. It's likely you will fall foul of the Law of Unintended Consequences. Whilst altering GC may appear to work superficially, it has a nasty habit of creeping up behind you, and when you least expect it biting you in the ass.

>
> At the moment I see:
>      2016-08-02T07:18:14.364+0200: 2062960.388: [GC (Allocation Failure)  4576K->3192K(5632K), 0.1543506 secs]
>      2016-08-02T09:23:04.833+0200: 2070450.857: [GC (Allocation Failure)  4728K->3168K(5632K), 0.0010015 secs]
>      2016-08-02T16:18:20.051+0200: 2095366.075: [GC (Allocation Failure)  4704K->3112K(5632K), 0.0017111 secs]
>      2016-08-02T19:37:35.176+0200: 2107321.200: [GC (Allocation Failure)  4648K->3056K(5632K), 0.0014402 secs]
>
> So the heap is still around 4 MB.
>
> But when I look at memory used and swap used (it is on an openSUSE
> 13.2 system) then I see that used memory is 37 MB and used swap is
> 57 MB. How is it possible that these are so high?

How are you looking at the memory usage?
Process stats are typically very misleading. Also, why would such a small program be using any swap at all, unless it's been running for a long time and unused pages have been swapped to make room for other applications.

>
> When I close the program and start it again, it only uses 40 MB memory.
>

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Memory usage Cecil Westerhof <Cecil@decebal.nl> - 2016-08-02 22:48 +0200
  Re: Memory usage Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-02 17:28 -0400
  Re: Memory usage Arne Vajhøj <arne@vajhoej.dk> - 2016-08-02 17:49 -0400
    Re: Memory usage Arne Vajhøj <arne@vajhoej.dk> - 2016-08-02 17:52 -0400
  Re: Memory usage Roedy Green <inquiry@mindprod.com> - 2016-08-02 17:51 -0700
  Re: Memory usage Nigel Wade <nmw@local.domain> - 2016-08-03 13:11 +0100

csiph-web