Why do we need/use managed code (over native)?
Asked Answered
K

5

8

I'm missing something basic here. What's the use of compiling from a source language into bytecode (java) or intermediate language (.NET) and then running them from inside the JVM or CLR ?


There's the decrease in performance (however slight or large) of using managed code, but what are the benefits ? I know there's garbage collection and memory management but even so wouldn't it be better to just compile the source to native straight away without needing this intermediate level ?

Also (I'm adding this here since it's directly related to the question) - Apparently Windows 10 Universal apps are compiled with .NET Native which compiles to native machine code. I'm curious as to why this wasn't done before with all .NET programs.

Kearns answered 16/10, 2015 at 6:31 Comment(4)
One big advantage of bytecode is being able to run it anyway you've implemented the VM. Scope for this is limited in Windows because you're only really targeting a handful of architectures (atom, x86 etc.)Spanner
.NET Native does NOT simply "compile to machine code" it essentially does jit early, so that it does not need to be jitted later on. This is still converted to the exact same machine code that it would be during jit; your egregiously oversimplification of it made it sound like you thought it magically became native c++.Bonnette
@Bonnette I see. But those are not my choice of words, I was quoting from the link I'd mentioned (.NET Native).Kearns
Krythic is incorrect. The .NET Native compiler uses the same set of technologies that power the Microsoft C++ compiler. In fact, the set of code generation technologies used for .NET Native is almost completely disjoint from the JITs built for our non native offerings.Poindexter
T
2

Apart from everything else pointed out in the other answers, major benefits of this approach are the important cost reductions achieved in development and maintenance and the vastly improved scalability of the development environment.

Consider the case where there is no intermediate language; you would need to develop and mantain a compiler for each supported language and each supported platform. Say you have languages L1, L2 and L3 and platforms P1, P2 and P3. This would mean you'd need to develop and mantain 9 different compilers: C1(L1,P1), C2(L1, P2), C3(L1, P3), C4(L2, P1), etc.

On the other hand, having an intermediate common language I lets you develop 3 language specific compilers C1(L1, I), C2(L2, I) and C3(L3, I) and 3 platform specific compilers C4(I, P1), C5(I, P2) and C6(I, P3).

Evidently, the larger your supported language and platform base is, the more signifcant the cost reduction will be.

It also gives you a whole lot of flexibility in future additions of supported platforms or languages; any new language L4 will only require the development of one single compiler C(L4, I) and you inmediately support all platforms for the price of one development. Conversely, if you have a new platform P4, you will only need to develop C(I, P4) and, bingo, you have L1, L2 and L3 all working in P4.

It's basically a win win situation.

Tarrasa answered 16/10, 2015 at 13:8 Comment(0)
H
2

This is from MSDN:

Benefits of managed code

Managed languages provide a generalized way to handle the details of memory management and garbage collection, at the cost of a small amount of overhead. This trade-off frees you from error-prone tasks, and allows you to write more compact, readable, and error-free programs.

Benefits of Un-managed code

If you use an unmanaged language, such as C++, you must write extra code to manage memory and security, and clean up objects after they have served their purpose. The housekeeping details are complicated, and don't relate to the intended function of the program, so developers often neglect these tasks, ignore them, or lose track of them. As a result, unmanaged code is often more costly and time consuming to test, and it requires greater programmer training and discipline.

However, developers often prefer unmanaged code because it executes faster, allows more flexibility in the use of pointers, and gives direct control of hardware.

Heffner answered 16/10, 2015 at 7:11 Comment(1)
It seems Aniruddha Varma's question is not something about managed/unmanaged code. He is wondering why an intermediate language is used in Java / .Net program.Yu
T
2

Apart from everything else pointed out in the other answers, major benefits of this approach are the important cost reductions achieved in development and maintenance and the vastly improved scalability of the development environment.

Consider the case where there is no intermediate language; you would need to develop and mantain a compiler for each supported language and each supported platform. Say you have languages L1, L2 and L3 and platforms P1, P2 and P3. This would mean you'd need to develop and mantain 9 different compilers: C1(L1,P1), C2(L1, P2), C3(L1, P3), C4(L2, P1), etc.

On the other hand, having an intermediate common language I lets you develop 3 language specific compilers C1(L1, I), C2(L2, I) and C3(L3, I) and 3 platform specific compilers C4(I, P1), C5(I, P2) and C6(I, P3).

Evidently, the larger your supported language and platform base is, the more signifcant the cost reduction will be.

It also gives you a whole lot of flexibility in future additions of supported platforms or languages; any new language L4 will only require the development of one single compiler C(L4, I) and you inmediately support all platforms for the price of one development. Conversely, if you have a new platform P4, you will only need to develop C(I, P4) and, bingo, you have L1, L2 and L3 all working in P4.

It's basically a win win situation.

Tarrasa answered 16/10, 2015 at 13:8 Comment(0)
A
0

Bytecode and JVM "shenanigans" mean that the code is always interpreted in the same way, independent of platform it is ran on. I remember vaguely reading long-time ago that Intel and AMD (and also other processors) do some logical operations differently, which leads to different results on those processors and that can result to some cross platform bugs. So bytecode solves that and the result is always constant.

On the other hand, if you know you are programming for just one platform and want extra performance, that is where embedded software development(or low-level languages) comes in. Java and .NET are best used when you know the performance is not that important.

Auxesis answered 16/10, 2015 at 6:55 Comment(0)
Y
0

It is because compiling to native code would make your program platform specified. However, with compiling as intermediate language, your program is portable and can run on every platform if there is a platform specified JVM / CLR.

Both Java and .Net use Just-in-time compilation so that they can provide portability but still better performance compared with using interpreter.

Besides, Microsoft has already provided Ngen together with Visual Studio for compiling .Net code to native code:
https://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx
A main difference between Ngen and .Net Native is that Ngen still depends on .Net Framework and .Net Native compiles the required code of .Net together with the program so installation of .Net Framework is not required.

Yu answered 16/10, 2015 at 6:59 Comment(0)
M
-1

In java when byte code is generated, which is specific to a particular type of architecture, helps to java achieves its 'compile once run anywhere' ability. In addition to that, it takes very less memory.

Moskva answered 16/10, 2015 at 7:6 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.