Question

I am running a complicated multithread java game, which is working perfectly with the exception of this function. This function, when called, approximately 0.01% of the time, will cause a thread hitch of a quarter of second. Through a series of debug lines and time measurements, it’s absolutely down to this function (and three others almost exactly like it).

The usage of this function is to provide the light level of a nearby block within a voxel engine game. It is only run when a section of the world is updated, which can happen alongside rendering.

Please note:

• This function works accurately 100% of the time for its intended function.
• This function causes a thread hitch of approximately a quarter second 0.01% of the time.
• The variables are not synchronized.
• The function is never called more than once at a time in the program.
• All variables are valid fields of a larger, non-synchronized class.
• All variables are integers.
• The array light[][][] is a byte[][][].
• This method is never called more than once at a time, as it is synchronized by a larger method on a wide interval.

I’m pretty sure external synchronization is not the issue.

What part(s) of this function may be causing an issue with thread synchronization, CPU overuse, or stack filling, and how can I go about improving performance to get rid of these render hitches?

public byte nsleftlighting(int[] coords){
    if(coords[0]<0)return 16;
    difx=chunkedx-chunks[coords[0]].X;
    difz=chunkedz-chunks[coords[0]].Z;
    if(coords[1]==0){ 
        if(-difx<=-(chunklimit)){return 16;}

        else if (-difx==0) {
            if(-difz>=0){
                proz=0;
                specialz=-difz;
            }else{
                specialz=difz-1;
                proz=1;
            }
            if(chunks[chunkxyid[1][proz][0][specialz]].loaded){
                return chunks[chunkxyid[1][proz][0][specialz]].light[15][coords[2]][coords[3]];
            }
            else{return 16;}
        } else {
            if(-difz>=0){
                proz=0;
                specialz=-difz;
            }else{
                specialz=difz-1;
                proz=1;
            }
            if(-difx>0){
                prox=0;
                specialx=-difx-1;
            }else{
                specialx=difx;
                prox=1;
            }
            if(chunks[chunkxyid[prox][proz][specialx][specialz]].loaded){
                return chunks[chunkxyid[prox][proz][specialx][specialz]].light[15][coords[2]][coords[3]];
            } else {return 16;}
        }
    }
    if(coords[1]>0){
        return chunks[coords[0]].light[coords[1]-1][coords[2]][coords[3]];
    }
    return 16;
}

Answer 1

I don’t see anything in here that would cause a performance problem — at least not with that high a variance. Array accesses should be extremely fast — even if they are 4 dimensional arrays. [[Nice effort on that.]]

A quarter second is not a huge amount of time which makes me wonder if the profiler is lying to you about the source of the problem. It may be responding poorly to the multi-dimensional arrays or some other attribute of this method that is not immediately apparent — to me at least.

One possibility, however remote, is that your program is swapped and these arrays are pretty big. If they aren’t accessed very often is there any chance you are seeing some IO as some memory pages are swapped in?

You commented that you are using wall-clock timers to determine that the routine takes 250ms. Are you sure that the CPU was actually executing that method for that time period? Could this be a thread contention issue that is taking over CPU in some other part of the program? Can you see if you see CPU spikes every so often when this method takes a long time?

Any chance you are seeing a GC heap lock and it’s affecting the array accesses more than other routines? Can you watch the memory graphs to see if you see a correlation? Does giving the program more heap affect the timing or the frequency of the problem? This is going to be more an issue if you are running Java <= 1.5.