Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Some Java questions



Thanks Daniel,
One question. I also understand that there is a maximum permanent heap
parameter, and that setting it too high could also cause problems. In
looking around, the Java heap consists of a permanent, tenured, and young
section. I'm not 100% sure how the JVM differentiates between these. I
would assume that the Permanent heap would be essentially the equivalent of
the C/C++ initialized data section that contains data elements created at
load time.

Also what about the thread stack. I'm not sure how much recursion we have
in the code, but I have not heard of any stack corruption issues with the
product.

One issue is that we don't run java directly. we set parameters (usually in
XML) that are passed to Java through scripts. Essentially, the product runs
as a Web Application using Tomcat.

On Thu, Oct 25, 2012 at 10:50 AM, Daniel Hagerty <hag at linnaean.org> wrote:

> Jerry Feldman <gaf.linux at gmail.com> writes:
>
> > We have an important client-related Java issue. We are trying to
> reproduce
> > a client's problem, but they are using a very large host (96GB/8CPU) and
> we
> > just were able to upgrade a VM to 4CPUs and 64GB for this project. I
> would
> > like to know if there are any good run-time tuning parameters that my
> > coworker can set to use more of the memory. (We are using Java SE
>
>     Run java -X; it'll dump the help for the ("non-standard and subject
> to change without notice") -X options.
>
>     A couple of the memory related ones I've used before include:
>
>     -Xms<size>        set initial Java heap size
>     -Xmx<size>        set maximum Java heap size
>



-- 
--
Jerry Feldman <gaf.linux at gmail.com>
Boston Linux and Unix
PGP key id:3BC1EB90
Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org