Tiny object performance overhead

[Riven]

Appearantly this object is expensive to construct and/or initialize:

public class Vec3
{
  public float x,y,z;
}

See my benchmark: compare “new object” (1354ms) and “used object” (447ms).

[Jeff]

Ya gotta be *really careful with micro-benchmarks in java. Its very very easy to get meaningles results.

I’m swamped now but if I find time later Ill take a look at this particular example.

[Riven]

I’m fully aware of that, and have run into this in real-world applications, and turned it into a bechmark to show the results with you guys without uploading large packages of code, with at least a dozen dependancies.

Even in realworld cases the results of the changes in architechture were very similar, so please don’t think of it as yet-another-benchmark that the JVM isn’t handling properly yet.

[pepijnve]

I second Riven’s comment on the expensive Vec3 construction. I recently reworked some C++ code that used some vector math classes like the Vec3 class. All the Vec3 operators (±*/) allocated new Vec3 instances (stack allocation). Initially I converted this to ‘new Vec3()’ in the java code, but the performance was terrible. The algorithm in question was causing lots of very shortlived Vec3 instances to be allocated inside inner loops. I then reworked the code to reuse Vec3 instances as much as possible. This improved performance a lot, but the elegance of the code dropped Unfortunately I can’t seem to find my test results…

[blahblahblahh]

@rreyelts

@blahblahblahh

Off the top of my head, it is clearly impossible for object creation to be that cheap - you have to initialise lots of data in memory (think how much data an object actually contains under the hood if it contains merely a simple float)

Think about it in terms of allocation versus initialization blah^3. Allocation is reserving address space for the object, and initialization is assigning actual values to fields, etc… So, allocation can indeed be as fast as a pointer bump.

I’ve done this in C++ code where I’ve written custom allocators for a routine. The routine allocates some millions of nodes over it’s relatively short (1 second) execution time. The allocator has a pre-allocated memory pool. When it needs to allocate a node, it simply bumps a pointer. No nodes get deallocated until the very end of the routine, at which point they are all “deallocated” by simply resetting the pointer to the top of the pool. This reduced allocation/deallocation times to just about nil.

You can do something similar in Java by creating an object pool, but those objects are still something that the gc is aware of.

Bad description on my part, but what I was trying to do was allude to the fact that a java object that merely contains a float also contains many other bytes imposed by the language. Whereas you have to re-initialize only the float with pooling, with new’ing you have to initialize a bunch of other data.

So, I took “object creation” as used in this discussion to mean “allocation + initialization of required JVM/language/platform data”.

No? Yes? Maybe?

[princec]

Once again, it is probably the case that escape analysis and stack allocation will cure most of this. Due in Java 7 isn’t it? I’ve seen it working in Jet and it pretty much does the trick performance wise.

Cas

[walter_bruce]

Escape analysis will help and be a nice addition but it is no panacea. It should easily handle the trivial cases shown in typical microbenchmarks where an object is created, used once, and thrown away all within a single method. For harder cases, for example where the temporary object is used to marshal arguments for a possibly polymorphic method call, it remains to be seen how often escape analysis can handle this for real code in large projects. And of course, if the object has any significant lifespan, for example if the object is part of a larger object, then escape analysis cannot help. It does not allow objects to be inlined into other objects.

The small object overhead is still significant and while escape analysis is a good thing, it only fixes one aspect of a wider problem.

[CommanderKeith]

[quote]I read in some article* of a JVM engineer that creating new objects was ‘almost at the cost of shifting a pointer’.

• I tried hard to find the article, but sometimes java.sun.com is kinda hard to wade through
  [/quote]
  I think CaptainJester just found the article you were talking about:

Check out this article on how the garbage collecter works: http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html

The 1.0 and 1.1 JDKs used a mark-sweep collector, which did compaction on some – but not all – collections, meaning that the heap might be fragmented after a garbage collection. Accordingly, memory allocation costs in the 1.0 and 1.1 JVMs were comparable to that in C or C++, where the allocator uses heuristics such as “first-first” or “best-fit” to manage the free heap space. Deallocation costs were also high, since the mark-sweep collector had to sweep the entire heap at every collection. No wonder we were advised to go easy on the allocator.

In HotSpot JVMs (Sun JDK 1.2 and later), things got a lot better – the Sun JDKs moved to a generational collector. Because a copying collector is used for the young generation, the free space in the heap is always contiguous so that allocation of a new object from the heap can be done through a simple pointer addition, as shown in Listing 1. This makes object allocation in Java applications significantly cheaper than it is in C, a possibility that many developers at first have difficulty imagining. Similarly, because copying collectors do not visit dead objects, a heap with a large number of temporary objects, which is a common situation in Java applications, costs very little to collect; simply trace and copy the live objects to a survivor space and reclaim the entire heap in one fell swoop. No free lists, no block coalescing, no compacting – just wipe the heap clean and start over. So both allocation and deallocation costs per object went way down in JDK 1.2.

in this thread:

http://www.java-gaming.org/forums/index.php?topic=16512.msg130580;topicseen#msg130580

[Riven]

Thanks for backing up that statement.

It simply shows there is more to object-creation than just allocation. Even an object with an ‘empty’ constructor has significant overhead. At least the object-header has to be written (as it’s not a struct) which might require fetching the class-id, or something else entirely…

[t_larkworthy]

Object pooling in JOODE has speed it up by an order of magnitute.