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

Groups > comp.lang.java.programmer > #35175 > unrolled thread

Memory usage

Back to article view | Back to comp.lang.java.programmer

Contents

  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

#35175 — Memory usage

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?

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?

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

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#35176

On 8/2/2016 4:48 PM, 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?

     Maybe some large objects were allocated?  Even when using only
512K of 4M, `new int[1000][1000]' might well prompt a GC.

     Keep in mind that the state of the art (and "art" it is!) in
garbage collection is constantly in flux.  When I was at Sun, they
were forever tinkering with different garbage collectors and tunings
and auto-adjustments and heuristics and whatnot, and I have no reason
to think the work ceased when Sun set.  That is, Oracle is very likely
still changing GC stuff from release to release and even from patch to
patch -- meaning that both the command-line controls (recall that "The
-X options are non-standard and subject to change without notice") and
the output of the GC traces may not mean the same thing today that
they did six months ago ...

     You don't mention what Java release you're using, but if it's SE8
you might find something useful at

http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html

     Good luck!

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#35177

On 8/2/2016 4:48 PM, 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.

Given how small these values are then I am not surprised that you see
funky results.

Newer Java SE's has not been designed to run with so little heap.

> 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?

Maybe because there is only 3.5M free??

I don't know, but for realistic Xmx values then 3.5M would mean that you 
are close to running out.

> 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.

Same.

> 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?

A Java program use more memory than the Java heap.

The JVM itself. Various native libraries. Stacks. For
older versions permgen. Etc.etc..

Arne

[toc] | [prev] | [next] | [standalone]

#35178

On 8/2/2016 5:49 PM, Arne Vajhøj wrote:
> On 8/2/2016 4:48 PM, 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.
>
> Given how small these values are then I am not surprised that you see
> funky results.

Just for fun try:

-Xms400M -Xmx800M

and see if you find Java's behavior more "matching expectations".

Arne

[toc] | [prev] | [next] | [standalone]

#35180

On Tue, 02 Aug 2016 22:48:59 +0200, Cecil Westerhof <Cecil@decebal.nl>
wrote:

>So the initial heap size will be 4 MB and the maximum will be 8 MB.
>But some strange things happen.

My guess is there a quite a bit of basic overhead that they don't
count in those numbers.  For example, caches, space for generated
machine code, space needed by the core jvm, scratch space needed for
GC.

Have a look at the task manager and how much free space it says you
have.  You might as well give great whacking hunks of it to Java.

[toc] | [prev] | [next] | [standalone]

#35182

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.
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web