Re: Heap limits in OS X

------=_Part_7603_157282814.1317698035467
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 14, 2011 at 10:58 PM, Tom Morris <[email protected]> wrote:

> Hi Jack.  It's been a while since I coded this up, but
> On Wed, Sep 14, 2011 at 8:53 PM, Jack Repenning <[email protected]>
> wrote:
> > I suppose a "warn at 500 for a limit of 600" is not unduly alarmist =E2=
=80=A6 but
> I gave it 1024, not just 600, why's it whining at me?
>
> I hope it's not whining too loudly, but, as I remember it, the orange
> line limit is arbitrary (ie picked out of the air by me) and full
> scale on the graph is the *current* (not max) heap size.  Typical JVM
> behavior is for heap allocations to ratchet up towards some limit
> (e.g. 90% of the current heap) which triggers a garbage collection and
> when heap usage stays too close to the total heap size for a period of
> time to increase the size of the heap (by asking the O/S for more
> memory) and, finally, when the heap has been expanded as much as
> possible, to give an OutOfMemory error.
>
> > Should I have set this elsewhere? Should I adjust my execrations? Are
> there things (like, say, extensions) I can remove to free some heap?
> >
> > And, is this heap usage reasonable? I only have one diagram (a Sequence
> diagram), with four Classifiers, and 22 Actions.
>
> Pretty much impossible to say without more info.

...


> The real warning size to watch for is that the heap indicator, instead
> of going from 90% to 50% continually, stays pegged at 90%+ (which will
> also mean that you've maxed out your heap expansion opportunities.
>
> With the limited time I have available to commit, I'm much more
> focused on ArgoEclipse than ArgoUML, but I'd be happy to tweak the
> current implementation of the heap monitor dispaly if folks can come
> up with a consensus for a more valuable display (e.g. don't show the
> alarming orange color at whatever the threshold is set at).


 So, I reviewed the implementation recently because I wanted to reuse
aspects of it for Google Refine.

Despite the lack of feedback on the current implementation, I've tweaked th=
e
display protocol to use the max possible heap size, as opposed to the
current allocated heap size for the full range display.  This will sometime=
s
be misleading since the operating system may not honor requests for memory
up to the max size, but, hopefully, it should be accurate more often than
the previous implementation (particularly in these days of copious RAM).

Tom

------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=3D449&dsMessageId=3D2=
849681

To unsubscribe from this discussion, e-mail: [[email protected]=
ris.org].
------=_Part_7603_157282814.1317698035467
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Sep 14, 2011 at 10:58 PM, Tom Morris <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]">[email protected]=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Jack. =A0It&#39;s been a while since I coded this up, but<br>
<div class=3D"im">On Wed, Sep 14, 2011 at 8:53 PM, Jack Repenning &lt;<a hr=
ef=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br=
>
&gt; I suppose a &quot;warn at 500 for a limit of 600&quot; is not unduly a=
larmist =85 but I gave it 1024, not just 600, why&#39;s it whining at me?<b=
r>
<br>
</div>I hope it&#39;s not whining too loudly, but, as I remember it, the or=
ange<br>
line limit is arbitrary (ie picked out of the air by me) and full<br>
scale on the graph is the *current* (not max) heap size. =A0Typical JVM<br>
behavior is for heap allocations to ratchet up towards some limit<br>
(e.g. 90% of the current heap) which triggers a garbage collection and<br>
when heap usage stays too close to the total heap size for a period of<br>
time to increase the size of the heap (by asking the O/S for more<br>
memory) and, finally, when the heap has been expanded as much as<br>
possible, to give an OutOfMemory error.<br>
<div class=3D"im"><br>
&gt; Should I have set this elsewhere? Should I adjust my execrations? Are =
there things (like, say, extensions) I can remove to free some heap?<br>
&gt;<br>
&gt; And, is this heap usage reasonable? I only have one diagram (a Sequenc=
e diagram), with four Classifiers, and 22 Actions.<br>
<br>
</div>Pretty much impossible to say without more info.</blockquote><div>...=
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The real warning size t=
o watch for is that the heap indicator, instead<br>

of going from 90% to 50% continually, stays pegged at 90%+ (which will<br>
also mean that you&#39;ve maxed out your heap expansion opportunities.<br>
<br>
With the limited time I have available to commit, I&#39;m much more<br>
focused on ArgoEclipse than ArgoUML, but I&#39;d be happy to tweak the<br>
current implementation of the heap monitor dispaly if folks can come<br>
up with a consensus for a more valuable display (e.g. don&#39;t show the<br=
>
alarming orange color at whatever the threshold is set at).</blockquote><di=
v><br></div><div>=A0So, I reviewed the implementation recently because I wa=
nted to reuse aspects of it for Google Refine.</div><div><br></div><div>
Despite the lack of feedback on the current implementation, I&#39;ve tweake=
d the display protocol to use the max possible heap size, as opposed to the=
 current allocated heap size for the full range display. =A0This will somet=
imes be misleading since the operating system may not honor requests for me=
mory up to the max size, but, hopefully, it should be accurate more often t=
han the previous implementation (particularly in these days of copious RAM)=
.</div>
<div><br></div><div>Tom</div></div>

------=_Part_7603_157282814.1317698035467--