Who exactly wants a vm to host other vms? I don't think anyone here has mentioned any requirement or wish. It is impossible to commoditize every single part of the stack from hardware all the way up to software. Some parts need to remain stationary so time can bespent on actually trying new/different things. We could also replace computers with counting ants moving sand which might be challenging or fun but in the end it's just duplication...
Java was slow in 95 because the hardware was nit ready and no jit existed. Everybody knew they would eventually appear and betting on such an outcome was logical. This sort of duplication is nonsense and something I could not personally understand about harmony. Harmony was a massive effort all for nothing as everyone could just use open jdk or pay sun. Besides android how has harmony helped push computing forward. It's just a copy there's nothing new. Only the license is different, and IMHO who cares when one can just use the real thing from sun. Maybe harmony was a proxy from IBM out of spite but for 99% of the community they are just happy with real java. When Apple decided to drop their official jvm did anyone say let's use Harmony ? I don't think you mentioned it back then becAuse it was obvious that was not reallysensibke. So who exact is going to invent this new vm platform? If Google one if the worlds largest companies didn't start from scratch but built android leveraging java, who would ? Have you tried asm/javassist in android ??? On 17/11/2010, at 7:06 PM, Casper Bang <[email protected]> wrote: > On Nov 17, 8:34 am, Miroslav Pokorny <[email protected]> > wrote: >> Vms that host both for example the CLR and JVM is nonsense due to the way >> each handles classloading for starters. They also use different byte codes, >> which would mean one or both would need to be emulated/translated into the >> instruction set of the other. What you are proposing has never happened in >> the cpu business, even when the Mac left 68000 and started to use power the >> older system had to be emulated. There is no previous example when two >> different systems with different instructions set somehow coexisted as first >> class citizens on a new execution environment. > > The CLR and JVM are more similar than they are different though. I > don't really think it makes sense to compare native instruction sets, > this is after all a designated virtual layer with quite a bit more > flexibility. Even if we do focus on hardware however, remember that an > x86 RISC processor design is really just emulating the CISC > instructions in a fast and intelligent pre-fetcher. > > Also, the fact that Google can write a completely independent register > based VM via manipulating stack based JVM bytecode, goes to show that > at least one way mapping is possible. > >> I dont think many will be happy to adopt a system such as you mention (think >> like IKVM in mono land ) where their application is emulated inside another >> emulated system. Im no expert but having a double layered system of >> emulation must be quite slow no matter how great jit/aot becomes. > > Yeah well, remember when Java first came out? It wasn't exactly > setting any speed records, and took some 10 years with a lot of > assistance from smart people as well as Moore's law to be considered > fast. > >> Why would anyone trust Parrot ? If you thought Java 7 was slow look how long >> it took for Parrot to get their first release out... Do you really want to >> trust the world of computing on something that is that slow to in terms of >> evolution and proven ability to deliver on time ? > > I especially DON'T want to trust any single VM. This whole topic > brought forth by Carl Joki revolves around raising the bar of > abstraction, to not be locked into one particular language nor VM > profile. I'm not saying it's easy, I'm saying it feels like a logical > next step in a world that needs to interoperate. Would I love to > replace my current heavy-weight server JVM, launching applets in the > browser of my laptop? Absolutely... Dalvik sounds like a perfect fit > for that. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
