Re: How can I see memory used by Java?
Nathan Meyers wrote: > BTW, I haven't seen any evidence that the JVM gives memory back > to the system. Doing such a thing isn't impossible, but it is > difficult; OTOH, systems with garbage-collection are those most > able to implement such a capability. This was added to JDK 1.1.8. From the 1.1.8 release notes: > HEAP EXPANSION AND SHRINKAGE - Four new command-line options have > been added to the java application launcher that allow control of > garbage- collected heap expansion and shrinkage. The new options are > -maxe, -mine, -maxf, and -minf. These options were added as a fix > for bugd> 4065018. Check the descriptions for the -maxe, -mine, -minf, and particularly the -maxf options for further details about the conditions under which heap is returned to the OS. Perhaps these have made it into the Blackdown 1.2.2 RC2; though I doubt it since I don't see any mention of these options or their -X equivalents even in the Windows or Solaris 1.3 Betas and I don't recollect any mention of heap contraction in other 1.2 documentation. Only those with access to the garbage collector source would know for sure. By the way, the IBM JDK 1.1.8 for Linux claims to support these options. -- Jonathan Doughty The MITRE Corporation [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Advanced Imaging availability on Linux
Jacob Nikom wrote: > However, when I looked at JAI web site and found they have only > downloads for Solaris and Windows. Why in this case they have special > distribution? Is it possible to use them on Linux? Is it pure Java > stuff? The GZIP format implementation bundle on the JAI site is just a standard Gzipped tar archive. That does contain some Solaris native .so libraries that are supposed to end up in the JDK 1.2 jre/lib/sparc directory. Running JAI applications on Linux should just ignore those though I suppose you could remove them as unecessary. JAI is set up to fall back to pure Java implementations when native implementations (presumably residing in jre/lib/i386 on Intel/Linux) are not available. It should work okay on Linux (modulo JDK 1.2 incompleteness), just more slowly than it might. Of course, I haven't actually tried this yet, so YMMV. -- Jonathan Doughty The MITRE Corporation [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Terrible native thread performance
Daniel Stux wrote: > Here is what I see with Linux. I am running on a freshly installed > RedHat 6.1 machine. With either JDK, running in native threads is > absolutely crippling. There seems to be a serparate JDK process ID > for each running thread, or otherwise something is casuing it to > fork 15 times. Of these threads four or five of them just hammer the > CPU, leaving the whole machine at a crawl. Actual performance of our > Java GUI isn't too bad, but it's no where near where it should be. You are seeing an artifact of the Linux threading model: native Java threads are mapped onto kernel threads and kernel threads look a lot (to ps and friends) like separately forked processes. As for your four or five CPU hammers; that may be a Java problem, a Linux problem, or a Java/Linux problem but it is hard to say without more details from you. For a *really* good analysis (IMHO) of Java / Linux threading issues, kernel tweaks that can improve the situation, and what we might be seeing in the 2.4 kernels unless the Linux kernel powers that be address the situation, see the recently published paper: Java, threads, and scheduling in Linux Patching the kernel scheduler for better Java performance at http://www-4.ibm.com/software/developer/library/java2/index.html Recommended reading; the Java on Linux situation really needs this kind of work. (Speaking only for myself.) -- Jonathan Doughty The MITRE Corporation [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sun JDK 1.3.0 RC
Note the Java[TM] 2 Platform, Standard Edition (J2SETM), v 1.3 for Linux, Release Candidate on http://developer.java.sun.com/developer/earlyAccess/j2sdk13/download-linux.html Cafe au Lait says "There aren't any new features here, just bug fixes and performance improvements." Still, some interesting results when compared to IBM's current service refresh of August 18. Fellow Linux aficionados, assuming the final version doesn't take anything away from the release candidate, we are about to have two (or maybe make that three when one considers jitc, HotSpot Client, and HotSpot Server) winners here. Congratulations Sun, and thank you. -- Jonathan Doughty The MITRE Corporation [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use Java options -Xms and -Xmx on Linux?
>>>>> "Timothy" == Timothy Reaves <[EMAIL PROTECTED]> writes: >> Q2: is there any upper limit for -Xms and -Xmx values, or can >> I use whatever value I want such as -Xms700m and >> -Xmx2g (suppose "m" and "g" are available)? > There is no upper limit. Au contraire. There is not _supposed_ to be, no. But, in fact, on current 32-bit Linux systems there is a 2GB limit. See http://developer.java.sun.com/developer/bugParade/bugs/4435069.html The same holds true on Solaris for Intel. See http://developer.java.sun.com/developer/bugParade/bugs/4385914.html On other platforms, Solaris on SPARC, at least, there is not supposed to be a limit. But once again, it doesn't work for me, at least not with the latest 1,3,1RC2. On a 64-bit enabled Solaris 8 system with 4GB, top indicates: => Memory: 4096M real, 3801M free, 8002M swap free and we get: => $ ./j2sdk1_3_1sparc/bin/java -version => java version "1.3.1-rc2" => Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc2-b23) => Java HotSpot(TM) Client VM (build 1.3.1-rc2-b23, mixed mode) but if we try: => $ ./j2sdk1_3_1sparc/bin/java -mx2g -version => Error occurred during initialization of VM => Could not reserve enough space for object heap Of course, one would like to actually run an application that uses more than 2GB, not just check the version number. Those fail for me too. It is easy to write a C program that can malloc more, but java doesn't seem to like anything over around -mx1800m (yet.) The bug reports seem to indicate it is a HotSpot limitation. Note that those bug reports claim to be "closed, fixed", but the text of the latter report seems to indicate the fix may be to documentation noting the limitation. The latter hints at some intrinsic limitations on Windows. Meanwhile I'm trying to refactor our application to get by with less. -- Jonathan DoughtyThe MITRE Corporation[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM and threads
> "Mauricio" == Mauricio Nuñez <[EMAIL PROTECTED]> writes: > Thanks for your answers! > Well, i will need to wait for a back port from kernel 2.5 to 2.4 ... > I'm trying to get a better performance with Tomcat (a servlet > container). > The servlet spec say '1 request: 1 thread', then with high concurrent > requests, my server is less responsive. You could try BEA's (formerly Appeal's) JRockit VM for Linux. http://www.bea.com/products/weblogic/jrockit/index.shtml The -Xthinthreads option claims to provide some benefits. I've no extensive practical experience with their VM but it is nice to have additional options to try. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using more than 2 gigs with Java on Linux?
I knew this was out there somewhere (since I submitted the related bug) but finding this was quite a bear. http://developer.java.sun.com/developer/bugParade/bugs/4385914.html > Support for large heaps not present in Ladybird solaris i386 client & server > Category java:doc > Reported Against ladybird, 1.3 > Release Fixed ladybird-beta > State Closed, fixed > Related Bugs 4401509 But the fix is to document the restriction that > The mmap system call on x86 and non-64-bit enabled solaris will fail > with ENOMEM for sizes greater than MAXOFF_T which is 0x7ff. Can't say I can find where the documentation was fixed, either. -- Jonathan DoughtyThe MITRE Corporation[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using more than 2 gigs with Java on Linux?
>>>>> "Nelson" == Nelson Minar <[EMAIL PROTECTED]> writes: >> I knew this was out there somewhere (since I submitted the related >> bug) but finding this was quite a bear. >> http://developer.java.sun.com/developer/bugParade/bugs/4385914.html > Hmm, this seems to be related to Solaris x86. And the answer is "you > can't do more than 2 gigs". I have in the back of my mind you *can* do > this somehow, so I'm not sure this is my answer. My understanding was that the issue is Intel architecture related, not just Solaris specific. I seem to recall going down this path before but I couldn't find the definitive bug parade description; the one I cited above was the nearesty I could get. The bug description says: > SPECIAL NOTE: Does the documentation note the limitation of support > in win98/NT and some win2000 release? What about linux, should this > workas well? If a customer uses -Xmx3g on win98, do we tell them > that large heap support is not valid for this OS. which is sort of ambiguous as well though hints at the issue. My foggy memory recalls something about the Intel architecture not being able to reliably return contiguous large enough memory segments for HotSpot to do its job. Not in the related bug http://developer.java.sun.com/developer/bugParade/bugs/4401509.html that someone claimed IBM's 1.3.0 implementation was able to use more than 2gb. Also note that IBM recently released their 1.4.0 implementation: http://www-106.ibm.com/developerworks/java/jdk/linux140/ Don't know about BEA's JRockit off hand. -- Jonathan DoughtyThe MITRE Corporation[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
