| News | Features | Interviews |
| Blog | Contact | Editorials |
| Project Sumatra improves Java performance with OpenCL |
| By Thom Holwerda, submitted by MOS6510 on 2012-10-10 23:47:06 |
| "Java is a programming language that allows developers to write once and deploy everywhere - from high-end gaming desktops to smartphones. Its OS-agnostic and widespread nature is one of its strongest selling points, but one area where it can fall flat is performance. Generally, Java applications are not going to perform as well as native applications written for a specific OS. However, thanks to Project Sumatra that performance gap may soon become less of an issue." |
|
| RE[2]: Security |
| By tracul on 2012-10-11 09:16:18 |
|
> However as a local desktop platform I don't think Java deserves too much criticism since the language has never been less secure than native apps in the first place. Consider that anything which manages to break out of the java sandbox through a java vulnerability is still access-limited by the same user-space restrictions as a non-VM language like C. While a vulnerability is disappointing, the worst case scenario is that the java app gains access to the same userland syscalls that a native C app can access anyways. The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control) |
 - Score: 1 |
| Java performance |
| By dsmogor on 2012-10-11 10:37:20 |
|
The crux if java performance problems comes not from its raw number crunching abilities (it stands agains c++ in micro benchmarks) but its style of memory mamagement. Moreover JIT has its own memory overhead (runtime performance metrics, heaily instrumented code). Managing memory in pressured conditions takes time, not being able to share heavy runtime between processes adds to it. Having jit take care of branch optimization also made priogrammers prefer more dynamic style (virtual by default). If they used it in C++ (with GC) the resulting runtime performance would be worse. Is summ practical java lower performance is a price paid for programmers convenience more than inherent platform flaw. |
| - Score: 2 |
| RE[3]: Security |
| By the_trapper on 2012-10-11 11:19:24 |
|
> The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control) Until you link against third party libraries. A lot of browser flaws aren't actually Microsoft, Mozilla, or Google's fault. They are due to flaws in things like libjpeg, libpng, or openssl. Java applications are no different, you can think of Java as a big third party library. Even drivers, firmwares, and BIOSes have been known to have remotely exploitable vulnerabilities in them. As a programmer, you never have all the code "under your control" unless you go to extreme lengths like designing your own hardware, firmware, and operating system from scratch. |
| - Score: 2 |
| RE[3]: Security |
| By moondevil on 2012-10-11 11:20:48 |
|
> The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control) Can you enlighten me how are you able to have more control over libc, libstdc++, msvcrt,... than Java developers have over JRE? |
| - Score: 2 |
| Performance is not definitive |
| By JAlexoid on 2012-10-11 12:18:44 |
|
Java performance is not an issue, it's better than most languanges(there's a ton of benchmarks). The issue is JNI performance and deterministic(aka real-time) performance. Edited 2012-10-11 12:19 UTC |
| - Score: 2 |
| RE: Java performance |
| By JAlexoid on 2012-10-11 12:22:57 |
|
> Managing memory in pressured conditions takes time Yep. Java definitely has issues with deterministic performance, but so do most GC'd platforms. |
| - Score: 2 |
| RE[3]: Security |
| By JAlexoid on 2012-10-11 12:25:27 |
|
> Except with Java, isn't the vulnerability potentially cross platform? You have to break out of the sandbox and what you do afterwards is platform dependent. |
| - Score: 2 |
| RE[5]: Security |
| By Alfman on 2012-10-11 14:34:14 |
|
moondevil, "Graal is the project to integrate Maxime JIT which is 100% Java code." I wasn't aware, that's very interesting. I wonder how you bootstrap such a thing. Do you need another VM to bootstrap the Maxime JIT's code? Nice diagram for a project you mentioned: http://labs.oracle.com/projects/... "Even with VM exploits it depends on which VM you are using, there are many more out there, besides Oracle's." I'm not ready to stop calling it Sun's VM :) |
| - Score: 2 |
| RE[3]: Security |
| By Alfman on 2012-10-11 14:52:41 |
|
tracul, "The difference is that you can write 'perfect' java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)" I disagree. A "perfect" ANSI-C program can still be vulnerable to libc bugs (aka malloc, fscanf, etc). Also, modern C code compilation can be incredibly complex. There are memory barriers, aliasing constraints, auto SIMD/pipelining, overflow assumptions, threading related bugs, etc. A bug or bad assumption in any of these features might be remotely exploitable (ie a JPEG rasterization library). To the extent that a JIT compiler is more complex, I'll grant you that it is more likely to contain bugs, but bugs are inherently possible whether the code compilation happens ahead of time or at run time. |
| - Score: 2 |
| RE[4]: Security |
| By kwan_e on 2012-10-11 15:20:10 |
|
> > Except with Java, isn't the vulnerability potentially cross platform? You have to break out of the sandbox and what you do afterwards is platform dependent. But does it? If a Java vulnerability allows the VM itself to be controlled, the exploit can just run Java code with full permissions. Much like how in the past, MS Office's Visual Basic potentially allowed malware to run on a Mac (again, not a security expert, so I don't know if it ended up being just hype, like Y2K). |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |