Linux Documentation Project Guides 

The Linux Documentation Project (LDP) is working on developing good,
reliable documentation for the Linux operating system. The overall
goal of the LDP is to collaborate in taking care of all of the issues
of Linux documentation, ranging from online documentation (man pages,
HTML, and so on) to printed manuals covering topics such as
installing, using, and running Linux. Here is the Linux Documentation
Project Manifesto and
Copyright License for LDP works.

Translations of LDP works (languages other than
English) can be found on the "Non-English
Linux Info" links page.

Additional documentation (HOWTOs, FAQs, etc) can
be found here.

Older and unmaintained (but still pertinent)
guides can be found here.

Search the LDP documents from
our search page.

IntelliJ 7 was a bit unstable with JDK 1.6 on previous set of options I presented on this blog so I decided to tweak it again.

Here are the options I ended up with:

-Xms256m

-Xmx256m

-XX:MaxPermSize=150m

-XX:MaxGCPauseMillis=10

–XX:MaxHeapFreeRatio=70

-XX:+UseConcMarkSweepGC

–XX:+CMSIncrementalPacing

-Didea.no.jdk.check=true

This document describes some of the issues concerning the use of CSS to reformat Web documents for printing (using the media type "print"). We also discuss those aspects that CSS is not able to control or even influence. We assume a good knowledge of CSS and concentrate on practical issues, given the current deficiencies in browsers in implementing print-related CSS. For more basic tutorials and theory see "Other Sources" below. See also MediaStylesheets for practical media stylesheet strategies.

Two of the most common problems with printing occur when positioning other than static is used (e.g. position: absolute) or when there are floats. See the section below "Suggested strategy for page breaks".

Stripes-Quickstart










<script type="text/javascript">var dzone_url = 'http://www.stripesbook.com/blog/index.php?/archives/19-Stripes-Quickstart.html';</script>
<script type="text/javascript">var dzone_title = 'Stripes-Quickstart';</script>
<script type="text/javascript">var dzone_blurb = 'Stripes-Quickstart is an Ant script that speeds up the process of creating a new Stripes project.';</script>
<script type="text/javascript">var dzone_style = '2';</script>
<script src="http://widgets.dzone.com/widgets/zoneit.js" language="javascript"></script>





Stripes-Quickstart is an Ant script that speeds up the process of creating a
new Stripes project. Here is a summary of its features:



• Creates the project directory structure
  
• Downloads and copies the appropriate JAR files
  
• Generates a basic web.xml file
  
• Generates an action bean, a layout, and a simple page as a starting point
  
• Supports JSP/JSTL
  and FreeMarker
  
• Creates an Ant build.xml file for compiling and packaging the web application
  
• Creates a run target to run the web application in Jetty
  
• Creates an xml file that you can use to run the web application in Tomcat
  
• Creates ready-to-import Eclipse and NetBeans
  projects
  

Rule 0: Read a reputable paper on JVMs and micro-benchmarking. A good one is Brian Goetz, 2005. Do not expect too much from micro-benchmarks; they measure only a limited range of JVM performance characteristics.

Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s). (Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.)

Rule 2: Always run with -XX:+PrintCompilation, -verbose:gc, etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase.

Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase.

Rule 3: Be aware of the difference between -client and -server, and OSR and regular compilations. The -XX:+PrintCompilation flag reports OSR compilations with an at-sign to denote the non-initial entry point, for example: Trouble$1::run @ 2 (41 bytes). Prefer server to client, and regular to OSR, if you are after best performance.

Rule 4: Be aware of initialization effects. Do not print for the first time during your timing phase, since printing loads and initializes classes. Do not load new classes outside of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). Rule 2 is your first line of defense against such effects.

Rule 5: Be aware of deoptimization and recompilation effects. Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. Rule 2 is your first line of defense against such effects.

Rule 6: Use appropriate tools to read the compiler's mind, and expect to be surprised by the code it produces. Inspect the code yourself before forming theories about what makes something faster or slower.

Rule 7: Reduce noise in your measurements. Run your benchmark on a quiet machine, and run it several times, discarding outliers. Use -Xbatch to serialize the compiler with the application, and consider setting -XX:CICompilerCount=1 to prevent the compiler from running in parallel with itself.

Automated integration testing with Selenium, Maven and Jetty