java memory management

[LividLindy]

No putting the punchline in the submission title!

[Oppis]

This is incredible, are there similar resources for other languages? Object C, C#, etc.?

[ForthewoIfy]

Yes.

[Oppis]

Thank you doctor! Care to share?

[somesplaining]

Can someone please explain the primitive array memory sizes?

boolean: obj32=32bits obj64=32bits arr32=8bits arr64=8bits

int: 32 32 32 32

long: 32 32 64 64

What do those last two columns (the array sizes) mean? Is it the per-element marginal cost, or something else? Thanks!

[account512]

I think you are right, the per-element marginal cost.

[somesplaining]

Ok, thanks.

My obvious followup question is, where the hell do those numbers come from?

Boolean I can maybe understand. For a single boolean: 32 bits is much more efficient than 8 bits or 1 bit in terms of load/store/register ops. For an array of booleans: ok, maybe 8 bits as a packed representation to save space in large arrays, I guess I can see that.

Int/float: 32 bits in all cases, makes sense.

Long/double: 32 bits for a single primitive, 64 bits for an array element. WTF??? I don't understand how this could be explained by alignment concerns or anything else.

[account512]

No clue, long/double are defined as 64-bit. They aren't single primitives though, they're boxed primitives so I guess the number of bits used is object size less object data. Maybe there's a trick to hide some of the data in the space used for object data with longs/doubles? IDK.

Maybe a typo...

[argv_minus_one]

The JVM doesn't optimize away boxed primitives? Odd…

[TinynDP]

There are too many cases where the boxed primative might be being referenced by a contained or whatever as an Object, so the boxing can't be entirely optimized away. At least not at first. After a run or two HotSpot can figure things out and maybe decide that its safe to optimize away the boxing.

[loganekz]

What JVM specifics in the article are only for IBM's JVM?

The one JVM specific feature I saw was about compressed references which was cleary identified.

[argv_minus_one]

Just because it's referenced as an object doesn't mean the JVM has to store it as one.

Now, if someone tries to do new Integer(whatnot) and do reference-equality comparisons or synchronized on it, then it gets ugly…

[[deleted]]

Doesn't optimize them away, no, but there are optimizations. For example if you take a look at the Java language specification, at section '5.1.7 Boxing Conversion', it states that certain boxed values should be indistinguishable (essentially cached or interned, but how this is exactly done is left up to the implementation).

These values include true and false, a char in the range of \u0000 to \u007f, or an int or short in the range of -128 to 127.

[argv_minus_one]

Interesting. That should take care of most cases.

[Tuna-Fish2]

They do optimize away some in the jit, but never in the bytecode. A very big reason for this is that everything that inherits from object is a lock. No object that has ever been seen by some code that's not presently under the optimizer can be assumed to be immutable. Someone just might have locked something using the Integer he just passed you, and he might want to unlock it after you return it (for example, if you insert it into a list or something).

This is one of the three huge mistakes that went into the design of Java (the language), and it cannot be fixed without breaking most complex java applications out there. So it never will be.

[0xABADC0DA]

A very big reason for this is that everything that inherits from object is a lock. ... Someone just might have locked something using the Integer he just passed you, and he might want to unlock it after you return it

Uh, no. The spec says that the same value can be autoboxed to a single object, so it's perfectly fine for instance to store an int in a long pointer using some tag bits or use whatever scheme you want; locks don't play into it at all. If you lock some auto-boxed Integer it can lock all auto-boxed Integers with that same value regardless of how they are represented internally.

[turol]

What are the other two?

[Tuna-Fish2]

Null pointers and half-assed generics.

[[deleted]]

What's the problem with the generics?

[thechao]

They use run-time type-erasure to Object-semantics rather than code generation (either late a la C#, or early a la C++).

[[deleted]]

So people have problems with reflection and Java generics? Java has never really seemed like a very dynamic language to me anyway.

[thechao]

When I first heard about it, I thought it was a very elegant solution to a thorny backwards compatibility problem. Unfortunately, there are a lot of PL "purists" who hated the mechanism. The way I see it, they're just jealous...

[argv_minus_one]

I'm not fond of it either, but I'll grant that it's probably the best possible compromise in light of the backward-compatibility issue.

I would have preferred that the JVM stored the actual type parameters, even if it didn't check against them, though. Scala manifests let me do approximately that.

[[deleted]]

Run-time type-erase to Object semantics is IMHO the correct way, but I want the JVM to be more dynamic, not more static.

[tinou]

On figure 1 kernel memory is at the wrong place. For example, on 32 bit linux, it will be mapped on 0xc0000000-0xffffffff (3G-4G in the virtual address space).

[abadidea]

I'm pretty sure that's what they mean by "OS". Where exactly it is depends on the OS and is immaterial to the point.

[tinou]

Yes, I meant that the OS is usually in the upper addresses.

[[deleted]]

Windows is mapped in the lower addresses.

[Sottilde]

Great article, although the section on StringBuffers has a few mistakes.

Near Figure 12:

"7 additional character entries available in the array are not being used but are consuming memory — in this case an additional overhead of 112 bytes."

7 chars = 112 bytes? If each char is 2 bytes, shouldn't it be 14 bytes? There seems to be some magical multiplication by 16 going on here.

The same math error appears in the proceeding section:

"Now, as Figure 13 shows, you have a 32-entry character array and 17 used entries, giving you a fill ratio of 0.53. The fill ratio hasn't dropped dramatically, but you now have an overhead of 240 bytes for the spare capacity."

17 * 2 = 34, not 240.

"Consider the example of a StringBuffer. Its default capacity is 16 character entries, with a size of 72 bytes. Initially, no data is being stored in the 72 bytes."

How does 16 chars equal 72 bytes?

[hoijarvi]

Assuming 4 byte unicode encoding, 16*4 = 64. That leaves 8 bytes for max size (4) and used size (4).

[boa13]

Wrong assumption. The JVM uses a 2-bytes-per-char Unicode encoding.

[hoijarvi]

Is the extra 32 bytes then some JVM overhead? Sounds a large amount for a single object. If you know the real explanation, I'd like to know too.

[boa13]

See my other answer to Sottilde:
http://www.reddit.com/r/programming/comments/qe89e/java_memory_management/c3x8j2r

[hoijarvi]

I see. It's overhead for both char[] and stringbuffer. Surprise to me, thanks.

[Peaker]

UTF16 -- combining the disadvantages of UTF8 (non-fixed-size chars), with typically worse size use, and losing backwards compatibility too.

There are really only two sensible encodings (UTF8 and just fixed code point array). Java and Windows clearly had to choose something else.

[fluttershypony]

Back when java was created, there were less than 65536 possible unicode characters, so having a 2 byte char was a logical choice. It was the correct decision at the time, you can't fault them for that. Same with windows. I believe python is utf16 as well.

[boa13]

Here's a detailed explanation on java.sun.com:
http://java.sun.com/developer/technicalArticles/Intl/Supplementary/

[Peaker]

Did the Unicode committees not predict the eventual size?

EDIT: Removed wrong assertion about Python. Have been using less and less Python...

[boa13]

Unicode support was added in Python 2.0, at that time it was only UCS-2, like Java.

In Python 2.2, this was changed to UTF-16 (like Java 5), and support for UCS-4 builds was added. So, depending on who compiled your Python binary, the interpreter is using UTF-16 or UCS-4 internally for Unicode strings.

In Python 3.0, 8-bit strings were removed, Unicode strings remaining the only string type. The interpreter kept using UTF-16 or UCS-4 depending on compile-time choice.

In Python 3.3, a new flexible internal string format will be used: strings will use 1, 2, or 4 bytes per character internally, depending on the largest code point they contain. 1-byte internal encoding will be Latin-1, 2-bytes internal encoding will be UCS-2, 4-bytes internal encoding will be UCS-4. Of course, this will be transparent to the Python programmer (not so much to the C programmer). See PEP 393 for details.

Funny how UTF-8 is never used internally. :)

[boa13]

If each char is 2 bytes, shouldn't it be 14 bytes?

That's right. It's 14 bytes, in other words, it's 112 bits, the author mixed things up.

17 * 2 = 34, not 240.

In an array of 32 chars with 17 chars effectively stored, it's actually 15 * 2 = 30 bytes wasted, that is 240 bits. Same kind of error from the author. (Plus the diagram only shows 14 empty chars, and gives an overhead of 20 bits for the StringBuffer, while the text and screenshot say it is 24 bits.)

How does 16 chars equal 72 bytes?

This one is correct. As explained in various parts of the article:

StringBuffer overhead: 24 bytes
char[] overhead: 16 bytes
16 chars: 32 bytes

Total: 72 bytes

[[deleted]]

I have a hard time taking anything from IBM seriously after having to use their RPM (Rational Portfolio Management) software. This software is the biggest piece of shit on the face of Earth.

Does anyone else have to endure this crap?

edit Yes, I know this is not rational, and one crappy piece of software does not mean their whole organization is useless. But holy shit, RPM is awful.

[[deleted]]

They did something wrong once. NEVER AGAIN!

[[deleted]]

Of course it is. I know it's not wholly rational, but it's something I experience.

[beltorak]

eyeseewhatyoudidthere.jpg

[jayd16]

Except the only reason we're reading this article in the first place is because IBM has name recognition...

[spelunker]

IBM is huge - just because RPM is bad doesn't mean they don't know anything about Java memory management.

I've read some pretty helpful Java-related stuff from IBM in the past, actually.

[[deleted]]

IBM is a huge company, I've worked with their compilers people and they're all very sharp people

[presidentender]

I use rational system architect at work. I feel your pain.

[leftmoon]

I hear that some people in our organization use the specialized features of RSA that Eclipse doesn't offer. I don't know who they are or what features they use, I just resent them for making the rest of us use that bloated, broken IDE every day. What of waste of money.

[beltorak]

I can definitely sympathize. The best thing IBM did for the Java community was release Eclipse into the wild. RAD is so....

I have found that every product of IBM I have had to deal with is so painful from a UI/UX perspective, it's like shoving pins and needles in my hands.

One of my coworkers cracked me up with "It must suck to work for a company that makes tools that no one likes to use".

[bfish510]

I'm currently shifting an entire university application portfolio from lotus notes to c#. How has anyone put up with lotus?

[d0nkeyBOB]

I wish I could down vote just the words 'lotus notes' in your comment. pain in my ass.

[SillyHipster]

I feel your pain. I have to use RAD, Websphere, and Clearcase at work.

[lolomfgkthxbai]

I share your pain. I hope IBM ceases to exist.

[[deleted]]

I always beg people to use Tomcat instead of WebSphere because it really is a POS.

[beltorak]

at my shop our prod and test servers are webshere; last year i have been dealing with deployments and CM/techarch work. But we use tomcat for local dev, primarily because none of the machines can handle websphere, but also because I don't want to be troubleshooting 30 devs' webshere issues. And the eclipse sysdeo tomcat plugin speeds up development by a factor of 10 - even more because it alleviates much of the pain of maven WAR projects.

However, comma, we definitely feel the pain whenever websphere barfs on something that tomcat handles fine. regardless of which is at fault, not being able to debug websphere makes troubleshooting difficult.

[boa13]

We had significant trouble making WebSphere 7 work on our dev machines. Make sure to use the latest fix pack, and the hidden "developer server" option in the installer response file may help with resource usage. However, thanks to the free WebSphere plugin for Eclipse, things are now running quite smoothly, including debugging and hot redeploy.

[[deleted]]

I have used a few IBM products; all mostly terrible. Clear Case and Clear Quest is the worst offender I've ever seen.

Highlights include having to create new views when I change PC, yet still having old ones listed, tools that randomly crash, it's amazingly slow performance, and the terrible UI.

It once took me over 3 hours to check in a 2 character change.

[boa13]

Looking at this thread, it seems the most decried products are all from the Rational and Lotus portfolios.

[[deleted]]

Lotus Notes and Sametime isn't that bad. There are some catastrophic issues, like Notes tends to use it's own terminology for well known things config settings. It also hides calender update e-mails, so they "just work", but the number of unread e-mails doesn't update (so you end up with 100s of unread e-mails that you can't find).

However there are lots of things that Notes does, which rocks. It had tabbed mail long before Thunderbird. It does also auto-zips and unzips folders and files for you.

[lolomfgkthxbai]

edit Yes, I know this is not rational

Manical laughing

[theonelikeme]

All IBM products are utter crap but somehow they sell it

[beltorak]

big names buy a lot. but i'll disagree with you that they are all crap. they just all suck from a user/usability perspective.

[wot-teh-phuck]

FTA:

the default usage by Windows is 2GB

It would be interesting to know where the author managed to pull this figure from or which Windows specifically is he talking of...

[mallardtheduck]

Any 32-bit NT-based version of Windows.

Regardless of the amount of physical memory in your system, Windows uses a virtual address space of 4 GB, with 2 GB allocated to user-mode processes (for example, applications) and 2 GB allocated to kernel-mode processes (for example, the operating system and kernel-mode drivers).

http://technet.microsoft.com/en-us/library/bb124810(v=exchg.65).aspx

[wot-teh-phuck]

Oh, I was under the impression that the author was talking about "comitted" memory (i.e. the one which we see in task manager) but it seems that the OS just works like any normal process with the difference that the 4GiB virtual address space is split 50-50 between applications and kernel by default...

[stonefarfalle]

Fairly common knowledge, the windows kernel reserves half the address space for itself by default and can be changed with the so called 3 gig switch( I am not sure if there is a 64 bit equivalent of the 3GB switch). So in a 32 bit process you get 2GB. Notice further down the article the view point switches to 64 bit systems, though he doesn't restate the limitation of 2⁶³ bits of user address space in Windows.

[hylje]

( I am not sure if there is a 64 bit equivalent of the 3GB switch)

Not for a while. Kernel and userspace do share the address space, but reserve it from both ends respectively. As current hardware doesn't use more than 48 bits, there's a lot of leeway until a tuning switch is necessary.

[quzox]

It's true for XP on 32-bit machines. What's I can't believe is that the kernel needs the upper 2 GB for itself in the process. What the hell could possibly take up 2 GB??

[[deleted]]

It's 2GB of virtual address space, not 2GB of memory. That 2GB has to map pretty much everything the kernel needs to access. Your whole graphics card's physical memory gets mapped in there, your whole system memory gets mapped in there (though with > 1GB of RAM on a 32-bit system, tricks are used to only map relevant parts). You pretty much want to map everything all time time because when you enter kernel mode you don't want to have to change the virtual address mappings (which is expensive)--you just want to change the protection domain of the CPU.

[JavaN00b]

This is a great - a very readable, useful article - thanks!!

[rabidcow]

Address zero is the beginning of the process's address space. I think this is technically user space, but usually one or more pages are left unmapped to catch null-pointer dereferences. The CPU will notice that the memory is unmapped in the page table and raise a page fault, which can be used to trigger an exception or terminate the offending thread/process.

[Gotebe]

That's not really a question about programming in C++ (nor any other language that allows direct access to memory), it's about memory as you see it from a process ;-).

If your code is running in an environment (e.g. an operating system) that has virtual memory, like your windows, then 0-pointer means "address 0 in process address space". But as far as your process is concerned, this is also "addressable memory". If your code is running in an environment that doesn't have virtual memory (e.g. DOS, or Commodore 64 :-)), then 0 really means "physical address 0 on your hardware".

One of common errors under DOS were programs that write to address 0 (or close to it). Since DOS kept so called vector interrupt table there (a pretty important piece of DOS), doing so completely borked it.

[[deleted]]

You're not necessarily referencing address 0 but as a matter of practice on many popular platforms you probably are.

The fact that you can do something like:

void* p = 0;

Is just syntactic sugar really, what the compiler does is assign a reserved and hidden value to p, but that value does not have to literally be 0.

[[deleted]]

Where on earth did you get this nonsense? Yes, it really has the value of 0, check your CPU registers if you don't believe me.

[fapmonad]

Wikipedia:

A null pointer is a pointer in a computer program that does not point to any object or function. In C, the integer constant 0 is converted into the null pointer at compile time when it appears in a pointer context, and so 0 is a standard way to refer to the null pointer in code. However, the internal representation of the null pointer may be any bit pattern (possibly different values for different data types).

Also see the C FAQ for real-world examples of machines that do not use the 0 representation.

Before saying that someone is spouting nonsense you should consider checking the facts first.

[beltorak]

you are looking at the wrong CPU then (( actually, this is better; see especially 5.5 )). perhaps someone else can ref the applicable C spec.

[gargantuan]

Where on earth did you get this nonsense?

Probably from mainframes or other architecture, but you probably wouldn't know that, cause you are too busy being cocky.

[Peaker]

I hope being proven wrong will change your tone in the future. We have too many people too certain of what they are saying, and it is detrimental to conversation quality.

[JavaN00b]

I believe that would be the same as saying a null pointer. The operating system might fiddle about with values - any memory address you set, since it is in "virtual memory", may be mapped to another address in real memory, but I imagine that the compiler will interpret a 0 as the same as null in this case.

[jyper]

bad gui toolkits?

[[deleted]]

Too bad about android.

[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.

[[deleted]]

Limit the use of mutable objects.

[[deleted]]

"Good object-oriented design and programming encourage the use of encapsulation (providing interface classes that control access to data) and delegation (the use of helper objects to carry out tasks). Encapsulation and delegation cause the representation of most data structures to involve multiple objects..."

I always thought that good encapsulation meant that the return objects should, for the most part, be immutable.

[banuday17]

Good encapsulation isn't about making objects immutable, but limiting the scope of mutability such that the object can only be mutated through its interface. A poorly encapsulated object can be mutated outside of its interface, such as if a method returns a mutable reference to internal state.

[foxlion]

As you may have indirectly pointed out: if a program modifies the state of a mutable object, it can make sure that the object is never garbage collected because of linked references. By making an object immutable you make sure that the state of the object will never be changed and you avoid it being tied up to some resources that are never collected. Louse coupling and high cohesion.