background preloader

Java HotSpot VM Options

Java HotSpot VM Options
Please note that this page only applies to JDK 7 and earlier releases. For JDK 8 please see the Windows, Solaris, Linux and Mac OS X reference pages. This document provides information on typical command-line options and environment variables that can affect the performance characteristics of the Java HotSpot Virtual Machine. Unless otherwise noted, all information in this document pertains to both the Java HotSpot Client VM and the Java HotSpot Server VM. Categories of Java HotSpot VM Options Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Windows and Solaris & Linux. Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK. Some Useful -XX Options Default values are listed for Java SE 6 for Solaris Sparc with -server. The options below are loosely grouped into categories. Behavioral Options Related:  Java TroubleshootingMinecraft

Getting alerts when Java processes crash When bugs occur in the Java runtime environment, most administrators want to get notified so they can take corrective action. These actions can range from restarting a Java process, collecting postmortem data or calling in application support personnel to debug the situation further. The Java runtime has a number of useful options that can be used for this purpose. The first option is “-XX:OnOutOfMemoryError”, which allows a command to be run when the runtime environment incurs an out of memory condition. $ java -XX:OnOutOfMemoryError=”logger Java process %p encountered an OOM condition” … Syslog entries similar to the following will be generated each time an OOM event occurs: Jan 21 19:59:17 nevadadev root: [ID 702911 daemon.notice] Java process 19001 encountered an OOM condition Another super useful option is “-XX:OnError”, which allows a command to be run when the runtime environment incurs a fatal error (i.e., a hard crash).

Patent troll Un article de Wikipédia, l'encyclopédie libre. Un patent troll, (en français « chasseur de brevets » ou « troll des brevets »[1]) est, dans le domaine de la propriété intellectuelle, et plus précisément dans celui de la concession de licences (Licensing), le nom donné à une société ou à une personne physique, qui utilise la concession de licence et le litige de brevets comme principale activité économique. Cette notion fait aujourd'hui l'objet de nombreux articles universitaires, ce qui s'accompagne d'un usage de plus en plus fréquent par les cours de justice[2]. Étymologie[modifier | modifier le code] La dénomination patent troll a été utilisée dès 1993 pour décrire les entreprises qui intentent de multiples procès pour violation de brevet[3]. L'expression a été popularisée par Peter Detkin en 2001 lorsqu'il travaillait pour Intel[4]. Activité[modifier | modifier le code] pour ses détracteurs[modifier | modifier le code] pour ses défenseurs[modifier | modifier le code]

How to get java thread dump Опции JVM. Как это работает С каждым днем слово java все больше и больше воспринимается уже не как язык, а как платформа благодаря небезызвестному invokeDynamic. Именно поэтому сегодня я бы хотел поговорить про виртуальную java машину, а именно — об так называемых Performance опциях в Oracle HotSpot JVM версии 1.6 и выше (server). Потому что сегодня почти не встретить людей, которые знают что-то больше чем -Xmx, -Xms и -Xss. В свое время, когда я начал углубляться в тему, то обнаружил огромное количество интересной информации, которой и хочу поделится. Отправной точкой, понятное дело, послужила официальная документация от Oracle. А дальше — гугл, эксперименты и общение: -XX:+DoEscapeAnalysis Начну, пожалуй, с самой интересной опции — DoEscapeAnalysis. Про то, как работает сам алгоритм можно прочитать тут (PDF). Следует уточнить, что на стеке создается не сам объект а его поля. Вполне очевидно, что благодаря такого рода анализу, производительность отдельных частей программы может возрасти в разы. -XX:+AggressiveOpts

City Life More Odds and Ends of Hprof heap dump format Hprof binary file format is back in my head again, as I consider whether to use it as a native heap dump format. When I wrote about it previously, I was more interested in how to parse it. Now I must consider its strengths and limitations. Strengths Format widely supported by profilers and heap analyzers. Written by the JVM directly and the hprof agent. Compact encoding of both primitive and reference fields. Hprof class and object identifiers are stable for multiple heap dumps written in the same JVM lifetime. The JVM implementation is very fast. The hprof implementation is very readable, excellent code. Weaknesses The JVM uses machine addresses as object identifiers, which change with every gc, so two heap dumps from the same JVM can't be compared object-wise. JVM heap dumps consistently have dangling references to objects that are not reported in the heap dump and, even if -live is specified, objects that are unreachable from any root. Conclusion

Tomcat - Shutdown port On a new installation of Tomcat (default config files), you'll notice that your server.xml file is set up with a shutdown port of 8005, and shutdown="SHUTDOWN". What does this mean? It means that anyone who contacts the server locally on port 8005 and send it the words SHUTDOWN can cause Tomcat to close out all its web applications and shut down cleanly. If your Tomcat server allows anyone except the administrator to log in with a shell, then I strongly suggest you change shutdown="SHUTDOWN" to shutdown="waSS-I41tis" so that at least it won't be a string that any hacker can guess. waSS-I41tis => "what a STUPID SYSTEM - I for one think it's silly" (written 2006-08-18) Associated topics are indexed as below, or enter for individual articles A654 - Web Application Deployment - Configuring and Controlling Tomcat [3043] Gathering information - logging - with log4j. Some other Articles

How to Tune Java Garbage Collection This is the third article in the series of "Become a Java GC Expert". In the first issue Understanding Java Garbage Collection we have learned about the processes for different GC algorithms, about how GC works, what Young and Old Generation is, what you should know about the 5 types of GC in the new JDK 7, and what the performance implications are for each of these GC types. In the second article How to Monitor Java Garbage Collection I have explained how JVM actually runs the Garbage Collection in the real time, how we can monitor GC, and which tools we can use to make this process faster and more effective. In this third article based on real cases as our examples I will show some of the best options you can use for GC tuning. Is GC Tuning Required? Or more precisely is GC tuning required for Java-based services? The memory size has been specified using -Xms and –Xmx options.The -server option is included.Logs such as Timeout log are not left in the system. Decreasing Full GC Time 1. 2.

Improving your Minecraft server’s performance Understanding how your server ticks underneath can be helpful when diagnosing problems regarding slow performance. We’ll cover several topics. An overview of the game logic loopHow this all applies to modded serversAn explanation of transient problemsA guide to profiling your serverA macro-view of improving performance The game logic loop The most important part of Minecraft is the game loop. Quite a few things are on the to-do list, but as far as the “main game elements” go, those items are blocks, entities, and tile entities. Usually on an un-loaded server, it works out and you have a nice slice of idle time, but what happens when it doesn’t “work out?” Fundamentally, the problem is that of “too many items” with “each item taking 10 nanoseconds too long.” Reduce the number of entities and blocks loaded at any time.Optimize the code for each block or entity to do more in less time. Reducing numbers How do you go about reducing numbers? Unload chunks more often and more reliably.

Joshua Bloch: Performance Anxiety – on Performance Unpredictability, Its Measurement and Benchmarking Joshua Bloch had a great talk called Performance Anxiety (30min, via Parleys; slides also available ) at Devoxx 2010, the main message as I read it was Nowadays, performance is completely non-predictable. You have to measure it and employ proper statistics to get some meaningful results.Microbenchmarking is very, very hard to do correctly. No, you misunderstand me, I mean even harder than that! There has been another blog about it but I’d like to record here more detailed remarks. Today we can’t estimate performance, we must measure it because the systems (JVM, OS, processor, …) are very complex with many different heuristics on various levels and thus the performance is highly unpredictable. Example: Results during a single JVM run may be consistent (warm-up, then faster) but can vary between JVM executions even by 20%. “Benchmarking is really, really hard!” Joshua mentiones a couple of interesting papers, you should check the slides for them. Personal touch Conclusion

Apache Tomcat - Apache Tomcat 6 Downloads Welcome to the Tomcat 6.x download page. This page provides download links for obtaining the latest version of Tomcat 6.0.x, as well as links to the archives of older releases. You must verify the integrity of the downloaded files. You are currently using Please see the README file for packaging information. Source Code Distributions Understanding CMS GC Logs (Poonam Bajaj) CMS GC with -XX:+PrintGCDetails and -XX:+PrintGCTimeStamps prints a lot of information. Understanding this information can help in fine tuning various parameters of the application and CMS to achieve best performance. Let's have a look at some of the CMS logs generated with 1.4.2_10: 39.910: [GC 39.910: [ParNew: 261760K->0K(261952K), 0.2314667 secs] 262017K->26386K(1048384K), 0.2318679 secs] Young generation (ParNew) collection. 40.146: [GC [1 CMS-initial-mark: 26386K(786432K)] 26404K(1048384K), 0.0074495 secs] Beginning of tenured generation collection with CMS collector. Capacity of tenured generation space is 786432K and CMS was triggered at the occupancy of 26386K. 40.154: [CMS-concurrent-mark-start] Start of concurrent marking phase. 40.683: [CMS-concurrent-mark: 0.521/0.529 secs] Concurrent marking took total 0.521 seconds cpu time and 0.529 seconds wall time that includes the yield to other threads also. 40.683: [CMS-concurrent-preclean-start] Start of precleaning. Start of reset.