clearing or make new array?

[BurntPizza]

So basically Rakiayn, don’t worry about clearing or ‘deleting’ your list of Strings, the JVM knows what it’s doing better than you do, and the only time appropriate for a String pool is if you are generating millions of new strings all the time, which I doubt.

Also, is your program using too much memory? If not, don’t fix it if it’s not broken!

Nice article about Strings: http://java-performance.info/string-intern-in-java-6-7-8/

[gouessej]

Hi

Object pooling in Java has become completely useless and inefficient in most cases since Java 1.4. Rather avoid keeping references on useless objects so that the garbage collector can make a good job and implement some kind of management only for partially unmanaged objects allocated on the native heap which is the case of direct NIO buffers or objects depending on system resources (TeamworkGuy2 gave some examples).

If you poorly implement your object pool, it will be both useless and less effective than using no object pool at all. I agree with BurntPizza, “premature optimization is the root of all evil” (http://en.wikipedia.org/wiki/Program_optimization#cite_note-autogenerated268-2).

[Gibbo3771]

@gouessej

Object pooling in Java has become completely useless and inefficient in most cases since Java 1.4.

Was about to ask about this, I was considering doing it at one point for my game, rather than create objects over and over again, simply just put them into an array and respawn them.

Was pointless.

[princec]

I concur with these findings too; use pooling only when it is actually relatively expensive to construct an object (ie. large number of c’tor parameters, lots of validation, native call, large amount of memory consumed etc).

Cas

[loom_weaver]

Even something as simple as new MyClass(), while traditionally allocating object on the heap, might have the JVM put it on the stack instead (determined via escape analysis).

An interesting link:

Java theory and practice: Urban performance legends, revisited

Urban performance legends, revisited

[princec]

Don’t think scalar replacement is in yet.

Cas

[BurntPizza]

@princec

Don’t think scalar replacement is in yet.

Cas

Apparently it’s been in the server since JDK6U23, also how to tell whether it’s working: http://www.java-gaming.org/index.php?topic=25533.0

Not sure about the client VM yet.

[princec]

Hmm it never seems to work for me. My heap was generating tens of thousands of $Itr classes (from foreach constructs) every frame. Unfortunately with all the other tiny objects I was making every frame that pushed GC over the edge of acceptable and started giving me the Dreaded Regular Pause, so I had to regress all my foreaches into ordinary for loops :emo: Still, pauses gone, wahey.

Cas

[jonjava]

Really? That sounds awful. Didn’t realize foreach could be that bulky.

[princec]

Well, that’s what I thought. I was fully expecting all the Itrs to be escape analysed and not even show up in visualVM but there they were, gobbling hundreds of K every frame.

Cas

[shadders]

@ctomni231

Ugh, this sounds exactly like an Object Pool to me. But, then you wouldn’t need to delete the Objects, instead, you would just set them to a value that you wouldn’t use so they can be used again. Below is an implementation for objects (not written by me but borrowed…)

    /**
     * Acquires an object from the pool, if a recycled one is available, then
     * the pool will return the recycled one rather than creating a new one.
     *
     * @return object instance
     */
    public final T acquireObject()
    {
        if( collectedTrash.size() > 0 )
            return collectedTrash.remove(0);
        else
            return createInstance();
    }

You realise when you call collectedTrash.remove(0) you’re causing the entire backing array of ArrayList to be copied 1 place to the left? If it’s large you’re probably costing yourself a lot more than you gain from eliminating GC. Better off using a LinkedList or collectedTrash.remove(collectedTrash.size() - 1).

edit: Don’t use a LinkedList because that will create another wrapper object which will get GC’d in place of the pooled object.