The Java™ language is the target of a lot of abuse for performance. And while some of it may well be deserved, a tour of message board and newsgroup postings on the subject shows that there is a great deal of misunderstanding about how a Java Virtual Mach
Tutorial Details:
Which language boasts faster raw allocation performance, the Java language, or C/C++? The answer may surprise you - allocation in modern JVMs is far faster than the best performing malloc implementations.
You don't have to search through too many blogs or Slashdot postings to find confidently worded statements like "Garbage collection will never be as efficient as direct memory management." And, in a way, those statements are right -- dynamic memory management is not as fast - it's often considerably faster. The malloc/free
approach deals with blocks of memory one at a time, whereas the garbage collection approach tends to deal with memory management in large batches, yielding more opportunities for optimization
This "plausibility argument" -- that it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day -- is borne out by the data. One study (Zorn; see Resources) also measured the effects of replacing malloc with the conservative Boehm-Demers-Weiser (BDW) garbage collector for a number of common C++ applications, and the result was that many of these programs exhibited speedups when running with a garbage collector instead of a traditional allocator. (And BDW is a conservative, nonmoving garbage collector, which greatly constrains its ability to optimize allocation and reclamation and improve memory locality; exact relocating collectors such as those used in JVMs can do far better.)
A generational garbage collector divides the heap into multiple generations; most JVMs use two generations, a "young" and an "old" generation. Objects are allocated in the young generation; if they survive past a certain number of garbage collections, they are considered "long lived" and get promoted into the old generation.
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Java theory and practice: Urban performance legends, revisited
View Tutorial: Java theory and practice: Urban performance legends, revisited
Related
Tutorials:
 Programming Java threads in the
real world, Part
1 - JavaWorld -
September 1998
Programming Java threads in the
real world, Part
1 - JavaWorld -
September 1998
|
The Java HotSpot
Performance Engine is set to break new records - JavaWorld
The Java HotSpot
Performance Engine is set to break new records - JavaWorld
|
Build an object database, Part 2: Object storage
backend - JavaWorld April 2000
Build an object database, Part 2: Object storage
backend - JavaWorld April 2000
|
Java threads may not use all your CPUs - JavaWorld August 2000
Java threads may not use all your CPUs - JavaWorld August 2000
|
Tweak your IO performance
for faster runtime - JavaWorld November
2000
Tweak your IO performance
for faster runtime - JavaWorld November
2000
|
Double-checked
locking: Clever, but broken - JavaWorld February
2001
Double-checked
locking: Clever, but broken - JavaWorld February
2001
|
J2ME: The next
major games
platform? - JavaWorld March 2001
J2ME: The next
major games
platform? - JavaWorld March 2001
|
Performance books put to the test - JavaWorld March 2001
Performance books put to the test - JavaWorld March 2001
|
Pushlets: Send
events from servlets to DHTML client browsers
Pushlets: Send
events from servlets to DHTML client browsers
|
High-availability mobile applications
High-availability mobile applications
|
Fixing the Java Memory Model, Part 2
Writing concurrent code is hard to begin with; the language should not make it any harder. While the Java platform included support for threading from the outset, including a cross-platform memory model that was intended to provide \"Write Once, Run Anywh
|
Fixing the Java Memory Model, Part 1
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM).
|
JView 2004 - J2EE Performance Management Software - Version 1.4
JView 2004 Enterprise Edition available now!
JView 2004 is the leading J2EE Production Performance Monitor and Java Performance Tuning solution, providing precise real-time performance metrics to assist you in ensuring your performance requirements a
|
JView 2004 2.1 Released - J2EE Performance Profiler
JView 2004 J2EE Performance Tuning and Monitoring Enterprise Edition Trial Download
|
new
Version 0.9.3 of the Quake2 Java port Jake2
With the new Jake2 release 0.9.3 savegames are working. So you can take a break on your mission.
|
Servlet and JSP performance tuning
Servlet and JSP performance tuning
This article describes performance-tuning techniques (PTT) for developing high performance and scalable JSP (JavaServer Pages) pages and servlets. That means building applications that are reasonably and consistently fa
|
PDFTextStream v1.1.2 Released; Fast Java PDF Text Extraction
PDFTextStream is the ideal solution for Java applications and J2EE web services that need to rapidly and accurately extract text and document metadata from PDF files.
|
Access Windows Performance Monitor counters from Java, Part 1
Access Windows Performance Monitor counters from Java, Part 1
Use a simple Java API to gather valuable performance statistics
Summary
Windows NT, 2000, 2003, and XP contain a utility called the Performance Monitor that provides a rich array of perform
|
Write custom appenders for log4j
The Apache Software Foundation's log4j logging library is one of the better logging systems around. It's both easier to use and more flexible than Java's built-in logging system.
|
Java theory and practice: Generics gotchas
Generic types, added in JDK 5.0, are a significant enhancement to type safety in the Java language. However, some aspects of generics may seem confusing, or even downright bizarre, to first-time users. In this month's Java theory and practice, Brian Goetz
|
|
|
|
