Hi Kirk,
Java heap allocations will fragment the C Heap. PermGen memory
will fragment the C Heap. JIT Compilations will fragment the C Heap.
Java Thread creations/destruction will fragment the C Heap.
PermGen and Java Heap I can do something about. Sorry, but my answer
is still that for a memory intensive application you should be setting
your memory settings properly to get the most out of your 32 bit
memory space.
When setting the -Xms -Xmx to be the same at startup, I get 2-3 very
clean 1GB memory allocations in my process memory space. If you don't
set -Xms, then your process memory space is littered with smaller
memory allocations over the course of the process runtime. If your
blog doesn't tackle why keeping my memory space ultra clean is a bad
idea then it will not win me over.
We are both entitled to our opinion:-) I don't think we need to
continue to hi-jack this thread any further. Hopefully the parent
resolved his issue.
Thanks,
Anthony
On Tue, Mar 29, 2011 at 6:34 PM, Kirk <[email protected]> wrote:
> Hi Anthony,
>
> Setting ms to mx is a tuning/configuration mistake in most cases. I have a
> blog entry that explains this (Keep your hands off of the switches iirc) and
> I've another one in the pipe that very clearly exposes why you should rarely
> set mx == ms.
>
> Java heap is taken from C heap. C heap is stacked on the back of stack space
> in Windows and Linux. That means stack and text areas are fixed in size at
> startup. If by native memory you are talking about C heap, then point taken.
> That said, most Java applications should not require a lot of native space
> unless they are using direct byte buffers (aka the newest version of EHCache)
> or objects that create structures in C heap (eg. file/socket descriptors).
>
>>
>> The fact that the 10th thread gets an error and thread creation is
>> fine after that does sound like some sort of OS or Java bug as sebb
>> mentioned. Hopefully the parent can make sure that he is using the
>> most recent JVM and see if the problem still occurs.
>
> This is a strange one for sure. I'd be looking in the bug database to see
> whats going on. One of the things that sometimes happens is that problems
> with the LD_LIBRARY_PATH case the JVM to be constructed with the wrong
> versions of shared libraries. Though normally this causes the JVM to core
> dump, I guess it could cause other (strange) behaviors in the JVM.
>
> Regards,
> Kirk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
