Possible memory leak, or am I doing this wrong?

(Sorry if this is the wrong section, or too stupid a question to post here!)

I've started writing a plugin (new to Java, mostly, by the way) to generate custom landscapes as the player explores, and I've encountered a problem. The following code causes memory usage to shoot up to about 1GB abnd just... stay there. (I'm aware the code doesn't really DO anything useful, I'm just testing right now)

Code:

Random rnd = new Random();

World world = getServer().getWorlds().get(0);

for (int x = 0; x <= 175; x ++) {
    for (int y = 0; y <= 127; y ++) {
        for (int z = 0; z <= 175; z ++) {
            world.getBlockAt(x, y, z).setTypeId(rnd.nextInt(6));
        }
    }
    System.out.println(x);
}

This is placed in the plugin loading event, for now, but it also happens if I put it in a chunk loading event (I can't figure out how to use the CHUNK_GENERATION event)

Code:

world.getBlockAt(x, y, z);

in a loop will also cause the same problem.

Like I said, mostly new to Java, so I'm not sure if I'm doing something that the garbage collection doesn't like, something wrong with Bukkit, or need to unload chunks, or... what. I've tried unloading chunks too, with no one on the server, but I'm not sure they even unloaded.

 

That's processing 3.8 million blocks. I'm not very good at memory management so I don't know for sure, but I imagine that's why it starts freaking out. It's being expected to cycle through millions of blocks as fast as it can

 

Yeah, and I figure it's a pretty dumb way to do it (through Bukkit) but I don't know where to start as far as making a landscape generator elsewhere. The speed isn't really the issue right now (although it might be after a while), just the fact that I don't know how to unload the memory used to make them. I think something's keeping every block I process in the RAM after it's all done.

 

The server may be caching blocks loaded using this mechanism. You could invoke the garbage collector directly to try to unload any unreferenced blocks. But if there are any strong references to those blocks remain, the call won't actually free up any memory.

 

I submitted a pull request that may help with this.

It makes the cache use "soft" references. This means that the garbage collector can delete them if the server runs low on memory.

However, drawing a large number of blocks does seem to cause problems for the server.

 

That's a nice change. Very appropriate for caching.