faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Native code FUD
by Mike Hearn on Monday 09/Aug/2004, @02:11
|
The other problem with JITing runtimes tends to be memory pressure, which impacts desktop performance far more than CPU overhead these days.
I think most of the advantages of JIT compiled code are bogus. Security is not to me a convincing argument as the only security you gain is via type-checking, which is not fine grained enough for real world security. For instance you can prove the code does not use the File object, but you cannot restrict which files it can access and when (at least, not without seriously hacking the class library sources itself). A worse-is-better approach seems to be an SELinux style one, where security is applied at the process level rather than the type level, but policy is easier to specify and more flexible.
CPU independence - please. The CPU is already abstracted by the compiler, no need to do it twice given the dominance of x86 (on the desktop, it may be more useful on the server).
Easier to examine the code: well, there is no rule that says you cannot have reflective native code, and indeed gcj/java does exactly this.
I don't have a strong opinion on Java vs Mono, but right now it seems they are evenly matched. Mono has the community momentum and nicer APIs (at least for GTK developers) but GCJ has a more traditional toolchain and produces native code that is easily integrated with existing systems. It also seems to have easier integration with native code via the CNI and the upcoming GDirect thing (similar to P/Invoke). I do not know which will "win", but I suspect they will both be strong. Right now Mono seems to be in the lead if only because there aren't any "real" desktop Java apps outside Eclipse that are in wide use on Linux. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Native code FUD
by Philippe Fremy on Monday 09/Aug/2004, @03:04
|
I don't have an opinion on this Java vs Mono but somehow, seing the debate reminds me a bit of the java momentum, when java was supposed to replace everything and of the orbit vs dcop/kpart debate too.
We sure like to have heated discussion with technical arguments...
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Monday 09/Aug/2004, @09:37
|
"The other problem with JITing runtimes tends to be memory pressure, which
impacts desktop performance far more than CPU overhead these days."
These problems can easily eliminated by caching the results. The advantage is
that you can do best-case optimizations that a static compiler can't afford, - if the worst-case happens a dynamic compiler can still recompile at runtime. But that doesnt mean that it needs to happen frequently.
"I think most of the advantages of JIT compiled code are bogus. Security is not to me a convincing argument as the only security you gain is via type-checking, which is not fine grained enough for real world security. "
There are two things that you need for Java-like sandboxing:
1. you need to integrate security checks in all libraries that communicate with the world outside of the process/VM and should be used by the sandbox'd code
2. you need to make sure that the only way to access any part of the system is using the public APIs
With native code, number 2 becomes very hard.
"For instance you can prove the code does not use the File object, but you cannot restrict which files it can access and when (at least, not without seriously hacking the class library sources itself)."
Java allows this:
http://java.sun.com/j2se/1.4.2/docs/api/java/io/FilePermission.html
"A worse-is-better approach seems to be an SELinux style one, where security is applied at the process level rather than the type level, but policy is easier to specify and more flexible."
This allows only very low-level security. For example Java allows that applets in a sandbox can create windows, but only if the window has a large warning sign. Try enforcing that with SELinux.
"CPU independence - please. The CPU is already abstracted by the compiler, no
need to do it twice given the dominance of x86 (on the desktop, it may be
more useful on the server)."
Even if there would be only x86, there are already more than enough variants through extensions. 32-bit and 64-bit, MMX, 3DNow, SSE, SSE2...
Managed code also has the advantage that it will give x86 CPU vendors more room for improvement. Right now they have the problem that even if they come up with a good (low-level) extension, there will hardly any software that makes use of it.
"Easier to examine the code: well, there is no rule that says you cannot have reflective native code, and indeed gcj/java does exactly this."
That's examining at runtime and not what I meant. I was talking about analysing and modifying programs that are stored on the disk in their distribution format.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Mike Hearn on Wednesday 11/Aug/2004, @05:16
|
Yes, you can enforce such windowing policies with SELinux (or more accurately the in-development SE-X). SELinux policy can be propogated up into userspace object managers.
As to the other points, well maybe but I've not seen much software that would benefit from such on the fly optimization. Algorithmic optimization usually matters far more.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
