aspose file tools*
The moose likes Beginning Java and the fly likes JVM as an OS instead of a VM ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "JVM as an OS instead of a VM ?" Watch "JVM as an OS instead of a VM ?" New topic
Author

JVM as an OS instead of a VM ?

justin smythhe
Ranch Hand

Joined: Jul 06, 2012
Posts: 107
I am quite new to programming and IT. So, my questions might sound a little absurd
I was wondering if we could eliminate the OS that lies underneath the JVM. Make the JVM control the hardware and even provide some
standard applications (like Office) under the new JVM to make it a full-fledged OS. Would that not be faster because it would eliminate the
win/mac/linux OS layer. Is this possible ? Is it a good idea ?
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
In my opinion to realize the scenario that you put forth, the underlying hardware would have to be in compliance with Java architecture. That would make it just for Java if you get what I mean. An int variable would always be 4 bytes, so in case you run an application which has a different architecture(written using other standards) it would not run.
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
On further thought...I'll take a parallel here

We have Unix built using C which I assume was done like this - C programs -> .c files . Now if it were a Unix operating system, it would know how to convert these .c files to .machinecode files. If it were Windows, it would need a another layer to do so.

Similarly if we had a Java operating system, it would know what to do with the bytecode files(and convert them to .machinecode). But the same Java operating system would need a layer to understand programs written in .Net
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 567
    
    4

Anything's possible, but I think using the JVM as an OS would be as problematic as, say, using a Pentium processor as an OS. The JVM is a native-mode executable, running in the context of whatever OS loaded it. Once running, it effectively emulates a CPU, with (I am assuming, here) the API relying on the native OS to support a lot of operations that require platform-specific support (like disk i/o, and filesystem navigation, that sort of thing). I suppose you could implement an entire OS in Java, but you would still need some kind of loader to load the JVM, and something at some level to handle all the API calls that presently lead to the host OS doing some of your work for you.

Since the JVM is an executable loaded by an OS it expects will be available for its own use, using it as its own OS would seem to me to be using it kind of backwards.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

An interesting example of what you could consider to be a JVM as an OS would be SunSPOT. SunSPOTs run Squawk virtual machine, which supports a version of Java ME. The virtual machine is loaded from some type of ROM and run by the processor directly.

Do a google search for SunSPOT and Squawk VM.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

Your idea is not completely new, several people have tried writing an OS purely based on Java - see for example JNode and JOS. Even Sun developed something like this, JavaOS. As far as I know none of these efforts have been very successful.

There have even been efforts to create microprocessors that have Java bytecode as their native instruction set - see picoJava. It also never really took off.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Aniruddha Singtalur
Greenhorn

Joined: Aug 15, 2012
Posts: 8

Your Idea is Good, but Using Java to write OS, the OS would be slow since java programs are compiled and intrepreted, thats why most of the system softwares are written in C or C++.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

Aniruddha Sn wrote:Your Idea is Good, but Using Java to write OS, the OS would be slow since java programs are compiled and intrepreted, thats why most of the system softwares are written in C or C++.

That's not true. It's a common misunderstanding to think that Java must be slow because it runs on a virtual machine, so that the bytecode has to be interpreted or compiled to native code at runtime.

Java programs can run just as fast as programs written in C or C++, and potentially even faster. The JIT in the JVM can in principle generate better optimized native code than a traditional ahead-of-time C or C++ compiler, because the JIT can do profile-based optimizations, and optimize the code for the exact processor model that it's running on.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

justin smythhe wrote:I was wondering if we could eliminate the OS that lies underneath the JVM. Make the JVM control the hardware and even provide some
standard applications (like Office) under the new JVM to make it a full-fledged OS. Would that not be faster because it would eliminate the win/mac/linux OS layer. Is this possible ? Is it a good idea ?

I think everyone else has pretty much covered it. I would add though that it IS possible to burn a JVM into a chip - just as you might burn a video driver - so that it loads almost instantaneously (or is made resident). Indeed, I think it has been done for devices like cell phones; but I'm sure the experts will flame me if I'm wrong.

As for Office - I think it would be for MS to come up with a version of the product that runs in a JVM before you'd ever get anything like that.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
Please search; you will find things like this thread from last week on a similar subject.
Aniruddha Singtalur
Greenhorn

Joined: Aug 15, 2012
Posts: 8

Jesper de Jong wrote:That's not true. It's a common misunderstanding to think that Java must be slow because it runs on a virtual machine, so that the bytecode has to be interpreted or compiled to native code at runtime.

Java programs can run just as fast as programs written in C or C++, and potentially even faster. The JIT in the JVM can in principle generate better optimized native code than a traditional ahead-of-time C or C++ compiler, because the JIT can do profile-based optimizations, and optimize the code for the exact processor model that it's running on.

In c++ we can implement same optimisations done by JIT and achieve even higher speeds, but ofcourse the processor specific optimizations will be an overhead to implement.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

Aniruddha Sn wrote:In c++ we can implement same optimisations done by JIT and achieve even higher speeds, but ofcourse the processor specific optimizations will be an overhead to implement.

Yes, and that's the distinction: you can implement them. In Java, they're part of the compilation/bytecode translation process.

Don't get me wrong; I came to Java via C and C++, and I think that both (especially C) have their place. The great thing about Java is that speed is generally less of a concern, and also tends to increase - with no additional input from you, the programmer.

Winston
justin smythhe
Ranch Hand

Joined: Jul 06, 2012
Posts: 107
Jesper de Jong wrote:
The JIT in the JVM can in principle generate better optimized native code than a traditional ahead-of-time C or C++ compiler, because the JIT can do profile-based optimizations, and optimize the code for the exact processor model that it's running on.


How can we demonstrate this ?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

I think it's hard to demonstrate, but I've heard the smart people from Sun (for example Brian Goetz, who wrote the very good book Java Concurrency in Practice) talk about what kinds of optimizations the JVM / JIT can do. There are some very sophisticated things in there. For example, in some cases it can turn virtual method calls into static method calls, which are faster (a virtual method call is indirect, via a lookup table, while a static method call is direct). In a C++ program with virtual method calls, which is compiled ahead-of-time, those virtual method calls will always remain indirect calls - there's no such thing as the JIT that optimizes those calls at runtime.

To really understand how all those advanced optimizations work, you really need to know in detail how the computer works at a low level and what the compiler and the JIT do to your code. It's not an easy subject.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39791
    
  28
It is difficult to demonstrate by viewing the code, since the JVM does not record the machine code it uses.

A few months ago, somebody produced a loop rather like this and said it was an infinite loop. Everybody else disagreed.So what you do is to change that to, and run the loop. Now try the corresponding C programTime it in both versions. You may have to use a different C compiler from mine; I have gcc. One version uses seconds and the other milliseconds.
Amit Ghorpade
Bartender

Joined: Jun 06, 2007
Posts: 2716
    
    6

Sorry if I am hijacking this topic but I think it would be really cool if the JVM does its own pagination, I know that would be an overhead. Still I think it will help in performance due to following reasons
  • It is not OS dependent
  • Reduces usage of actual OS swap space, keeps it free for other applications.
  • The JVM always knows what page is in memory and what needs to be pulled from the swap space.
  • Reduced page faults, this is a bold statement but considering the above point, this would be possible.
  • Just as heap space, the JVM swap space could be user configurable.


  • I am not sure if the JVM already does something like this. I am too lazy at the moment to find it out on my own.


    SCJP, SCWCD.
    |Asking Good Questions|
    Stevens Miller
    Ranch Hand

    Joined: Jul 26, 2012
    Posts: 567
        
        4

    Campbell, I am not sure that C program is a good match. The C while loop will run until i comes full circle back to zero, while the Java while loop will run until overflow, which is half as many steps.

    When I run your programs, the times I get are about 3 seconds for Java, 16 seconds for C. But, if I change the C code so the while loop is this:

    Then the C code also runs in 3 seconds.

    Don't know why the C compiler produces slower object code from the example you've written versus my version, but I think it's not a fair comparison as you've written it. When you have them actually doing the same things, they run about as fast. (Tests run on a 2GHz Pentium IV, Linux 2.6.31 kernel.)
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 4181
        
      21

    Stevens Miller wrote:Don't know why the C compiler produces slower object code from the example you've written versus my version, but I think it's not a fair comparison as you've written it. When you have them actually doing the same things, they run about as fast. (Tests run on a 2GHz Pentium IV, Linux 2.6.31 kernel.)


    I am not a C programmer, but in C, isn't 0 FALSE and any non-zero TRUE? So in Java you would be waiting for the counter to loop back to INTEGER.MIN, while in the C example Campbell wrote you would be waiting for it to loop back to INTEGER.MIN then back to 0. But that is just my hazy recollection from C from many years ago...


    Steve
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 39791
        
      28
    Damn! I thought I Had changed it to while (i != 0)...

    You are right that the C version will overflow and then go through all values until it stops on 0. But then you would expect the C version to take twice as long to run, not five times. I shall try making the two loops more similar to each other.
    Stevens Miller
    Ranch Hand

    Joined: Jul 26, 2012
    Posts: 567
        
        4

    Campbell Ritchie wrote:Damn! I thought I Had changed it to while (i != 0)...

    You are right that the C version will overflow and then go through all values until it stops on 0. But then you would expect the C version to take twice as long to run, not five times. I shall try making the two loops more similar to each other.


    Yes, I do find that puzzling. But (and I will be interested to know your results), what I find even more puzzling is that, if you change the C code to the two-line while-loop I tried above, you get nearly the same performance out of C that you get out of Java. Something about doing the post-autoincrement inside the while test adds a lot of time. If I had nothing pressing to do, I'd look at the assembly code and find out what it's doing. Perhaps someone else will look into that.
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18886
        
        8

    Amit Ghorpade wrote:Sorry if I am hijacking this topic but I think it would be really cool if the JVM does its own pagination...


    You mean like garbage collection, only the JVM would page out objects to disk if they hadn't been used recently, especially if they used a lot of memory? Sounds like a cool idea all right.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8196
        
      23

    Paul Clapham wrote:
    Amit Ghorpade wrote:Sorry if I am hijacking this topic but I think it would be really cool if the JVM does its own pagination...
    You mean like garbage collection, only the JVM would page out objects to disk if they hadn't been used recently, especially if they used a lot of memory? Sounds like a cool idea all right.

    Hmmm. As an old sysadmin, I definitely disagree. Paging is one of those things like mirroring and striping: best left to one thing (the OS or a RAID system) to manage.

    Back in the bad old days, it was quite common for Oracle databases to run slower on RAIDed system than on standard ones (or not as fast as you'd expect), because Oracle db's actually had their own disk management (including about 80 pages of guff explaining how to configure for an n-disk system), so in fact the db and RAID were working in competition.

    Same is true of paging: I certainly wouldn't want bits of software on my system deciding something as fundamental as paging independently. What happens then? Do we have to configure swap space for a JVM? As I understand it, the system is able to swap out unused portions of Java heap space anyway, so why add an extra layer?

    Winston
    Kathleen Angeles
    Ranch Hand

    Joined: Aug 06, 2012
    Posts: 123

    A computer system has a microprocessor and an OS, usually.

    An OS is an interface to talking to the microprocessor.

    A JVM is for talking to 'any' OS (that it is implemented in).

    I think that you are merging 2 layers that should never be done, unless on small devices like mobile phones, where it will be optimum (due to limited memory and resources).
    Amit Ghorpade
    Bartender

    Joined: Jun 06, 2007
    Posts: 2716
        
        6

    Winston Gutkowski wrote:

    Same is true of paging: I certainly wouldn't want bits of software on my system deciding something as fundamental as paging independently. What happens then? Do we have to configure swap space for a JVM? As I understand it, the system is able to swap out unused portions of Java heap space anyway, so why add an extra layer?


    Not my point exactly, disk management is way different from paging. As Paul said, the JVM moves out large recently unused objects to disk and reclaims the memory they occupy. And this does not add any extra layer.
    In theory, the OS would never need to paginate the JVM as it will actually run in its limits. This could mean less page faults. In particular I am talking about systems where the JVMs are quite huge, spanning few Gigs.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8196
        
      23

    Amit Ghorpade wrote:Not my point exactly, disk management is way different from paging. As Paul said, the JVM moves out large recently unused objects to disk and reclaims the memory they occupy. And this does not add any extra layer.

    How doesn't it? In your scenario, it's a piece of software that's allowed to do its own paging independently of the OS; and how could you then guarantee that it is NOT in conflict with the rest of the system? In that respect, I'd say that it's exactly like the scenario I described above.

    In theory, the OS would never need to paginate the JVM as it will actually run in its limits. This could mean less page faults. In particular I am talking about systems where the JVMs are quite huge, spanning few Gigs.

    A few points here:
    1. Swap space is normally defined by the OS; and it's done in such a way as to provide fastest access, including mirroring, disk-spreading, dedicated storage, or simply putting it in sectors closest to the rest position (admittedly probably old hat in these days of huge cache disks). How could you do this for a JVM?
    2. Conflict/layering - If your JVM 'swaps out' a large object, what becomes of that memory? Can the system now swap it out, or is it 'resident' as far as it's concerned? If the latter, I can't see any way that your idea prevents paging, since the JVM is actually likely to take more memory than it needs to, in order to make it all 'manageable' by the JVM. And if the first, then the same piece of memory has a good chance of being swapped out twice in intense situations.
    3. Memory is cheap - If you have a JVM that is likely to span several gigs, then add a few more for the OS. That is the surest (and cheapest) way to prevent paging.

    The only possible benefit I could see for your idea would be for 'swap ins'. A JVM could possibly manage it's own swap space like a hashmap or database, providing added speed for pulling specific objects back from disk. I just don't think there's a sufficient case to warrant it.

    Winston
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: JVM as an OS instead of a VM ?