Slashdot Mirror
Using Java In Low Latency Environments
twofishy writes "Something I've noticed amongst financial service companies in London is a growing use of Java in preference to C/C++ for exchange systems, High Frequency Trading and over low-latency work. InfoQ has a good written panel discussion with Peter Lawrey, Martin Thompson, Todd L. Montgomery and Andy Piper. From the article: 'Often the faster an algorithm can be put into the market, the more advantage it has. Many algorithms have a shelf life and quicker time to market is key in taking advantage of that. With the community around Java and the options available, it can definitely be a competitive advantage, as opposed to C or C++ where the options may not be as broad for the use case. Sometimes, though, pure low latency can rule out other concerns. I think currently, the difference in performance between Java and C++ is so close that it's not a black and white decision based solely on speed. Improvements in GC techniques, JIT optimizations, and managed runtimes have made traditional Java weaknesses with respect to performance into some very compelling strengths that are not easy to ignore.'"
This Slashvertisement brought to you by: Dice.com
I find java helps me with my latency :)
Why would the language of choice matter terribly much if the programmer has skills with the language?
Wouldn't a C++ programmer generate an applicable program effectively as quickly as a Java programmer? It's not like compiling is the time-consuming part anymore...
Do not look into laser with remaining eye.
It's a good thing that these days computers have plenty of memory. It's not quite yet true on smaller devices such as smartphones, but it will be soon. With each year, memory use is becoming less of a problem and how to take advantage of parallel processing is becoming more of a problem.
What a fool believes, he sees, no wise man has the power to reason away.
Java can be compiled to native code.
C and C++ can be interpreted.
You do know that Java is compiled to native, don't you?
The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.
Given the same code written in both C and Java, and including C range bounds checking (to make it as safe as Java), the speed will be the same. Or, quite possibly Java would be quicker once the JVM starts stripping away the checks once it realises there is no possibilities of bounds been breached.
Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.
What a fool believes, he sees, no wise man has the power to reason away.
Traders are typically working with monster servers outfitted with over a hundred gigabytes of RAM, not tiny desktop workstations that need to swap just to move the mouse. I won't say that memory usage is no object, but there is almost no reason not to throw extra memory at a process if it wants it.
Your trading engine runs in Java and leaks four gigabytes an hour? No problem. Just give it 64G of stack and do half an hour of garbage collection after the market closes. Is that not enough? Okay, give it more. Don't have that much available? Get more. Can't afford it? Now you're just pulling my leg. Buying extra memory is cheaper than debugging a live system where any slip-up could cost you thousands of dollars in missed trades or penalties.
It's a weird world, but somehow it works that way.
Languages are not interpreted or compiled. Implementations are compilers or interpreters. These days Java is typically compiled at runtime, instead of ahead of time. Your comment is bogus.
What a fool believes, he sees, no wise man has the power to reason away.
Challenge Accepted!
The chest beating about Java vs C is kinda sad. Look, I've spent the past 20 years hating java with the fire of a 1000 suns, but having been kinda forced to use it lately I've realised its actually not a bad language, in fact its quite neat and well thought out (But god help me, somehow its date handling is even more broken than javascript)
The problem is all the verbose cruft that goes with it. The giant overly complicated frameworks that require configuring 50 different XML files fed through a labrynith undocumented build process that allows you to write terse and insane pattern-madness code ....or alternatively just fire up JDBC and write a bloody SQL query instead.
I think JAVA could shine if people just threw out about 15 years of insane and overly complicated frameworks and took some tips from the python and perl people and replace them with some simple but effective libraries that do one thing and do it well.
But hey, at least its not bloody javascript!
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Java does NOT perform anywhere close to as efficiently as C/C++. You might be able to get message transmissions to take the same time, but the Java environment will undoubtedly take more system resources. The same happens with any through the kitchen sink of libraries at it interpreted language. .Net, Java, Ruby. In my experience Perl runs faster than those 3 but managers have been led to believe that Perl has a slower time to market, thus is slipping from the mainstream. The closer you get to stripped down, just what you need, compiled language, the faster and less system resources the code will take to execute.
The big issue with language decisions these days is that they tend to be driven by perceived market value. People are the most expensive cost to most businesses these days. So the marketing battle between languages focuses less on performance and more on how experienced and expensive your developers need to be. What I see being missed with this marketing is that by lowering the people quality and marginalizing your language and code quality, you are setting yourself up for maintenance, improvement, and performance costs down the road.
There is or can be built a machine that can simulate any physical object. -Church-Turing principle
So now the polls are allowed to have comments, they are for data mining only, not discussion.
Why?
What is the reason we can't talk about the subject of the polls anymore?
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
Java is slow because it is Garbage-Collected, not because it runs in a Virtual Machine.
Memory usage is more important than the virtual machine for performance for anything more complex than calculating Fibonacci numbers, as it affects hard drive swapping and cache misses. That's what is making Java programs **feel** slow. The hard disk is the bottleneck, not the CPU.
You do know that Java is compiled to native, don't you?
Yes, Java can be compiled. It can also be run interpretted. Either way, it runs in a Virtual Machine, which in and of itself adds another layer in the stack and slows the software down, however small the difference may be it will be there.
The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.
Given the same code written in both C and Java, and including C range bounds checking (to make it as safe as Java), the speed will be the same. Or, quite possibly Java would be quicker once the JVM starts stripping away the checks once it realises there is no possibilities of bounds been breached.
And yet in embedded environments the advise when using Java is do to write in software in such a way that the GC is never invoked because it causes major performance penalties at unexpected times.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
I used to work for a company that provided high frequency trading software. We once competed with 4 other companies for a sale to a rather large client, one of them were written in C one was written in C++, the other was unknown. We beat them by 10% (performance was the time a price update was received on the the LAN to the time an order went back out on the wire, as measured from network sniffing device, all tested by them on their hardware). Our software would run 1k-2 warmup/test updates through the system after startup before it went into live trading mode, by then all the critical paths had been fully optimized and compiled to CPU specific instructions. We even tried commercial Java to binary compilers and the standard jvm beat them (after the warmup period). When you compile C/C++ program you usually dont do it for a specific cpu to take advantage of specific instructions, when the JVM JIT kicks in on fully optimized code it is optimized for the specific chip in the computer (again, this is after a warmup period, but in these cases or the case of a web server those are fine). Memory allocation in java is faster than C/C++ and has a higher natural rate of locality of reference, the trade off of course is the gc phase, but using parallel mark and sweep algo's the lock time is relatively small, our customers (your banks) were willing to risk 1 in 1000 transactions being delayed by gc in order to get a 10% boost on over their competitors on the other 999 transactions.
In the end we were acquired by a multinational corp, I gave them the finger, now I work for a start-up.
Wrong. This hasn't been true for more than 15 years 1996. It's a JIT-compiled language, which means it has a slow startup time, but once the VM is warm, it can actually outperform C on numerical code. Really.
He runs all java apps with the -Xint
Interpreter only mode is awesome.
A run time interpreted language that in real life JVM implementations is a run time profiled, optimised and compiled language. That can create better optimised code than any compile time optimiser could because it's optimising against the actual workload instead of guessing what it might be and compromising against many possibilities.
Java is a shitty language with many nasty aspects, you managed to pick the one thing it can get very right. Not much of a programmer then.
The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.
That and C and C++ have faster allocation and deallocation of temporaries. And they have no runtime specification of what's going on, so the optimizer is allowed to do more.
Specifically, C/C++ (one of the few times where such a phrase is meaningful) require the programmer to specify stack allocation or heap allocation. Stack allocated objects are completely free. At the point of function call and return, it simply uses a different size for the increment/decrement.
Java has an excellent heap allocator (very fast) and can do good escape analysis, but very fast is aloways slower than free and escape analysis is never as good as by-hand specification.
In terms of the optimizer, java specifies all sorts of things about how stack traces from exceptions must be accessed and so on. C/C++ don't specify anything about those. As a result, the optimizer is free to remove more stuff than in C/C++ than Java. If you compile with -O3, it's not uncommon to find the debugger thinks you're in a completely different place than seems to make sense.
Or, quite possibly Java would be quicker once the JVM starts stripping away the checks
The thing is, java trades some safety and tighter specification for some performance loss. C and C++ allow the programmer to specify more. While the JVM is very good at removing a lot of stuff, it's always fighting an uphill battle to remove stuff that simply isn't there in C and C++.
SJW n. One who posts facts.
Many JVM implementations can make use of SIMD at run time because they know what they're running on. Additionally, in many algorithms, the pointer indirection cost in C is higher than the bounds checking cost in Java (because pointers make life hard on optimizing compilers, and HotSpot doesn't have that disadvantage). Cache coherency also plays a big role. See the link in my reply to parent comment.
Java runs in a virtual machine, and is compiled "just in time".
For "real time" applications, that need guarenteed latency, this is a no no.
Java's garbage collection, running is also a no no.
Real time applications need hard deadlines, that are deterministic. A function must always return X mSec, regardless of any other things like GC, etc.
Just imagine if say a pacemaker ran Java.
"I detected an unusual event, but I have to run GC first, then process the event..oh, what the patient is dead?"
Why don't we have for ultimate speed, a java interpreter written in java, running on a java interpreter written in java running on... ad nauseaum?
I don't want a 15 min boot time for my embedded system. there is a reason most Android tablets have huuuge lag at unexpected times. Give me access to the bare metal any day. I'll figure out memory management myself, thank you very much!
Then again, I come from the embedded days, when memory was and sometimes still is, measued in Kb, not Gb.
Java is great for student programmers and others of limited skill that need to produce *something* ,at limited cost. They can't really harm the underlying system, and don't need to lean any hard concepts like memory management and real-time deadlines.
Well, let's think about the equivalent of pulling the Java run-time environment for C/C++. That's right, you'd have to pull your operating system. Do you see how that's not even close to a reasonable comparison?
Not only that, but you're not even talking about related types of safety. The Java runtime keeps getting in trouble for poorly handling malicious third party code. If you are writing a java program yourself, it is immensely safer for the reasons GP listed, and you probably aren't in the business of attacking yourself with malware.
Step 1) Don't.
Step 2) See step 1.
C developers often get accused of trying to use their particular hammer to drive in every screw they see. This very much counts as the other side of that equation.
> I think currently, the difference in performance between Java and C++ is so close that...
Additionally the problem is this blowhard is talking out of their ass (SWAG / opinion) instead of showing us cold, hard, facts.
Open Source + Open Data = let the results speak for themselves instead of some opinion that no one gives a fuck about.
Mod Article: -1 Troll
When it's compiled, e.g. by gcj, Java doesn't run in a virtual machine. It's compiled to native code.
The reason it's not done much is that this is actually slower for many tasks than the optimizing JIT is.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
For simple applications that don't deal with a lot of dynamic memory, Java is almost as fast as C/C++. Unfortunately, trading systems are not such - I know because I worked in that domain for some time, in the 1980's and again in the 2000's. Java's biggest issue is garbage collection - it is decidedly non-deterministic. IE, it can have SERIOUS impacts upon performance, and at times that cannot be pre-determined. In my experience (30+ years), if you need consistency and speed, then you do not select Java for your environment - and I do a LOT of Java development. I just don't use it when I need the software to have a small footprint, be fast, and stay out of the way of other system processes.
I suppose as long as the programmers are ACTUALLY equally skilled it would be fine, but from what I've actually experienced in the real programming world, the C++ programmers are generally all fairly experienced skilled programmers who write effective efficient code. With Java programmers, I have seen quite the opposite, sure there are those experienced skilled programmers who could compete, but a LOT of Java programmers even ones with equal 10-12 years of experience, suck monkey balls at actually writing efficient code. Instead they write code that's JUUUST good enough. That said I know a number of people in the HFT market and the programming languages are ALL over the place, sure some of them are in Java and some are in C++, but there's not any one dominating language: there's plenty of Python, Scala, Perl, Groovy, and probably every language you can image. I believe Perl is actually still the biggest language because a lot of the financial analysts can actually write it directly and so do stuff that the front end systems don't normally allow.
More important than the actual runtime environment is that fact that in any networked application that processes lots of data, _latency_ is the bottleneck, not the actual performance of a well implemented* algorithm. The latency between servers, between RAM and the CPU, and even between L3 and L1 (hell, even from L1 to the registers) will have a larger impact on the overall performance than the actual language used. Round trips to and from memory (either local or remote) are what kills performance for most code**. Good programmers know this and optimize for these latencies when implementing an algorithm, regardless of the language.
Even in a low latency environment, well implemented algorithms in scripting languages can outperform poorly written C/C++ and Java. In the financial world, those guys are laughing all the way to the bank (true story).
-Chris
*assume for the sake of discussion that both the Java and C++ implementations are done by good programmers who know how to optimize in their target language.
**remember, round trips occur every time you call a function/method and the stack has to be saved... it's not just data access that triggers this.
FYI the author of that quote is the chief engineer of a C system on which enterprise, low latency trading systems are built. So when he says it, I would tend to give that more than the passing thought.
Those items quoted have indeed been recently shown to bring performance close to similarly developed C++ systems. Though you are right that the layer of indirection will always mean overhead, if you are working low level enough and real time is not your goal, that indirection is what allows your code to be run time optimized and compensate for the cost of the overhead.
And really, until code developed in either reaches the stage of being re-done as an Emacs major mode, how seriously can it be taken?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
For applets in a web-browser. Running a Java server is a different beast with different concerns.
Ram is cheap, and you have control over the max heap size on your java call, so I don't know why you think disk swapping is a problem. Not only that, but garbage collection can actually speed you up in some cases: if you can defer memory management from a time when it would slow you down to a time when you're sitting on free time anyway (waiting for io, etc), you are actually sometimes better off.
Low latency is not measured in the millisecond, but in the microsecond. I'm so tired of hearing about how special the HFT think they are.
... is that you get to rewrite your applications in 2 years? Or less?
You're thinking of Microsoft.
Java is the only programming language I have run across in common usage that incorporates a deprecation mechanism.
When code becomes obsolete, you can tag it as deprecated. It will produce warnings when compiled, IDEs and javadocs will highlight it as deprecated, but it continues to be usable. That means that you can delete the code at your leisure instead of being forced to confront - and fix/bypass broken code when you're doing a completely unrelated emergency repair the way that I had to do far too many times using Microsoft C.
Sun has been extremely conservative about pulling deprecated functions. The Date(month, day, year) constructor has been deprecated for more than a decade, having been pulled because of its inflexibility in regard to timezones and other locale sensitivities. But applications that were coded to use it continue to compile and run to this very day.
Microsoft, on the other hand, yanked an entire SOAP library out from under me while I was still Beta-testing once.
Really I'm not trying to troll here
12 years ago I started in the backing sector in London, and over the last 5-7 years I have been working/involved in the Algo trading arena
I have always used Java to write the Algos
Poor code uses a lot of memory in any language.
Wrong exemple, Facebook has since replaced their C/C++ compiler (HipHop) with the use of a virtual machine and they have gained in performance in the process. http://www.javaworld.com/javaworld/jw-07-2013/130726-facebook-invents-php-virtual-machine.html
Really.
Meh.
http://benchmarksgame.alioth.debian.org/u64/java.php
Or not. Benchmarks are a game and everyone likes to play, except the users of brainfuck for whom creating a program which completes is essentially winning.
The thing is people have been trumpeting "blah is as fast as C/C++/Fortran" since nearly the inception of C and C++ and probably shortly after the inception of FORTRAN.
I think there is a kernel of truth in that the reason C, C++ and FORTRAN/Fortran are always the targets is because they are almost always either the fastest or with a few percent of the fastest.
When people start comparing execution speeds of Haskell, Python, C#, C++, $NEWLANGUAGE etc consistently against Java then I'll believe that Java is indeed king of the hill.
SJW n. One who posts facts.
These are HFT folks, they have essentially unlimited money. Take a TB of RAM, use half for a tmpfs and you no longer worry about IO. A safer route and more expensive would be to just use PCIe SSDs.
Unlimited money solves a lot of problems.
Uh since around 1.3 the JIT optimization for java has led to blindly fast code containing optimizations which are not even available to C++ . Dynamic compiling allows for branch prediction to be more accurately, unlike malloc, the GC knows where to look for free memory and returns it from the last bit of memory you just requested, if you know where pointers are pointing at compile time, you can put them in registers. C++ and other statically compile languages don't have this information, so it stores them in cache, but the JIT can acquire this information and store it in a register. It's the difference between a register to register test and reading from disk.
There are tons of other stuff like this. I don't have it committed to memory, and compiler technology is not my thing but if you look around you'll see that actually GC and JIT are theoretical advantages in terms of speed and those advantages are being realized. It can even figure out what chip it's being run on at runtime and optimize the code for that chip.
The Java is Slow Meme is left over from 1995 before there was even HotSpot.
Not bashing any other language here. C# could also avail itself of these advantages.
Leaving aside my political beliefs that high speed trading needs to be banned, let me say this.
Switching to Java should yield similar results to C++. What matters is whether the programmer understands the memory architecture of the run-time environment well enough to not have issues. Generally, you'll find that even the best programmers in either language will overlook things like garbage collectors and memory fragmentation issues. It's a time-to-market thing. When working with large dynamic data sets, it doesn't matter if you're using Java or C++, the developer needs to be able to adapt their code to perform well on the system.
Code written without considering the processing time of memory management will probably work much better in C++ than Java. That said for huge data sets, Java could perform better since the memory itself is location independent and it is highly probable that you're gain a great deal of performance from being able to defragment memory. Consider however that the garbage collector and the defragmenter will have unpredictable times which can cause multi-millisecond hiccoughs during processing.
I recommend if you take this route, you hire a compiler geek to work on staff optimizing the memory operations.
First I am not saying that Java has no place.
To me this is not a case of Java being fast enough as good enough. Keep in mind these are people who are building their own microwave towers from one exchange to another to shave microseconds. But also keep in mind that this is is also the era of big data. So you now have a situation where you have to process insanely large amounts of data in near as is possible to real time in order to make trades "Now!"
So if I write a test program in Java that connects to a database and adds up a few columns and then compare it to the same program written in C++ I doubt that there will be a big difference. And if you trading algorithm is small then Java is probably best as your time to market will be shorter.
But if you have 5 Gigs of data coming in every 10 minutes that needs to be sifted, sorted, and processed, then again time to market might be better with Java and the processing time might not be that different. But now if you start to get cool and are using crazy Algorithms to squeeze your data dry then you might be pushing up against the limits of the hardware itself. Now you must be in C++ land or you needn't bother. The processing time difference between C++ and Java will be great enough that the market will move faster than your computers can.
Now this last case might seem like the weird case so a person could say well Java covers 95% of our needs. The problem is that if you have no C++ development at all then starting C++ just for this extreme case will not be easy to support. Thus a nice mix of Java and C++ is probably better than just one or the other.
A great example of this sort of experience for us programmers would be Eclipse and Sublime Text 2. Eclipse is mostly Java and for years drove me mad as it would start grinding away at whatever. Or I would start typing code and Eclipse would sit for 10 seconds before a bunch of my typing showed up. It took forever to start and so on. Sublime text starts in a flash, runs at warp speed, and has extra cpu cycles left over for things like the mini-side-view. Again this is not a perfect comparison as Eclipse is much more of an IDE and does 1 billion other things but I find they both are reflective of the Java and C++ philosophies. Java programmers love creating an object for damn near every thought that pops into their heads. They love multiple levels of abstraction. Whereas many C++ programmers are 70% C programmer and 30% C++ programmer which is a near endless war within the C++ world. So C++ programmers tend to head for the simplest possible solution, not the most flexible solution, not even the most maintainable solution.
So in the trading world if I were laying out the staff and the architecture for a large zillion user trading system that will be created and maintained by a large team(s) of programmers then I would stick with Java. If I had a small crack team who are to build a system for implementing an ML system that looks at traffic patterns to predict spot corn prices in the next 5 minutes then C++ all the way baby!
Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.
Yet it is Java that has had its run-time environments pulled for security concerns.
In perspective, the RTEs have been pulled because they had flaws that enabled exploit code to be run. In C, the RTE lets ANY code be run, including exploits, so what's really happening is that Java is falling back to something closer to C levels of runtime security.
The reason for the concern about Java exploitability is that while most sane people have long since given up on download-and-run C code (ActiveX), Java applets (while comparatively rare) have not had exploit concerns until fairly recently. Because until recently, Java's sandbox was considered trustworthy. C/C++ doesn't have a sandbox.
These are HFT folks, they have essentially unlimited money.
Unlimited money solves a lot of problems.
But not, apparently, the problem of an ongoing obsession with making even more money.
systemd is Roko's Basilisk.
mod parent troll, or just -1 ignorant.
Website Hosting
I'm not a Java user, so I've never directly tuned for things like GC, nor do I interact with it directly. Warm up is a different story.
I interact with quite a few exchanges (over all kinds of protocols). Most are, unsurprisingly, written in Java. Almost all of them perform terribly at the beginning of the week. The issue is a standard one: the JVM hasn't JITted important code paths, and it won't until several thousand requests come in. For a standard throughput-oriented program, this doesn't matter -- the total time wasted running interpreted code is small. For a low-latency network service, it's a different story entirely: all of this wasted time happens exactly when it matters.
The standard fix seems to be to write apps to exercise their own critical paths at startup. This is *hard* when dealing with front-end code on the edge of the system you control. Even when it's easy, it's still something you have to do in Java that is entirely irrelevant in compiled languages.
If JVMs some day allow you to export a profile of what code is hot and re-import it at startup, this problem may be solved. Until then, low-latency programmers should weigh the faster development time of Java with the time spent trying to solve annoying problems like warm-up.
This. I've actually personally witnessed a case where a java test application outperformed a (roughly) equivalent C++ application by a startling amount. The two applications were more of a benchmark program than a real app, since it was only testing the timing characteristics of allocating many thousands of objects on the heap, discarding some of them, allocating more, then discarding more, and so on.... The C++ version used the default new and delete operators, while the java version just used the normal new keyword and left the discarding of memory of old objects to the GC. The Java version outperformed the C++ version by more than a factor of 10. Altering the C++ version so that it used custom new and delete operators for the objects, pooling unused objects instead of always just returning them to the heap as the default delete operator did, the C++ version of the application sped up considerably, outperforming the Java version only slightly over a period of about one billion allocations. In consideration of this experience, I think that one is left with answering the question for themselves of whether spending the extra time to specifically optimize a C++ program is truly worth the marginally improved performance. Sometimes it might be... but sometimes it won't.
File under 'M' for 'Manic ranting'
C/C++ doesn't have a sandbox.
C/C++ doesn't have much of anything specified.
There are various ways of sandboxing native code. On the heavyweight end you have something like a hardware assist, i.e. a hardware VM. You can then have things that go all the way down like software VMs, jails, sub-kernels, dynamic binary translation (like bochs, valgrind) to basic kernel based features like using rlimit and running as a nonpriviliged user or starting it in an SELinux/AppArmor context with no access to anything.
On the other end, you have things like Google's NaCl which uses a subset of native code that can be verified to be safe.
Naturally, just like java any of these sandboxes can be when bugs ARE found in the sandboxing mechanism.
But it's perfectly possible to sandbox native code.
SJW n. One who posts facts.
I built a real-time interface to some hardware in Smalltalk 20-years ago! (Yikes!) Since Java and Smalltalk have the same GC theory (at least, simplistically), some of my experiences would translate. I also spent 5-years running high-performance, low(ish) latency stuff in Java too. The simple rules of low-latency Java (or Smalltalk) are: - Create less garbage. Don't tell me that the GC is an issue when you are creating huge garbage. If your application is running in a tight loop (small amount of code being run a LOT of times), spend time on understanding the GC generational model... create only small temporary objects, and really focus on understanding where every object goes. If you can avoid the stop-the-world gc from kicking in (and you can), then most of the issues go away. - Force a GC before you go into low-latency land. This was something I could do in Smalltalk 20-years ago... I would force a GC right before I went into time-sensitive stuff. - Define what you mean by low-latency. I've worked on major systems (100s of millions of financial transactions per day with strict latency requirements) where there was a team dedicated to it, and frankly, Java wasn't nor never would be an option. (In fact, we worked with mainframe operating systems people can't even name anymore!) However, most people don't mean that when they say low-latency. - Finally, if what you really mean is low-latency measured in 100s of milliseconds, that isn't really hard and Java application servers do that in their sleep now. (I've build business transactional applications that do 100,000 transaction with 700,000 SQL calls per second on some standard software and some beefy hardware) Just work inside the best practices space of these products. It is very easy to say "Java doesn't perform" when your code is crap.
Note:
I'm not bashing java. It's an OK language (not my favourite, not my least favourite) and there are many others including much more fun ones for the VM. It does decent stuff and I often use Java programs (minecraft and ImageJ are particularly high on the list).
SJW n. One who posts facts.
including C range bounds checking (to make it as safe as Java),
Those extra cycles to make the code safer will cost an HFT firm tens of thousands of dollars. C is a better choice for these people *because* it allows them to cut corners. I mean, who cares if a bug in your program crashes the exchange when the exchange will just let you reverse the trades?
Give me Classic Slashdot or give me death!
And you'll notice even on your linked counterexample there are 5/11 examples where Java is within the margin of error on CPU time. Take the time to go back and read the link I posted. "Java vs C" goes back and forth depending on the algorithm in question and the cache characteristics of the target platform.
And you'll notice even on your linked counterexample there are 5/11 examples where Java is within the margin of error on CPU time.
Yeah and in the rest C++ is quite definitively faster. In other words as I claimed, C++ is either the fastest or within a small percentage, across the board. There are precious few examples where C or C++ is substantially outperformed by another language (and in almost all of those precious few examples, it's Fortran) and plenty of examples against just about any other languages where it is a clear winner.
Take the time to go back and read the link I posted. "Java vs C" goes back and forth depending on the algorithm in question and the cache characteristics of the target platform.
I did though the one I posted has much more recent results and no dead links. All the benchmarks are similar. In some cases C++ is slightly otuperformed by Java, in other cases C++ substantially outperforms Java.
Mostly it doesn't matter.
But when people routinely benchmark against Java rather than C++, then I'll accept Java as the faster language.
SJW n. One who posts facts.
..jiggabits of ram use isn't inherent for java as such.
it's if you put in gigabytes of libs..
anyhow, maybe they should look for guys who used to do j2me programs, because, uh, you can write java so that you don't trash the gc stupidly and get away with pretty nice things in 300kbytes of heap..
world was created 5 seconds before this post as it is.
Oh god, not this again, this isn't the first time you've made this sort of comment about Java vs. C/C++ and had it pointed out to you how wrong you are.
Then you go on as usual and complain about how unfair it is that you can't get a software development job and claim it's about the unfairness of H1-B and how bad your country is and whatever other excuses you come up with. If you can't even get right what even a bottom of the pile H1-B hire would then what do you expect?
Please read the responses others have given you, they're examples of the few times Slashdot's comment system is great because they're full of people who know what they're on about explaining why you're wrong. Unless you're willing to learn from this sort of thing you're going to forever struggle to find that software engineering job and yes, H1-Bs are going to get them instead of you.
It's an interesting topic as to why Java performs so well now and well worth a read. If you really want to be a developer then you'll find it interesting educating yourself on this. If you don't then maybe software isn't really where your heart is at anyway?
It's hardly a weird world.
Water leaks into basements. Many times, the solution is to use a sumppump to pump the water out rather than a very costly rebuilding of the house and surrounding terrain.
I've bought many products in my life (just recently a car tire pump) that tells you not to run it for more than 15 minutes. It might over heat.
Many people have cars that start leaking oil as they age. They don't spend the money to fix it as long as they can just add enough oil to keep it going.
And who hasn't used duct-tape to seal leaks?
It's hardly a weird world out there.
In consideration of this experience, I think that one is left with answering the question for themselves of whether spending the extra time to specifically optimize a C++ program is truly worth the marginally improved performance.
Probably not in general if the performance gain is marginal, though you've missed one very large aspect of C++ that idiomatically, small temporary objects are allocated on the stack, not the heap, and that's completely free.
In other words, C++ has a worse heap allocator and the properties of C++ make it harder to write a fast one compared to Java, but by default C++ doesn't use it nearly as much as Java anyway.
If you use a library such as Eigen for small, fixed sized matrices and vectors, it's particularly noticable as for even really complex stuff, no heap allocations are preformed. Also, C++ can easily pack unboxed objectes into arrays which makes a substantial difference in locality and number of allocations.
SJW n. One who posts facts.
Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.
Yet it is Java that has had its run-time environments pulled for security concerns.
In perspective, the RTEs have been pulled because they had flaws that enabled exploit code to be run. In C, the RTE lets ANY code be run, including exploits, so what's really happening is that Java is falling back to something closer to C levels of runtime security.
The Java Run-Times were pulled because they were allowing exploits that were not necessarily related to the program being run.
Comparatively, C/C++ programs are generally only susceptible to the flaws in the actual programs, and flaws in their support libraries are only exposed as much as the program allows it to be.
The reason for the concern about Java exploitability is that while most sane people have long since given up on download-and-run C code (ActiveX), Java applets (while comparatively rare) have not had exploit concerns until fairly recently. Because until recently, Java's sandbox was considered trustworthy. C/C++ doesn't have a sandbox.
C/C++ doesn't have a native, built-in sandboxing mechanism. But they can most certainly be sandboxed whether via hardware or software mechanisms.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
round trips occur every time you call a function/method and the stack has to be saved..
Is this always true? Can't the compiler unroll that, or the CPU store the stack info somewhere fast?
I personally find it weird that many systems still push parameters onto the stack and then call the function. That's mixing code and data. Very unhygienic. Security problems and potentially poorer performance.
Well, let's think about the equivalent of pulling the Java run-time environment for C/C++. That's right, you'd have to pull your operating system. Do you see how that's not even close to a reasonable comparison?
True, you'd have to pull the OS for C/C++ when it is providing it dynamically. C/C++ programs (and any native code program) could be using the RTE statically - updating the version in the OS has zero impact on the actual program as it still uses the old version. That said, the C/C++ RTE does not in itself introduce security flaws into the programs that use it, which was why the Java RTE was pulled.
Not only that, but you're not even talking about related types of safety. The Java runtime keeps getting in trouble for poorly handling malicious third party code. If you are writing a java program yourself, it is immensely safer for the reasons GP listed, and you probably aren't in the business of attacking yourself with malware.
Yes, Java keeps getting in trouble for allowing additional code to interface with a program and extend the program in ways the author did not intend. Not possible with C/C++ without some major program specific cracking, and even then it's a program specific attack.
Once in an extremely rare case does a bug in a C/C++ program translate in usuable ways to entire classes of C/C++ programs.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
For applets in a web-browser. Running a Java server is a different beast with different concerns.
The issue wasn't simply related to "applets for a web-browser". The reasons the Java RTE/VMs were pulled was due to how much it affected nearly every enterprise level use of Java in the data center - affecting entire classes of Java programs instead of having program specific attack vectors.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
You mention Java's heap allocator as "excellent" and "very fast"; one reason why is because, for most allocations, it's essentially equivalent to that stack pointer bump you touted as an advantage of C/C++.
One of the positive impacts of garbage collection is that it allows you to coalesce the deallocation phase, which means you don't pay it at all on function exit. Java can also be very aggressive about inlining function bodies (even non-private/"virtual" methods can be inlined in many cases), while you need to be more careful in C/C++ to ensure that the optimizer is allowed to do this, and for virtual methods, it's simply not possible because the optimizer can only do static analysis (at least, not without a much fancier C++ runtime than I've ever seen a compiler use).
Now, I program in all three languages, and I'm not saying Java is a superior language in every respect, particularly when it comes to performance (I would think garbage collection pauses would kill any low latency use, but there are workarounds for that), but it does have interesting performance advantages as well as performance disadvantages. It's not just a simple matter of "more safety" = "less performance" in every case.
C/C++ is much more prone to memory leaks than Java. Yes, you could chase them all down but this takes time. For a long running process this is definitely a factor.
[Citation needed]. I regularly see stories about nasty bugs in the Java plugin for web-browsers that allow drive-by downloads and code execution vulnerabilities. I've never heard of Java having to be pulled from a data-center. I'm not saying it isn't true, I'm just saying I'd like to see more info, because it's the first I've heard of this.
http://javolution.org/
"Javolution real-time goals are simple: To make your application faster and more time predictable!
That being accomplished through:
* High performance and time-deterministic (real-time) classes such as fractal-based collections supporting extended views, closure-based iterations, map-reduce paradigm, parallel computations, etc. Performance of fractal structures (e.g. worst case execution time) is comparable to standard structures for small sizes, but significantly improved for larger size (e.g. FastTable random insertion/deletion in O(Log(n))).
* Most parallelizable classes (including collections) are either mutex-free or using extremely short locking time in order not to impact the worst case execution time of high priority threads (works well only if the VM supports priority inheritance).
* Context programming in order to achieve true separation of concerns (logging, performance, etc).
* Straightforward and low-level parallel computing capabilities with ConcurrentContext.
* Struct and Union base classes for direct interfacing with native applications (e.g. C/C++).
World's fastest and first hard real-time XML marshalling/unmarshalling facility.
* Simple yet flexible configuration management of your application.
* Javolution makes it easy to port any Java application to C++ for native compilation (maven based) or to write Java-Like code directly in C++ (see Javolution C++ Overview)."
Javolution is written and maintained by Jean-Marie Dautelle.
So far Javolution has worked fairly well on a big project with soft real-time needs (although used mainly for the struct and union classes, which is what I originally suggested using it for). Perhaps these sorts of classes should become part of the Java standard library somehow?
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Being a big "C" booster these days, most of my hate is reserved for C++. It is a language with no home. Overly complicated, not as lightweight as C, and not as easy to use as Java or .NET. I could speak at length about its problems.
I'll be the first to admit to the myriad of problems with C++ (compilation speed and difficulty refactoring being my pet peeves) - but it has things that just make life more pleasant over C:
* RAII
* Standard library for algorithms, structures and so on
* Abstraction using templates are free - (well, one byte on the stack) and let you do (admittedly sometimes crazy) flexible things
* Abstraction at all
* Exceptions
You're welcome to your opinion, of course. I feel that C is overly simplistic and encourages re-implementation of the most mundane of things.
One look at things like GObject and GTK should at the very least make you question the sanity of accounting for every little thing. C doesn't leave you any choice - you must micromanage everything.
In .NET, you exactly have the same thing: ObsoleteAttribute. It's not often used, but it does exist.
The Freelance Wizard
When your car breaks down and you need to use duc[kt] tape to hold it together, maybe you're a bit late in getting home that day.
When the systems which run the world's financial markets are treated the same way... well, just open your window and take a look outside.
Good code doesn't ever leak any memory. Leaking 4gb / hour would be atrocious code! Learn to use code profilers.
All those moments will be lost in time, like tears in rain.
If I want to write a program quickly, I write it in Python even though I know the program will run quite slowly.
Which is what I do too knowing that if I need to speed up the code I can rewrite parts in C/C++ and compile them and then call them from Python. This, as far as I understand, is simply not possibly in Java. So if you code in Java there is no way to compile parts of it to get a needed speed boost.
In addition, while anecdotal, by experience with Java apps is that they are incredibly slow, rather unresponsive and crash often. No clue whether that is the programmers fault or Java's but it seems a common 'feature' of many java apps I've seen on the web. So I really am completely amazed that anyone would consider this for a low latency system given the speed and reliability issues that seem to abound with apps written in the language. The last time I coded a low latency system (in C++) we disabled timer interrupts to the Linux OS to prevent the process getting swapped out - somehow I cannot imagine there is a way to do this in Java!
Cheap RAM means you can run bigger and faster C++ apps too you know, not just Java. C++/C will beat java in almost every test that counts because skilled C/C++ developers can write code that handles memory better than most GCs.
All those moments will be lost in time, like tears in rain.
I've seen trading platforms in Java (Island) and was surprised at the number if transactions per second. I don't see Java jobs in London that much but lots of C#. Maybe that's UI work. Bloomberg are very C++ orientated and they're known for their trading platform. Lots of Boost in there AFAIK.
I'll give a concrete example.
Many years ago I had to write code to pull documents across an HTTP link using XML. The docs could be up to 10MB is size, though most were much smaller. I could grab several at a time each polling of the upstream server - up to 20.
Now, in C# or Java you might create a document class that could store the docs, and dispose of it after finishing. This could lead to heap exhaustion / GC / management as large amounts of memory were allocated and deallocated.
In C++ I simply made a buffer as large as the biggest document I wanted to deal with, and kept it in RAM the whole time. The buffer was overwritten many times a second as needed. Since it was always the same memory, there was no heap juggling required. The program ran so fast and smoothly that some financials accused us of cheating since we moved the data far faster then they did.
Sure, you could have written it in Java, but the GC would have taken a thrashing.
All those moments will be lost in time, like tears in rain.
. Since registers are limited and you can call many functions recursively, the data has to go somewhere and that somewhere is the stack. There is no way around that in the general case.
No way? Why not two stacks? One for addresses and one for data. That way even if there is an error you don't end up returning to an "attacker" supplied address (via data). The program might still crash, but it is less likely to "execute arbitrary machine code of the attackers choice" which seems to happen too often.
And also arguably if you keep the data and address stacks separate so that the address stack only ever contains addresses it might be easier to do optimization tricks.
I program in many languages, and I'm not saying Java is inferior.
one reason why is because, for most allocations, it's essentially equivalent to that stack pointer bump you touted as an advantage of C/C++.
Many, not most. For short lived objects, it bumps the pointer for each allocation and every so often scans the new object pool and decides to move them to a larger pool (generational collection).
In C++ the compiler knows the size of the stack frame, so when the function is entered, there is already exactly as much space as needed. The C++ one is still cheaper because it is completely free.
One of the positive impacts of garbage collection is that it allows you to coalesce the deallocation phase, which means you don't pay it at all on function exit.
With the standard allocator, you pay for large objects only on function allocator. For small ones, they dimply disappear as the stack pointer is ajusted to point back to the callee.
Java can also be very aggressive about inlining function bodies (even non-private/"virtual" methods can be inlined in many cases), while you need to be more careful in C/C++ to ensure that the optimizer is allowed to do this,
I disagree: in C++, all methods are non virtual by default, so almost everything is a candidate for inlining. The C++ compiler inlines a lot and actually with its heavy use of functors/lambdas, modern idiomatic C++ code relies on that.
and for virtual methods, it's simply not possible because the optimizer can only do static analysis (at least, not without a much fancier C++ runtime than I've ever seen a compiler use).
GCC does a fair bit of static devirtualisation. I suspect it is not as good as the JVM though, because the JVM can recompile long functions statically.
There are techniques to mitigate this in C++, for example writing loops with function calls using the curiously recurring template pattern, and putting that lot in a virtual function. The end result is much the same as what the JVM does: you get one compiled devirtualised function for each class.
The java solution is much easier to use (all done for you) where as the C++ one is guaranteed to work in all edge cases since you manually specify the devirtualisation.
That said, I personally use very few virtual functions in my C++ code.
SJW n. One who posts facts.
I tend to agree in general. However, for the employers in question, the cost difference between top-notch Java vs. C++ developers is a pittance compared to the potential earnings from the algorithms. Also, they can afford to buy fully trained developers (more to the point, they can't afford not to), so the inequity in training time to get to excellent competency isn't a problem for them. This is somewhat tangential to the point of TFA, though.
- T
I work in the finance industry in London on systems written in Java. and this comment is completely misleading.
First of all, ANY memory leak discovered in this kind of critical Java code is found during testing, using JVM profilers such as this : http://docs.oracle.com/javase/6/docs/technotes/guides/visualvm/profiler.html and is considered a major problem, and a lot of high priority effort is focused on fixing it. Believe me, the "no problem just throw gigabytes more memory in the server" is NOT an acceptable solution - the JVM performance deteriorates as you start to let the heap size grow too high, indeed if Garbage Collection starts at these kind of sizes it can slow to completely unacceptable speeds. It's actually more sensible to let garbage collection run fairly regularly to keep the memory usage limited, and with modern multicore servers you don't notice any penalty for it.
The JVM on the IBM servers these large organisations use is also super optimised for the specific chip sets in the servers - the performance is in a different league altogether to the bog standard Oracle version on your PC.
[Citation needed]. I regularly see stories about nasty bugs in the Java plugin for web-browsers that allow drive-by downloads and code execution vulnerabilities. I've never heard of Java having to be pulled from a data-center. I'm not saying it isn't true, I'm just saying I'd like to see more info, because it's the first I've heard of this.
FYI - in the last year the Java JRE was pulled from all major platforms for at least a while. Quickest story I could find on-line is this one. It was reported on Slashdot back when it happened, and it wasn't simply the browser-plugins, but full JRE. Data centers would have been the most affected; they didn't necessarily pull it but they were under a lot of pressure due to the impact of the JRE vulnerabilities.
The issues in play affected all versions of the JRE going back quite a while, up to and including the latest version at the time. In the last couple months there's been enough patches released to restore JRE functionality, but you have to be using the latest versions. Even then, Java's security perception has been shattered as a result.
Also as a note, there were several rounds of major security issues for the JRE in the last year. They thought they got one fixed and another popped up.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Rather depends on your definition of 'leak' and what you happen to be doing...
Rgds
Damon
http://m.earth.org.uk/
... or you could have written it in Java the exact same way and kept recycling a large buffer over and over without any garbage collection whatsoever..
Agreed.
I run my primary server (which includes my mail and DNS and static http servers, as well as a largeish Java app) on a swapless system. So swapping is never an issue.
And indeed not being forced to free synchronously as the stack unwinds can make Java faster than C++ for example, I second that.
And this "Java is slow because (insert assumption)" stuff is really really old. I can write good or bad code in Java, C, C++, C#, even asm, and I do write regularly in all of those, including real-time code, with cycles being counted where necessary, on hosts with CPU speeds and memory sizes ranging over several orders of magnitude.
Rgds
Damon
http://m.earth.org.uk/
Java can have relative low latency but can never match C or ASM. If you have a soft real time system that doesn't need pin point real time control then I would say Java is fine and a great choice, however if you need tight real time control and you are making a hard real time system then I would say Java and C++ don't work, C and ASM are still the best choices you have great embedded language. C and ASM can do everything that you need and more. I'm not saying Java doesn't have a place in the embedded world but I think it gets to highly valued.
The article you just linked to is describing...wait for it...flaws in the security sandbox which is used for browser plugins. A standard JRE app is not sandboxed, unless you're using a custom ClassLoader for plugins or weird stuff like that. Can you give an example of a datacenter Java application where this would be relevant and how it would be exploited? Why a typical enterprise server app would be running user supplied .class files is beyond me.
You can do exactly the same in Java with ByteBuffers and direct memory if you really want to, for example, and never GC.
On the other hand, for the non-critical 99% of the code you can write it simply and safely and quickly and let GC clean up occasionally if need be.
Rgds
Damon
http://m.earth.org.uk/
It takes a loooooong time.
That is nowhere near the standard meaning of the term "reusability" in a programming context.
I got this one, boys.
Let me translate what you said to a car analogy, then you can see if your statement still makes sense.
"Your car is unsafe because it was recalled due to a seat-belt issue. You should ride a motorbike like me. It's never been recalled for seat belt issues."
.there is enough of everything for everyone.
Your analogies are a resounding endorsement for the use of Java in these applications. Sure it's always breaking, but we have sump pumps and duct tape!
Good points. It annoys me when people claim that Java is faster than C++ because they tested one of the few things where Java really shines performance wise. Basically they're writing a Java program, with its endless allocation/deallocation, in C++, and saying look, Java programs run faster on Java than they do on C++!
Hint folks: you write C++ programs differently. Even in Java constant massive allocation/deallocation is bad form, especially when speed is important. RTFA: one of the tricks they use to speed up Java is to avoid creating a lot of garbage to be collected. Allocation/deallocation is free in any language if you don't do any of it.
The article you just linked to is describing...wait for it...flaws in the security sandbox which is used for browser plugins. A standard JRE app is not sandboxed, unless you're using a custom ClassLoader for plugins or weird stuff like that. Can you give an example of a datacenter Java application where this would be relevant and how it would be exploited? Why a typical enterprise server app would be running user supplied .class files is beyond me.
Any data center app that works as a server. You would certainly be sandboxing stuff there too, for security purposes; just like you would want to sandbox Bind, Apache2, etc. The APIs listed as being vulnerable were not APIs limited to Browser Usage, though they were most likely most commonly used there.
.class file to run on it is beyond me too...but that is part of the design of Java.
Why anyone would allow a user defined (end-user system defined)
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Well, I must say it's still somewhat remarkable how Fortran compilers generally manage to beat C/C++ compilers their collective behinds when it comes to processing large quantities of data. Then again, Fortran tends to be aimed at big data and high performance computing these days.
C++ does not enforce type safety at all.
This is flat out wrong. If anything, via templates C++ has stronger type safety than Java does. Also, stack/heap smashing is orthogonal to type safety.
I don't understand why people find Java faster than C++ to write code in. Any program large enough to require lengthy compiles is large enough that Java is unlikely to be a suitable candidate language, and even if you did write that triple-A game in Java it would take longer to code because of dealing with memory/performance issues.
Directly addressing memory/handling your own de-allocation of memory answers more problems than it creates unless I am writing trivial programs and have access to some magic libraries that I don't have access to in C++. All things being equal, I can code a better program faster in C++. Now, If I was a programmer who never learned/practiced coding with pointers then sure, my Java programming would be faster, but since I am comfortable with pointers/memory allocation schemes etc I find C++ faster. I am suspicious that people who find Java faster for coding large projects are just unfamiliar with C++ and managing your own memory, or are using libraries to do all the work and just don't know of an equivalent set of C++ libraries.
As of Java 7, Java also can allocate objects on the stack automatically with escape analysis.. So in theory C++ and Java are the same in this respect. (It also removes unnecessary synchronized calls in these cases for these objects)
As for other objects Java uses copy collectors for short lived objects that makes cleaning them up essentially free as well. In fact, it is much less expensive than C++ delete calls. C++ still has to run any destructors that are there. In Java finalizers are rare. So short lived objects are much cheaper in Java both on the stack and on the heap in terms of execution overhead related to memory allocation/deallocation.
Well, you could always just buy a new house. And hope it isn't haunted.
Help I am stuck in a signature factory!
Newer JVMs also allocate objects which won't escape context to the stack.
Help I am stuck in a signature factory!
Java only does array range checking when it needs to, at the beginning/end of a loop or at any point where the array ends.
See: https://wikis.oracle.com/display/HotSpotInternals/RangeCheckElimination
Help I am stuck in a signature factory!
People are the most expensive cost to most businesses these days. So the marketing battle between languages focuses less on performance and more on how experienced and expensive your developers need to be. What I see being missed with this marketing is that by lowering the people quality and marginalizing your language and code quality, you are setting yourself up for maintenance, improvement, and performance costs down the road.
Also for catastrophic failures, when a relatively inexperienced programmer does something that someone more seasoned would know to avoid and it makes it through QA to deployment before being triggered.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
That's part of the design of every language. Nothing stops a C programmer from calling "execvp", or a Python programmer from calling eval(), or a PHP programmer from using unsanitized user input to build an SQL query, except common sense and good education. With most languages we call people who execute untrusted code "dumb" (or soon-to-be-unemployed). With Java we call them that too, but some people apparently still think it's okay. Oracle's guidelines point out that if you're relying on the SecurityManager, you're probably doing it wrong (their actual words are "should be scrutinized" and "considered a last resort").
Can the Security Manager add a nice additional layer of protection if you use it correctly? Yes. Is it problematic that the Reflection APIs let you sidestep it? Yes. But if you're running Java in any kind of mission critical setting (i.e., enterprise/server apps), and that's all that stands between you and hostile code, you probably shouldn't have your job.
This constant blending of "C/C++" really bugs me. There is a world of difference in the performance of a non-class based language like C and one which requires hidden instance parameters and dynamic type checking like C++ does. While you can use a C++ compiler to write C code (all methods and variables declared static), the two languages really do not compare for performance nor for ease of use.
The big problem with C and C++ vs. Java is that it requires a lot of experience to write effective memory management with C and C++, and without effective memory management you end up leaking memory or thrashing the system allocator functions. Comparing these languages is like comparing a VW bug to a modern semi-tractor unit. They're just not equivalent in form, function, or intended market.
In the end you have to use the tools that are best suited to the requirements of the task at hand, and in the case of C and C++ code, that includes being aware of the operating system and it's memory management approach, which Java hides from your code.
I've seen no shortage of C and C++ code over the years whose performance sucked because some idiot directly used malloc/free for allocating small objects instead of writing proper allocators that would cache instance memory and reuse it. Conversely, I've seen Java code that tried to implement instance pools in order to override the garbage collector whose performance sucked as a result of the overhead.
The bottom line is an unskilled or inexperienced programmer with can shoehorn crappy performance concepts from other languages into the code at hand. Blame the coder, not the language.
I do not fail; I succeed at finding out what does not work.
Except that you could have used the exact same technique in java, recycling the same object.
Processor stacks are a near perfect candidate for caching. It's likely to exist in L1 cache for the bulk of run time, with close to no cache refills ever happening (typically you write before reading stack values). x86 CPUs are claimed to be optimised for L1 cache stack operands to be as fast as registers, essentially the stack then becomes a large set of extra registers, albeit funnelled through physical ones.
In architectures with large register files a lot of code may never actually touch RAM at all, with only the link pointers pushed to stack for many calls and living in a dedicated stack in some cases.
Stack frames only look like an ugly hack, they have great performance characteristics once you have good enough caching.
I meant something different - Java programs use more memory as a whole - this causes more cache misses, and also more hard drive swapping. The GC algorithms don't matter - they affect CPU usage, not memory usage. The problem is that a Java program uses several times more memory than a comparable C or a C++ program. As I said, the problem is cache misses and hard drive swapping.
And I'm talking about my own experience running Java programs on my not very powerful laptop computer with 3 GB of RAM (no SSD) - I don't use a server at home, the only Java programs I care about are desktop applications, and I've been disappointed there. May be that's why I only hear about Java programs but never see them - because it's only used for server-side programming. I don't use servers.
Stack allocated objects are completely free.
Point of order: stack objects are not free, they're just very cheap. However, you still need to initialize (or were you going to use something without setting it to a known state?) and you need to bear in mind that stacks are generally considerably smaller than the heap. Yes, you can do things like resizing a stack or relocating it to another area of memory when you run out, but those are operations for the extremely brave. And they're expensive too. If I suspect that I even might need them, I just use the heap from the get go as that prevents my hair-loss (and I'll layer a few thread-bound pooled allocators in, which deal with most of the cost of heap usage when stack-based allocation was originally even a candidate in the first place).
"Little does he know, but there is no 'I' in 'Idiot'!"
I know about escape analysis.
It won't make java as fast as C++ for the same reason that alias analysis fails to make C++ as fast as FORTRAN and for exactly the same reason.
In both languages (Java and C++) if you create a local variable, you may well then pass it by reference to some other function. If that function is sufficiently complex, or through a virtual function call, the compiler can't tell if the reference is stored somewhere after that function returns.
In C++ it's up to the programmer not to do that: you're providing a personal guarantee to the compiler that you're not going to do that and woe betide you if you do. In Java, the extra safety means the programmer isn't allowed to offer a personal guarantee with bad consequenced is it's wrong.
It's much the same as restrict in C99: you promise the compiler that no aliasing is happening and it's allowed to give you bad results if it does alias.
Not being a fan of undefined behavior, Java never does that and so optimizations are harder.
Interestingly, though GCC does also do some sort of escape analysis on memory allocations with malloc()/free() (though not new, delete) and can in fact avoid some malloc/free pairs that don't end up doing anything.
C++ still has to run any destructors that are there. In Java finalizers are rare. So short lived objects are much cheaper in Java both on the stack and on the heap in terms of execution overhead related to memory allocation/deallocation.
In C++ can have lighter objects than Java. C++ has the concept of POD (Plain Old Data) which has even expanded in C++11. PODs (and in fact many classes which don't manage resources) have trivial destructors: those that have no code and do not need to be run.
If you make a lot of temporaries of that sort then there are no destructors to be run, and deallocation is completely free because it is included at no cost in the stack pointer bump when the function returns.
An excellent example is the Eigen library. If you work in things like 3D geometry, you end up working with many small, statically sized vectors and matrices, generally 2D, 3D and 4D. These are all basically PODs (certainly under the new rules) and as a result, despite being complex objects with interesting semantics, they are still free to allocate and deallocate on the heap.
I have actually analysed the asm code. Interestingly, GCC can reason about the memory allocation more easily since it's on the stack and therefore it can guarantee that two arrays do not alias. As a result it can perform the most amazing amount of optimization.
TL;DR escape analysis is great (and is equivalent to alias analysis for pointers in C and C++) and therefore I love it. It will yield performance improvements, but will never catch as many cases as stack allocation.
SJW n. One who posts facts.
But it's perfectly possible to sandbox native code.
Actually, I think the BSD crowd prefers the term "jail".
The main difference between Java and native code is that in Java, there's always a sandbox. Native code either has to be self-jailing or some sort of jail has to be externally imposed on it.
I'm not saying this to assert that Java is the One True Language, superior in every way to all others. I'm just being a pedantic little snot.
In .NET, you exactly have the same thing: ObsoleteAttribute. It's not often used, but it does exist.
The cynic in me notes that one of the reasons .Net even exists is that Microsoft's attempted hijacking of Java was quashed. So, one could suspect that they may have lifted the concept from Java.
But if it made the Microsoft world a better place, that's fine by me.
Azul Zing and their Pauseless and C4 collector algorithms are leading the pack of pause-free JVM GC options at the moment..
http://paperhub.s3.amazonaws.com/d14661878f7811e5ee9c43de88414e86.pdf
http://www.azulsystems.com/
Throw more RAM at it. Allocate a little swap space in ramdisk so a few programs that go nuts when there is no swap will be quiet. It's only money.
now we need to go OSS in diesel cars
Yes, but Java programmers would never have this idea, unless they were former C or C++ programmers. They think in terms of objects, not in terms of byte buffers.
I've heard that often Java programs run slow, because there are allocations inside loops, when the same variable can be reused instead. That's because Java programmers are taught not to think about performance.
The big difference, however. is that the JVM can do escape analysis at runtime... and can possibly realize that further optimize is possible.
File under 'M' for 'Manic ranting'