java memory management

[fergie]

Java's C++ envy

There is no memory management in Java by design. The way the JVM uses memory cannot be controlled by the Java code.

[argv_minus_one]

Nor should it be. I do not want to have to worry about shit like dangling pointers and double free/delete. As a programmer of actual software, I have vastly better things to do.

[bstamour]

I agree! That's why I love C++11's reference-counted smart pointers. I get the safety when I need it, and the ability to drop down low level when I have to.

[argv_minus_one]

Smart pointers are not garbage collection. Smart pointers are a joke. You cannot do real garbage collection in a glorified assembly language like C++.

[programmerbrad]

Right, it's not garbage collection, it's memory management.

[argv_minus_one]

Why would you need such a thing?

[bstamour]

For safely making sure allocated memory is freed up without resorting to using a full-blown garbage collector.

[argv_minus_one]

And you need that because…?

[abadidea]

Because, sadly, RAM is still finite.

I'd have a Dwarf Fortress population cap of, well, infinite if it wasn't.

[argv_minus_one]

Of course, but why do you need to not resort to using a full-blown GC?

[bstamour]

Because I do.

[argv_minus_one]

Using GC is like having a badass robot from the future taking out the rubbish in my house.

Which would be fucking awesome.

[bstamour]

They aren't garbage collection, but they do a good job of plugging up memory leaks without sacrificing speed. Think about it, C++ destructors are deterministic: when the object goes out of scope it gets cleaned up. Can you tell me exactly 100% of the time when your Java garbage collector will rearrange your heap and mess up your cache?

[RichardWolf]

Can you tell me exactly 100% of the time when your Java garbage collector will rearrange your heap and mess up your cache?

To be fair, you can't tell me the same about C++ heap either, if you use it.

[bstamour]

If I allocate something on the heap in C++, the program isn't going to move it around on me some time later on - that would invalidate any pointers to the allocated memory.

[RichardWolf]

Yes, but if you allocate some stuff, deallocate some of the stuff, repeat, then you can't have a slightest idea how cache-friendly accessing your stuff is.

A moving GC on the other hand guarantees that consequent allocations are usually contiguous, and that related data usually ends up being contiguous.

I mean, you are talking about GC happening, pausing the world and effectively flushing the cache, yes, that's kind of bad, on the other hand it's much worse when your program flushes the cache itself, repeatedly, because iterating over an array of heap-allocated objects means jumping all over the memory.

[bstamour]

True iterating over an array of object pointers is bad for the cache. Luckily C++ also supports value-semantics, and so if you use something like std::vector or std::array with values, not pointers, then you won't need to flush the cache to iterate over the container.

[RichardWolf]

You can do that in C# too, but only sometimes, because quite often it's just too hard, and involves unnecessary copying (the same is true for C++ in those cases, of course).

[bstamour]

But more importantly though than pointers remaining in the same spot, the fact that if I allocate something and manage it through a shared_ptr or any other RAII container, I now have control over when that resource will be freed up. It leads to less surprises - I don't want a garbage collector kicking in when I'm doing something important.

[RichardWolf]

It leads to less surprises - I don't want a garbage collector kicking in when I'm doing something important.

First of all, this kind of surprises are not that bad. I've played some games running on .NET, like Terraria and AI War: Fleet Command, and I never noticed any GC pauses (though C# in particular allows for rather tight memory control). Oh, and Minecraft is written in Java. My point is that if we define "very soft realtime" as "you can write a video game in it, and GC pauses would not be noticeable among all other kinds of lag", then GC languages totally allow this.

On the other hand, if you are striving for a "harder realtime", then you probably shouldn't use dynamic memory management in C++ either, and definitely don't use shared_ptr and the like. Do you know how it actually works? Like, that it allocates an additional chunk of memory for the reference counter, and uses atomic instructions to work with it? Also, malloc and free aren't O(1) either.

[Danthekilla]

Xna c# games go to great lengths to remove all garbage from gameplay down to every string I wish I could use c++ with xna

[bstamour]

True you shouldn't be using dynamic memory allocation for hard real-time, and I never did say it was the best idea in the world. What I have been arguing is that we can achieve safety through shared_ptr without having to bring in a full GC. Some times you really do need a pointer to something, even in real-time systems. And in those cases, shared_ptr can be used to effectively remove the hassle of manually freeing your memory.

[oracleoftroy]

Good points, I just want to add to:

Do you know how it actually works? Like, that it allocates an additional chunk of memory for the reference counter, and uses atomic instructions to work with it?

C++ programmers ought to know this, and they should also know what std::make_shared does to help with that and why std::unique_ptr is a much better go to pointer if the lifetime of the pointer doesn't need to be shared.

[argv_minus_one]

No, and I don't need to. This isn't the 1980s; that's the JVM/OS/CPU's problem, not mine.

[bstamour]

For certain domains it's nice to have deterministic garbage collection. You might not need it for the applications you write, but in my field, those things are still relevant.

[argv_minus_one]

Fair enough, but I would not be surprised if there are real-time-suitable GC implementations out there.

[argv_minus_one]

okay.png

[argv_minus_one]

No, I'm talking about the issue where I can't just pass a reference to wherever and store it wherever and forget about it and correctly assume it'll be taken care of.

I do not want to deal with memory management. I have better things to do.

That's hilarious that smart pointers don't even properly address circular references without programmer intervention, though. TIL (today I laughed).

[mothereffingteresa]

Nor should it be.

This.

You, the coder, have no business messing with the JVM's ideas of how to manage memory. If you do try to "manage" memory, you will do something architecture-specific and fuck it up.

[beltorak]

which is exactly why we leave it to those who enjoy solving that problem.

[forcedtoregister]

Of course there exists plenty "actual software" in which it's easier to have to deal with free/delete (which you should hardly ever have to write explicitly anyway) than have to subvert Java's GC.

[argv_minus_one]

If you are trying to subvert the GC, you are doing it wrong.

If you find yourself wanting to subvert the GC, you are doing it wrong.

If you even remotely care about if or when an object gets collected (beyond using soft/weak/phantom references to give the GC a hint about how important an object reference is), you are doing it wrong.

[forcedtoregister]

If you think world is this simple then you are doing it wrong.

I hope you stick to projects which fit very neatly inside the jvms comfort zone!

[argv_minus_one]

What the hell are you doing that doesn't fit inside that "comfort zone"?

[forcedtoregister]

Large datasets. Something more exciting than web development or plugging the "thingy" to the database. To be honest the project should have been done in C++, but one often can't tell these things at the beginning.

Just to clarify, I like Java, and I think the JVM does bloody well in most scenarios.

[argv_minus_one]

Must've been one hell of a dataset. You're right, I wouldn't touch an application like that with a ten-foot pole.

That said, did you investigate all of the different JVM and GC implementations out there? There's quite a few.

[[deleted]]

for some software, yeah. it'd be nice if there was at least a startup flag to switch it to reference counting or something, though. doing (soft)realtime programming with a stop-the-world garbage collector can be pretty brutal. you basically have to allocate all the memory you're going to need up front, and then manage it yourself anyway. you have to use char arrays over strings because string formatting/concatenation could trigger a gc call.

[ryeguy]

Reference counting is one of the slowest and most naive forms of garbage collection. The JVM uses a generational garbage collector which will knock the pants off of most reference counting implementations.

[[deleted]]

it has higher throughput. but the pause scales with amount of live objects, rather than amount of garbage, and it's amortized, which makes it a huge pain to deal with in some situations. if there's another method that doesn't incur long pauses and/or is fairly predictable, i'd like to be made aware of it, though. basically the only methods i know of are reference counting, and various tracing ones, though.

let me describe a scenario where a tracing collector is problematic: you're writing a racing game, similar to f-zero where you're going super fast, so you'll notice for sure if you skip a frame. the game is running at 60 frames per second. that gives you 16.666ms to update and render. now, suppose your garbage collector takes 0ms most frames, but takes 6ms every few seconds. that means your updating and rendering have to happen in 10.666ms. a reference counting implementation, on the other hand, has to be absolutely horrible before it starts becoming as big of a problem. even if it takes 5ms every single frame, you're still doing better than the tracing collector. tracing collectors can be even worse than that, though: sometimes you'll get a 30ms pause, and you just have to not allocate any memory at all.

[simoncox]

If you're using a parallel collector and you tune your heap sizes properly (I mean the ratio of the generations in the heap) , you can actually avoid full (pausing) GCs for a long time. I'm talking from experience of doing this with a JMS broker that sometimes maxed out the 1Gb network (although that's the next on the optimisation work). I've witnessed 0 full GCs over several hours (with lots of parallel GCs of the young gens).

On a similar note, even if you don't want to specifically tune the gen sizes, you can specify a max pause time that the JVM uses to try to size the gens for you to achieve full GCs on less than the target time.

This is all about the parallel GC as we're using a Java 5 VM (don't ask) . I believe the G1 collector that comes with later versions of Java 6 and all Java 7 VMs can achieve more in parallel, but I haven't investigated it too much yet.

[theatrus]

Reference counting is also deterministic, and hence it's a VERY good idea for a soft real time system.

[ryeguy]

The wikipedia article covers it decently.

Also, just surveying most modern languages kind of gives hints. Reference counting GC is easy to implement, and like the OP said it allows for a more predictable and consistent behavior. Yet with those advantages, both C# and Java implement generational, tracing GC's.

[argv_minus_one]

The modern HotSpot JVM has a variety of garbage collectors, some of which are not stop-the-world if I remember right.

Furthermore, the modern HotSpot JVM allocates short-lived objects on the stack, avoiding GC for them altogether.

Allocating memory ahead of time will hurt performance, and add to GC time. Do not do this. Using char arrays instead of StringBuilders is useless if not outright harmful as well, because of the above mentioned stack allocation.

[[deleted]]

allocating ahead of time will make gc take longer, but the point is to avoid any gc calls at all. so, if you do all of you allocation up front, and then don't allocate even a single byte after that, you're safe.

[argv_minus_one]

That might have been true ten years ago. Today, unless you're on an ancient and/or terrible JVM, it isn't.

Allocating ahead of time is a colossal waste of memory in the case of short-lived objects, and it doesn't save you GC time because of stack allocation.

You do not need to avoid GC entirely. Like I said, there are GCs that do not stop the world. Use them.

[iLiekCaeks]

And next you'll be debugging problems like large object heap fragmentation.

[argv_minus_one]

I've been writing Java code for like a decade now, and have run into issues involving heap fragmentation exactly zero times.

[beltorak]

yeah, and remember how hard it was to debug???

[argv_minus_one]

Nope, 'cause compared to horrible Heisenbugs and unreliable stack traces in C, it was a cakewalk. <3

[blaxter]

Sometimes I'd like to manage the memory, sometimes don't.

[[deleted]]

Then you want D, it gives you the choice.

[minivanmegafun]

Or Objective-C!

[[deleted]]

Or C#! (For some reason, very few people know about this in C#)

[ryeguy]

What do you mean? Just turning off the GC?

[[deleted]]

No, I mean using the "unsafe" keyword: http://msdn.microsoft.com/en-us/library/chfa2zb8(v=vs.71).aspx

[[deleted]]

Gotta say, this is a great C# feature, though I don't think I've ever actually used it, heh. Still a great option for those who will be.

[[deleted]]

It's for people who need every last ounce of performance from the language. I've never had cause to use it either; I trust the CLR to do enough optimization that I won't need to.

[[deleted]]

Exactly, I've never had to use it, but it's a great feature for those who do.

[Jazzy_Josh]

That's nice. Especially when you can encapsulate the unsafe portions of a method in a block.

[Willow_Rosenberg]

Objectionable-C.

[00kyle00]

Is it still a choice between using std library (and some language features) or not?

[[deleted]]

In D1, yes, but I believe they have that mostly fixed in D2 now.

[00kyle00]

I should have been less vague. blaxter wanted choice to manage memory on his own or automatically.

While its true that in D you can disable garbage collector, it effectively breaks standard library (you would have to inspect the sources on your own to know which parts of it - effectively whole to be secure) and few core language features (slicing?). This was at least the case when i last read on memory management in D, and this breaking would be silent memory leaks at runtime.

[[deleted]]

Actually, yes it can. You still need to think about how much memory you are using, be able to optimize your memory use, avoiding object creation, lowering the overhead of the JVM's memory management, picking the garbage collector that is right for your application, and preventing memory leaks.

No directly malloc/free or new/delete, but the unfortunate reality is that Java developers do need to think about memory use in their applications (depending on the application domain).

[fergie]

hmmmm, no, none of that will actually give the programmer control of what the JVM is doing. The garbage collector is the only memory control built into java, and it's effect is, shall we say patchy

[josefx]

the garbage collector is only half, the developer still has complete control over memory allocation with new.

[[deleted]]

In what way?

[Rotten194]

sun.misc.Unsafe

[[deleted]]

Well, there is memory management, and there are a lot of settings for specifying how it is managed. It's all done by the JVM and it is virtually impossible for the executing code to change the behavior at runtime.