Java, GC - object layout thoughts

Just some very draft thoughts - would it be possible to approach some of well-known GC-related memory problems by simply separating structure and data? What I mean is navigational links of an object, i.e. references to other objects, can be kept aside of the flat data associated with the object. In that case structural part of all objects will constitute a smaller memory region compared to the one created by how it is done currently. This may probably improve the efficiency of GC since the collector would need to scan smaller memory spaces with closer reference locality.
The data region would likely need lighter collection algorithms than it currently does. However, a certain side-effect of the approach is that the run-time would have to do an extra navigation every time when a reference has to be resolved into the corresponding data.
UPD 2012-07-16 Here is another experimentally-proven approach which relies on separating of pointer and data values at a finer grain. The key idea is again in that the pointer-data separation allows for building very efficient garbage collection algorithms.

Follow-up: Why I consider these features missing in Java

Some time ago I created a list of features I consider missing in the current Java implementation. As I recently realized it makes sense to provide reasoning for some of them to be in the list.

Eclipse CDT crashes on jdk1.6.0_23/24

Just came across a known bug with the latest JVM releases 1.6.0_23 or 24 - Eclipse CDT crashes on start-up. Solution is to add -XX:-UseCompressedOops in the eclipse.ini file.
Oracle tracks the problem in this record. According to it a fix will be delivered with 1.6.0_25.

Oracle: PL/SQL vs Java - one unconventional question

All the time since the introduction of Java engine within Oracle RDBMS people have been wondering how performance of Java stored procedures compare to orthodox ones written in PL/SQL. There are lots of performance tests demonstrating where things stand. Surprise! I am not going to discuss it here. What I am really curious about is what we may expect in future. Might it happen that one day PL/SQL will be fully replaced with the Java engine?

jvisualvm from jdk1.6.0_22 crashes on my Vista x64

Just discovered that jvisualvm.exe from jdk1.6.0_22 crashes with no apparent reason while starting up on my Vista x64 laptop. This is quite weird as yesterday I managed to start it many times without a problem, although there were two or three crashes. Not sure what has happened. Assuming that some of plug-ins may be corrupt I tried to remove the configuration under Application Data\.visualvm\6u20 folder. It started well a few times then again rejected to start. The same utility from jdk1.6.0_16 seems to operate well.
I am going to upgrade to jdk1.6.0_23 and see whether it solves the problem.

UPD Seems it is more stable in jdk1.6.0_23.
UPD #2 Here VisualVM dev team mention a Java bug that affects 64bit systems and they suggest adding "-J-Dsun.java2d.d3d=false" to the command line as a solution.
UPD #3 In JDK1.6.0_23 this option is already provided by default in ${JDK_HOME}\lib\visualvm\etc\visualvm.conf.

Why no ClassShutter in Java6 JS engine?

There is one thing about Java6 I am in a way baffled by. As far as I remember the JavaScript scripting engine in Java6 has been based on Mozilla Rhino. How did it happen that the implementation in Java6 is missing the original Rhino functionality for restricting the set of classes that may be loaded by a script?

I assume the feature has been replaced by allowing a custom implementation of java.lang.ClassLoader in one of javax.script.ScriptEngineManager constructors. This offers unlimited flexibility for other scripting engines that might be plugged in the JVM instance. Then another question - is there any built-in ClassLoader in Java6 that supports class filtering? Because of safety reasons it is quite natural to limit the set of classes loadable by scripting extensions. However it seems there is no standard or default way to do that. So everybody willing to ensure better control over the extension scripts has to build their own implementation of essentially the same functionality. Not quite encouraging.

JPA + Hibernate: optimizing queries on a many-to-many relationship

Following up a discussion (in Russian) on a developers' forum on advanced querying against many-to-many mapping in JPA I have compiled all my findings in this post. I intentionally leave all object and database names close to the original maybe with minor changes.

Servlets vs Messaging

Being kind of not a big fan of Web development I wonder what is so special about Servlets that requires a separate API to use them?

Integer.valueOf(): a few facts

Integer.valueOf(int x) added since Java 1.5 has one interesting feature - it resolves all incoming int values through a cache so to minimize the number of java.lang.Integer instances in application by re-using the cached values. This cache is also configurable with a system property java.lang.Integer.IntegerCache.high which is used to define the upper bound to populate the cache to. The minimum value is hard-coded and it is -128.

Surprisingly the upper bound for java.lang.Long, where a similar cache also exist, is hard-coded to 127 and is not at all configurable.

My list of features missing in Java

It is a very common question on interviews about what features you consider missing and would like to add to Java. Here is my list:

• C#-style properties accessible as such via reflection;
• C#-style yield keyword;
• C#-style as keyword;
• Get rid of java.util.Date hell - will require changes in java.sql as well;
• Function objects, specifically for bulk processing on collections; implies C#-style delegates;
• modularity, e.g. OSGi-like bundling - no jar-hell;
• Annotation-based configuration for JavaBeans, again, like it is done in .NET System.ComponentModel; extensive support in Swing;
• Something similar to org.springframework.util.Assert class for common runtime checks;
• Human-oriented Generics;
• Byte-code emitter API;
• Unified interfaces and compiler support for events like in .NET, free of known problems;
• One more feature would be nice to have - a user-defined context reference in java.lang.Class object. This would let keep all class-related extensions, e.g. persisters, serializers, validators, type descriptors, etc, acessible by simple navigation as opposed to keeping multiple mappings.
• Extremely useful feature - C#-style verbatim string literals (@"...") = multiline strings in Scala ("""...""");

UPD: I think I'd better provide some explanations why I deem these features to be missing.:-)

IBM eXtreme Scale vs ORMs

Ah, that's a solution I have also been thinking over for quite long time. Distributed object caching - that's the next generation platform for most applications. I am sure this is one of the most interesting areas to work in. Shall I seek for opportunities with IBM, maybe? :)

Thoughts on validation

Would I miss anything if I guess that a validation rule applied to a single entity can be either of the two:

1. An extention to a standard general-purpose type like int, double, String, etc that constrains the domain of possible values to the actual business domain. When I declare a String property as not null and having at most 16 characters, I actually give a hint to the framework to force the corresponding restriction on assigned values. Alternatively I could probably declare a new type like NonNullString16 and use it instead. Possibly a good example is the price of some asset that should never be less than zero. This requirement can be captured by NonNegativeDecimal type or even more specialized AssetPrice type. However, building a custom type for every particular situation seems rather irrational and hardly doable in most cases dut to a number of technical problems.
2. A complex check on several properties correlated by some law. Examples:
   for an employee the graduation date cannot precede the date of birth, for a market quote bid price cannot be higher than offer price, the number of idle resources cannot exceed the overall pool size, etc.

There is also sort of mess in SQL where #1 maps to NOT NULL constraint and size restriction on the column data type, and #2 is reflected by a CHECK constraint. Or is it a mess at all?

From Java constructors to domain-driven design concepts

Interestingly, a constructor in Java can be thought of as a callback method which is to be invoked upon instance allocation.

Entity metadata: Java vs XML

The architecture of the last multi-tier project I worked for included a bunch of C# frontends connecting to a few Java services. There were a number of business domain entities. The state of almost every entity was continuously mutated.

Gory details of java.lang.String interning

While exploring through the JDK source code today I came to some degree of understanding of how interned strings are treated by garbage collector (GC).

In the first versions of java interned strings were not collected at all. They were accumulated in the PermGen so it was quite possible to very quickly end up with OutOfMemory (OOM) exception when abusing intern() call. The current version of JVM uses a smarter way to maintain the string cache.

Opposed to some people saying that strings are kept as weak references the actual approach is different. During the first part of mark-and-sweep phase GC delegates to the static string table (a specialization of Hashtable) to get rid of all non-alive entries. These entries are not deleted but relinked instead from the hashtable bucket (the linked list they reside in) to the linked list of free entries (revise

   BasicHashtable::free_entry(BasicHashtableEntry* entry)← 
   void Hashtable::unlink(BoolObjectClosure* is_alive)←
   StringTable::unlink(BoolObjectClosure* cl)

call chain for details)
One important observation here is that memory taken by a freed entry is not deallocated. That means the more non-identical strings are interned by the application the more PermGen memory is consumed. Correspondingly if the JVM string table is too intensively used, for example, by attempting to cache too many non-identical strings it is easy to cause OOME. While in a case where the cached strings are known to have big percentage of duplicates interning along with fine tuning of PermGen may significantly reduce the overall memory consumption.

Tribute to C++

It's been a long time since I last did anything in c++. After many years with Java and C# I don't really feel like fiddling with tons of headers and source files without a really good fast navigation between the types, methods, etc. One of the biggest advantages of Java/C# is that declaration and implementation are combined in one source file. That greatly simplifies navigation and refactoring (unless, of course, the application is designed that badly that it stops you from making any changes in a reliable fashion).
However, the knowledge of C++ still appears to be extremely helpful, for instance, when I need to clarify some details of JVM operation. Every time a question comes for which there is no good answer readily available (e.g. does JVM really apply any optimizations to final methods?) I'd better dig into JVM source code rather than wasting my time on reading many controversial opinions on the question. After all it is just a waste of time trying to understand who's right, who's wrong. So usually a better option is to make it certain by yourself.

P.S. JVM does apply optimizations to a final method. For example, see Parse::optimize_inlining(), ciMethod::find_monomorphic_target(), methodOopDesc::can_be_statically_bound() methods (JDK6-6u18 sources). And understanding if these optimizations may really boost your application performance is best assessed with testing. That's the only reliable approach.

Benchmarking Java method performance

Very often there is a need to make a quick estimation of which of several method implementations performs better. A typical question is how many fractions of second it would take for a single invocation to complete. With Java (and any other JIT-based virtual machines) the estimation is especially difficult as certain number of initial invocations may be done in the interpreted mode with later switching to the compiled form plus some other optimizations may occur. Sometimes though the exact call duration may not be of much interest. We'd rather find out which implementation performs significantly better by comparing the performance in a simulated usage scenario. For that purpose I wrote a few classes that can facilitate that micro-benchmarking.

Parsing command-line options - part 4

This is the last part of the story. This time we will search for a way to make our annotation work.

A hint for indenting with XMLStreamWriter

Default implementation of javax.xml.stream.XMLStreamWriter does not support such output features as indentation and multi-line output. Correspondingly the resulting text is always a long one-line string which many of us would want to format in a pretty style for better reading. There is a solution bundled with Java 6 although it is sort of internal Sun facility which may have gone one beautiful day.:-) The class is named com.sun.xml.internal.txw2.output.IndentingXMLStreamWriter, it is public, and it resides in rt.jar. Using it is a matter of couple of lines in your code:

        final XMLStreamWriter defaultWriter =
            XMLOutputFactory.newInstance().createXMLStreamWriter(writer);
        final IndentingXMLStreamWriter sw = new IndentingXMLStreamWriter(defaultWriter);
        sw.setIndentStep("    ");

As shown above it allows you to vary the indent character sequence giving certain flexibility by that.
The only problem I can think of might be due to the end-of-line character internally hard-coded by '\n'. I would prefer having system-dependent or, better, a user-provided line terminator instead.
P.S. Just discovered that this class is only included into JRE not into JDK. That means one sure way to solve the original problem is to duplicate the class source in your application. There is nothing special in its logic as it routinely decorates an instance of XMLStreamWriter with the required functionality. The source code for JDK 6 can be downloaded from this page.

Parsing command-line options - part 3

So we have defined two interfaces - 1) the interface we want to use to access command-line values, - a real-world example of usage, and 2) the annotation we want to apply to the interface #1 to furnish it with option-specific information. It's time to start writing some code to bind them together.