I’m sure you guys could pull it off if Sun actually managed to … er … manage. They could start by allocating some proper budget to the VM engineering team.
Cas 
Well, I also could change the point of view - It would have happend already if SUN wouldn’t try to kid (they call it protect) us with a proprietary license.
Do you think anybody is willed to contribute code to hotspot, which is ownen 100% by a company - they get all your code and you get nothing.
However:
For now the mono_runtime is quite slow and only supports more or less basic optimizations. However it is improving steadily, and there is a project called “ikvm” which translates java-bytecode into .NET-bytecode at runtime which seems to work great.
In near future I plan to help with special awt-peers for the windows.forms interface.
I just do not wait until Sun goes bankrupt or is bought by someone who isn’t interrested in giving us java for free - look at the quarter results, they are (really) bad since 2001!
Btw. one session at FOSDEM was called “Escape the Java trap” or so, but wasn’t there 
Sorry for beeing a bit angry and maybe misinterpreted (so please do not be angry after reading this ),
lg Clemens
That’s ok… unfortunetly Sun has to look at the bigger picture, in which we have to keep both individual customers (you guys) and corporations happy. Its hard to do both, but I think Sun is walking the fine line, very well.
Well, to be honest I think the sun-jvm is quite cool and SUN did a good job developing this piece of software, except:
- The high footprint of the client-jvm
- The long time some bugs need to be fixed
but nobody is perfect and overall its great
The problem the opensource world has with (sun)-Java is the force and control the jvm gives sun if a very large base of oss software would bet on java.
They could do several things to increase their earnings:
- Optimize the jvm only for solaris very agressivle
- Optimize only the SPARC jit good.
- make it only rock-solid on solaris/sparc
- want to have money for the jvm
However this are just wost-case scenarious, but I have seen companies doing the strangest things if they have financial problems (e.g. SCO).
Great that you were not angry about the post…
lg Clemens
[quote]Well, to be honest I think the sun-jvm is quite cool and SUN did a good job developing this piece of software, except:
- The high footprint of the client-jvm
- The long time some bugs need to be fixed
but nobody is perfect and overall its great
lg Clemens
[/quote]
Actually I’m quite interested in footprint metrics, and was wondering if you can tell me why you think the client VM has a large footprint? Any numbers that you can give to give me a better idea of what we should be targeting? Thanks
[quote]Actually I’m quite interested in footprint metrics, and was wondering if you can tell me why you think the client VM has a large footprint? Any numbers that you can give to give me a better idea of what we should be targeting?
[/quote]
- Well, just what cat /proc/pid/status says the JVM needs quite a lot of memory (small swing app):
VmSize: 244272 kB
VmRSS: 52896 kB
VmData: 181688 kB
VmLib: 239185 kB
Maybe the kernel is telling me something wrong, because I don’t know wether I can trust these numbers.
Most of the footprint is code-size and well I think it would be hard to reduce it, because HotSpot is quite a big system.
A strange thing I discovered starting with 1.5 (also with CDS off) is the fact
that much more classes are loaded for my awt-based gui app (~1300) whereas with 1.4 it only needed to load about 700.
A big personal whish:
- A jit-cache. I know a bit hard to realize because of inlining and virtual method optimisations, but well I would have no problems with saving the same methods for every application.
- jit-sharing would also be great, but I think the same problems would occur.
lg Clemens
Actually it shouldn’t be too hard. Just a few methods to the JIT interface like retrieveStartingLinearExecutableImage(buffer) length in eax.
getHash(buffer, length) returns pointer to hash in eax.
So on start it would just call the code
correct = VMstart.code.isValid(buffer);
correct |= VMstart.wasCrash();
if(!correct){
VMstart.flushCache();
VMstart.startNoCache();
return;}
VMstart.load(buffer);
correct = VMstart.CCashe.isValid(buffer);
if(!correct){VMstart.reloadClassesAtStart(true);}
VMstart.Optocode(buffer/null);
VM.setLog(VMStart, nameOfProgram)
VMstart.atLinearExecutablePoint();
return;
Nah…then everyone would just complain about a different set of missing features ;). Although, let’s be honest here: we are talking about the fact that Sun’s JVM does lack major features. The reason is obvious: other things were prioritized, and although there may be some things that individuals can argue - from their viewpoint - should not have been prioritized ahead, personally I think this:
[quote]I’m sure you guys could pull it off if Sun actually managed to … er … manage. They could start by allocating some proper budget to the VM engineering team.
[/quote]
is the real issue that upsets people (although many haven’t quite conceptualized / verbalized it that far).
Sun has **** loads of money, and you know it and we know it. Java is probably the best possible investment for a good billion dollars right now, in terms of the IRR Sun would get on that billion dollars.
I know “it’s never that simple”, but I think in this case it probably really is that simple: java has shown it’s potential, more than anyone could ask for who is refusing to spend on it “waiting to see if it’s really a go-er”. And…it is abundantly clear (and not contested!) that Sun is the bottleneck and the negative restraint on much of Java right now.
It’s one of those no-brainer decisions that, in ten years time, people will write books about how foolish the Sun senior management were, and how they should have got jobs in other tech companies that didn’t have such vivacious IP that needed lively, enterprising, senior mgmt. Comparisons will be made to the Sugared-Water executive who tried to grow a computer company, and nearly ran it into the ground by completely missing the point of the business (I’m sure you all know the example ;)).
You heard it here first, folks.