Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Programming

HotSpot arrives 93

Posted by Hemos from the come-and-get-it dept.
ChrisRijk writes "See the HotSpot main-page for starters. HotSpot is basically a fast JVM, initially aimed at server-side Java - beta testers say it's 2x or more faster in real world applications - see this good article (not by Sun). See also the press release, FAQ, and white paper. Freely downloadable binaries available later this week. Linux port? Well, Sun are liscencing the code (for a fee), and claim to have designed it to be easily portable. Sun also announced their i-Planet software today - see this news.com article. "
This discussion has been archived. No new comments can be posted.

HotSpot arrives More

HotSpot arrives

Comments Filter:

  • Beware Corporate-Controlled Languages (Score:2)

    by Anonymous Coward
    Ask yourself this question: What would Java be like now if it was an open language from the start?

    The answer is: Two languages. One supported by Sun which would be secure and platform independant. And the other supported by Microsoft which would be Windows only and insecure.

    Unfortunatly, it would be Microsoft's version which would attract most of the programmers, because Microsoft is very good at wielding their OS monopoly. As a result, not only would we be asking companies for Linux versions of their C/C++ programs, but we'd also be asking for Pure Java versions of their J++ programs.

    Sun fought for, and won the removal of those extentions which would have split the language. Not that I don't think it should eventually be opened up, but if Java was an open language back then, or even if it opened up right now, those extentions would still be around.

    A lot of you don't like Sun, and as a result resent their control over Java. However they know what needs to be done to keep Java alive and they have the lawyers to do it. As long as Sun controls Java, it will still stand for the same things: platform independance, security, and probably some other stuff a more experienced Java programmer could fill in.

    As far as waiting on Java, I somewhat agree with you. I still don't trust it enough to bet the farm on it, but it's the performance issues that worry me, and it looks as if those aren't going to be around long.

  • alpha has *poor* performance (Score:2)

    by Anonymous Coward
    Sorry I'm writing this as A.C. However, I don't want to compromise my company's standing with Sun.

    My company has been an alpha tester of HotSpot for quite a while. I've seen several alpha versions. Each one improves upon the previous by a factor of about 2x. However, the latest alpha (actually, a release candidate) was still 2x *slower* than the JIT in Sun's JDK1.2, under WinNT.

    Our code is *not* in one giant loop. It is, however, heavily dependant upon floating-point calculations and array accesses. To be honest, there are supposedly a few bugs in their floating point math (are they implementing IEEE FP calculations in software???). We'll see if this is fixed in the latest version.

    The garbage collection is *greatly* improved. Unlike JDK 1.1.x and JDK 1.2, you never even notice when the garbage collection occurs (no long pauses).

    I keep hoping that they will optimize out array bounds checking (if your code permits), but I have not seen any evidence of this. Removing array bounds checking has been shown to make heavy computational code (like mine) run about 8x quicker (almost 100% of my computations are performed on data in arrays). Conditionals really screw up a CPU's pipeline, as each array bounds check results in a branch. In fact, the Java Grande group, a group experimenting with numerical algorithms and Java, has shown that with a few alterations to the JVM (removing bounds checking among them), Java runs numerical algorithms about 10% slower than C++! And that's without any dynamic optimization!

    I has been told that the public release is supposed to fix any problems that slow down my code. However, I have not had any pre-release access to this latest code. We shall see.

    All in all, I wouldn't hold my breath. Java is still young, and technologies like HotSpot are still in their 1.0 (pre)release. I hope for the best with HotSpot, but I am afraid it will greatly disappoint most users...
  • Posted by kenmcneil:

    Our long-term goal is to deliver a universal solution beyond just servers, and advance the technology to the client.

    From my knowledge of Java (one year of heavy development) I see no reason why they would develop the VM for just server side applications. As far as I know once you have developed the JNI code it can be ported to any VM. So why is Sun placing this restriction on HotSpot, or is it just a name game?

  • Posted by kenmcneil:

    That's what I figured. The idea that there was any true restraints on its application was unbelievable.
  • According to this article [news.com] on news.com they are going to give away the HotSpot VM.
  • does anyone have comparison between hotspot and oracle's 8i JVM?

    i don't have a spare box for 8i at the moment :0( (running 8.0.5 and 7.3.4 on all our suns)

  • No pass by reference!!!

    Wrapping variables up in other objects to implement a pseudo pass by reference has to be the single most irritating thing about Java ever... Especially when working with strings.

    And java's string classes are a) crap, b) confusing and c) slow.

    I went right back to Perl... faster than most languages for complex string processing, and fast enough for most other tasks.

    Matt.


    perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)'
  • Back at the start many JVMs were purely interpreted, and didn't have JITs, so compared to them, HotSpot will be much faster. Also, the early ones scaled very badly for multi-processor stuff. It's possible that on complex, MP server apps HotSpot really is be 50x faster compared to JVMs from 2 years ago. *shrug*

    Incidentally, that 2x faster is compared to very recent JVMs. Some apps went 4x faster. (read the links I gave).

    • The future of compilation, IMHO, is compiling your code with profiling information included, running your app for awhile, and then feeding the profile back into the compiler for more information to generate your final optimized executable.

      • Sun's professional C/C++ compilers already do this. (I presume there are other C/C++ compilers out there that do the same). It also has some nice run-time checking for memory-leaks...
  • There's an article about HotSpot at news.com here [news.com]. They say Sun changed their minds and decided to make it free. (Sun's stuff doesn't seem to be particularly clear...)
  • IBM's latest: 22.6 SPECjvm (1x 350Mhz PII on NT4)
    Fast JVM: 29.1 SPECjvm (1x 500Mhz Alpha EV6 on Tru64 Unix)
    HotSpot: 31.1 SPECjvm (2x 450Mhz PII on NT4)
    HotSpot: 31.9 Specjvm (1x 450Mhz UltraSparc-II with Solaris 7)

    (don't ask me what diff the dual PII's made for the HotSpot one. unfortunately they don't publish result for single-processor) Also, the 450Mhz UltraSparc-II won't be out for a few more weeks. A 450Mhz PII has 17.2 SPECint95 and 12.9 SPECfp-95. A 450 Mhz UltraSparc-II has 19.6 SPECint95 and 27.1 SPECfp95. A 500Mhz EV6 Alpha is rated as 27.3 SPECint95, and 57.7 SPECfp95.

    I don't have general volano marks available. Also, you can probably see what Sun are initially targeting HotSpot mostly at server side (for now anyway) as the effect is much greater compared to client side (because the longer HotSpot runs for the faster it gets, and because client side has much more interaction with the OS). Check the the article on 'real world' apps posted at the top. 2x, and up to 4x faster in heavy duty real world server apps compared to other recent JVMs is pretty good. The beta-testers particularly praised the high-speed, low latency garbage collector. (wha-hey, Sun build a better bin!).

    As a final note, HotSpot will be getting faster (the 2nd release will apparantly be 30% faster), as will everyone else's of course.

  • performance comparisons (Score:4)

    by ChrisRijk ( 1818 ) on Tuesday April 27, 1999 @01:55PM (#1913334)
    A HotSpot beta-tester wrote a long, detailed article to the newsgroups. You'll probably find it an interesting read. Find it here [altavista.com]
  • Up until today I would have agreeded with you cause that's what they have been saying on the JDC discution boards, but that's not what they are saying on the site today. If you want to use it you will have to pay.

  • note the words single-user server-side. Now what is the point of a single user server? They are going to charge for it else the free beer version wouldn't be limited to one user.

  • Python compilers: JPython [python.org] compiles to Java byte code. Python2C [mudlib.org] translates to C code, but not a lot of people seem to be interested in the project. (Anyone going to review the new Learning Python [ora.com] book for /.?)

    I find the Dylan posts not out-of-line, and they've been enough to interest me in learning more about Dylan; a Dylan book is sitting in my to-read queue, and I'll probably write a /. review of it.

    I'd like to see more language and programming-related items, too, since the business-related items are kind of boring and are usually covered by LinuxToday or LWN anyway. CmdrTaco, how about a new section like the book reviews or "Ask Slashdot", just for technical programming items?

  • Which ones are you talking about? If you're talking free software rather than free beer, that really just leaves us with Kaffe (which is only a PersonalJava implementation, and has never particularly impressed me), and Japhar (which is getting to be pretty good on the standards compliance front, but is currently slow as hell). Then there's ElectricalFire, but that's still some way off.
  • TYA is not a full VM implementation, it's just a JIT which plugs into Sun's VM, using a standard JIT interface. Yes, it can give a useful speed improvement against the Sun/blackdown JDK1.1 implementation. JDK1.2 already includes a JIT (at least on the ia32 platform) so I doubt TIA would make too much difference.
  • let's see how it compares to IBM'snew java (of course, IBM is still at 1.17 vs Sun's 1.2)
  • btw IBM java is free
  • From my point of view that was an excellent criticism, succint, restrained and mature. If Dylan is as good a language as that was a critic, then perhaps you should consider writing some bindings and contributing an app to one of the (high profile) free software desktop environments.
  • Just as suspected, HotSpot isn't intended for the client side; so Java's success will always be limited to a niche of server sided specific applications. Which is pretty sad, since that's far away from what Sun always promised and hoped, making client OSs (Windows...) obsolete.
    ---
  • I agree that dynamic optimization is a very exciting concept and a lot of compiler research is going to go in that direction. However, if it gives Java an advantage over C/C++, it will only be because more resources are being spent improving the Java JVMs and compilers than are being spent improving the C/C++ compilers.

    The initial demonstration of a lot of the concepts in HostSpot are from Self, a O-O prototype-based language, whose implementation does a lot of dynamic optimization. In the Self implementation the optimization actually takes place on machine instructions and not via intermediary VM instructions (which is why the Self implementation is closely tied to Sparc procesors). So having a VM-based language is not a prerequisite for doing these sorts of optimizations.

    The future of compilation, IMHO, is compiling your code with profiling information included, running your app for awhile, and then feeding the profile back into the compiler for more information to generate your final optimized executable.

    Granted that C/C++ aren't dynamic O-O languages, so many of the specific optimizations that Self/HotSpot are doing won't apply, but I still think there is a lot that could be done. And compiled Java, Objective-C, Eiffel, et cetera could all benefit from the HotSpot optimizations done with compiling and profiling as above.
  • It's good to see this come out finally, after the years (literally!) of hype. Dynamic optimization is great technology, and I suspect where a great deal of compiler research will head in the future; it could eventually give Java an actual speed *advantage* over C/C++ (or even hand-tuned ASM), since the fact that it's only semi-compiled means higher-level information is still available at runtime from which to optimize... which is IMHO good in terms of software engineering as well, because it means it'll become even less neccessary (and less possible) to hand-optimize the smeg out of code at the price of maintainability.

    Reading between the lines here, though, it sounds like HotSpot's analysis phase is currently the bottleneck. They keep saying that it's good for server-side application rather than client-side; I suspect that despite their claims that 'server applications are more VM-intensive', this is actually due to the fact that it takes a while during any given session to analyze the code far enough to realize the speedup (less of a problem for servers, for which sessions are typically very long). Of course, there are good ways around this besides just improving the analysis -- specifically, saving analysis info across sessions (ship your app with a baseline analysis, which will then be modified gradually by the user's VM based on their usage patterns).

    -spc
  • I think Java is an amazing language. They skimmed the best stuff off C++, made it easy to use and incredibly fast to run. The only problem is that Sun has it under such a tight leash that the language is stagnating and noone wants to risk going into it. You can't be sure where it's going next.

    I would love to program all my stuff in Java, but I don't think that will happen unless Sun decides to hand Java over to some open committee, where the users can decide on its direction. Until then, I'll use Java for what I can, but I don't think it'll work for everything.


  • Hey a single user version is just great for NPOs that want to have a dope ass java happenin' site.

    --
  • Just some comments and notes.

    primitive data types are not objects, they must be coerced into an object for methods which expect an object, and coerced back for operators which expect a primitive

    No offense intended, but duh. Primitives and objects are two completely different creatures.

    no operator overloading

    So?

    collection classes are not convienent to use (take iterators for example)

    Actually, that's a personal preference. I find the collection classes are quite easy to use. Regardless, it's the same type of construct that you find in the STL in C/C++.

    methods can only return 1 value

    Yes, but. Methods in C or C++ can only return one value as well. In Java, objects are passed by reference, which means you can pass an object into the function, manipulate it in the function, and the changed data stays even when the function exits. Just like references work in C/C++.

  • If you go to the HotSpot page [sun.com], you will see the following:
    (Note: Sun will be offering developers server-side binaries for free download from this website later this week. Check back here for download information.)
    In other words, the code's not done yet! I actually do believe it probably will be done Real (Real, Real) Soon Now, but still, it's humorous :-)
  • And... to acknowledge the "other languages"...
    optimizing the VM means that other languages
    that produce Java bytecode will also be optimized.

    Think of it as a win not only for Java, but for
    Python, Dylan, and other languages that have
    bindings for the Java VM.

    (I don't even use these languages and I'm
    sticking up for them -- is this a violation of
    ./ flame-bait policy?)
  • I don't have numbers, but we ran the HotSpot versus MS JVM and the IBM JVM when HotSpot was
    first available. Both of these blow doors on
    HotSpot. MS JVM was by far the fastest. IBM's
    wasn't far behind. Unfortunately, MS will most
    likely never support 1.2, and IBM's 1.2 support
    isn't finished yet (may be available in Beta).

    If you want to do a real comparison, compare the
    speed of Java code under each of these to the
    same code compiled native using something like
    Visual Cafe or Visual J++.



  • Well, I'm no Java pro, but I've been fairly impressed by the speed of a good JIT on Solaris IF AND ONLY IF you don't let it get anywhere near a GUI. They have a fair number of the key mathematical functions implemented and optimized in native instructions, so those can choke their way by, but both Swing and AWT, easy as they are to work with, just plain suck in terms of power. Ever used HotJava? OH MY LORD! On an old-ish SparcStation, HotJava can't even keep up with scrolling.
    My understanding of the "server side only" statement was twofold: 1st translation) "Sorry, our GUIs still suck guys, come back next year." 2nd impression) Well, the dynamic optimizer has to sit an run for a while before it gets up to speed, so it's better for continually-running server apps.
    I really wish I could write consumer-level desktop apps in Java, but it just doesn't fly right now.
  • They skimmed the best stuff off C++, made it easy to use and incredibly fast to run

    You know, I thought I'd die before I saw the words Java and incredibly fast in the same sentence, without the word NOT inbetween.

    I mean come on, even with Hotspot if speed is your main criteria and you choose Java you deserve to be fired / shot / defenestrated, etc..
  • hotspot is not free. go to the press release and read it, I don't think they've announced pricing but since it's deployable on serverside only I expect some hefty price tags.
  • The Java VM is the perfect place to spend time optimizing and tweaking. Those optimizations are automatically grandfathered into a huge base of precompiled bytecode.
  • that doesn't make it *free*

    sun plans to make money off of this with royaltied distribution costs (free developer SDK is a great way to hook people in) and flat-fee source licensing.

  • If you *need* the speed on the server-side apps, you probably can afford to pay for the software.

    There are plenty of completely FREE JVM's available (many are very fast) -- I don't see why Sun can't charge for something they've sunk so much money into, especially since they said they were going to charge for it from the start.
  • I agree that dynamic optimization is a very exciting concept and a lot of compiler research is going to go in that direction. However, if it gives Java an advantage over C/C++, it will only be because more resources are being spent improving the Java JVMs and compilers than are being spent improving the C/C++ compilers.
    Ya, C++ vendors have only had 15 years to optimize their compilers, Java vendors have had all of 2 years to provide fast JVM's. More effort is *currently* being put towards Java runtime speeds but a bit more C++ optimization's been done in total.
  • i doubt the fastest JVM will be anywhere near as expensive as the fastest production machine.

    :p
  • Man, a few JavaOne's ago (i've forgotten how many!) they were talking about Hotspot would deliver 10-50x increase! I mean, I'll take what performance boost I can get...but *damn*.

    Now the big question is going to be how much will they charge for the real deal. Given how poor and late it is compared to what they promised, they should give us all copies of it with a check for $2.50. But it's far more likely that they'll try to recoup development costs by charging an arm and a leg for the "real" version. Oooo, maybe if I pay double, I can get a 2.5x increase.

  • so is the hotspot.
  • As far as I know they are not going to release
    the source. There are papers about dynamic
    optimization on the self web site. As far as I know the self source code is available. The hard
    thing to do is to get to an practical implementation that doesn't consume too much memory. Memory consumption was one of the problems with Self. Also a solution that is easy to retarget to different platforms is probably also
    a hard thing to do because processors are so different today (Pentium versus Risc).
  • I get very excited when I think about Linux having the ability to do the sort of distributed application tasks that Java 2 promises.

    Currently, NT, COM/COM+/DCOM, and MTS are ruling the roost in this field, but I think it can be done better and businesses love to have alternatives anyway.

    I know Sun is providing limited assistance to Blackdown in order to make Java work on Linux. IMHO, they have very little to lose in getting as much Java stuff running on Linux as possible. Solaris and Linux don't exactly target the same market (SCO is a different matter, hee hee). My personal experience has been that Linux makes a great platform for Java development.

    Companies talk a lot about "mindshare". Tier-1 support for Java on Linux would be a great way to win some.
  • Ask yourself this question: What would Java be like now if it was an open language from the start?

    The answer is: Two languages. One supported by Sun which would be secure and platform independant. And the other supported by Microsoft which would be Windows only and insecure.

    Insecure? How do you figure that?

    Sun fought for, and won the removal of those extentions which would have split the language. Not that I don't think it should eventually be opened up, but if Java was an open language back then, or even if it opened up right now, those extentions would still be around.

    Actually, they won a preliminary injunction which forces the program to ask you if you want to use Microsoft extensions when you write a J++ app (note: not run one). It also made MS include JNI in the JVM.

    Boy. You're just short on facts today, aren't you?

    A lot of you don't like Sun, and as a result resent their control over Java. However they know what needs to be done to keep Java alive and they have the lawyers to do it. As long as Sun controls Java, it will still stand for the same things: platform independance, security, and probably some other stuff a more experienced Java programmer could fill in.

    Funny... for a platform independent architecture, the JVM is pretty optimized for Sparc. eg. float/double types are Sparc format.
  • > I for one will not touch Java until it is fully opened up.

    Well, you'd better start coding. Kaffee is GPL, Classpath and Japhar are LGPL.
  • Wrapping variables (state) in objects is one of the basic ideas of object oriented programming. I don't think that the concept of passing variables by reference is meaningful in OO language like Java.

    IMNSHO, Java string classes are OK. I like them.

    As for Perl: I don't like it. It's too baroque. Sometimes even medieval.

  • Java (Score:1)

    by BunBun ( 33385 )
    Dylan language and its two existing implementations are rather primitive compared to:

    http://www.mozart-oz.org/

    or

    http://www.erlang.org/

    .. and often even Java. For instance: Java lets you dynamicaly construct and load arbitrary class at runtime and also checks code validity. Dylan can't do that.
  • Well Said!

    I actually went to the Dylan site some months ago when I first saw this troll, but having to had read this same idiot post every time there's a Java post on slashdot has definitely made me anti-dylan type of person.

    Great job, AC.

  • Wasn't that 10-50x improvement claim made relative to the interpreted VM (no JIT)? That's about what they're delivering.
  • Copied from the hotspot page:

    (Note: Sun will be offering developers single-user server-side binaries for free download from this website later this week. Check back here for download information.)
  • As understood, the bounds checking "optimization" does not remove the bound checks generally, but rather removes only redundant bound checks identifiable from the flow Dags. Thus, a repeated reference to the same index in the same array in a loop needn't perform a new bound check if the index isn't touched. I believe that's what they were going for.

    Otherwise, as understood, those bound checks are fundamental to Sun's model for Java "safety" semantics. If I could work around the bound checking, I could write into memory all the lovely virus and pirate code I like, ultimately hack around all the security, and that ain't good for an applet loading into a browser.
  • I for one will not touch Java until it is fully opened up.

    There's simply too much of a chance that it will get mangled in the process of Sun trying to screw Microsoft, etc.

    In fact, the entire debacle of Java on Win32 (MS extensions) validated these very dangers.

  • Make the HOs two:
    If you want to stay afloat after next year, you got to learn java.
    And why not betting the farm on it?
    I find it myself a safe bet!
    As string poses it: There are just too serious players involved in (AKA: too serious funds) to let it go away.
    Plus the ethics:
    You can develop in a real OS and let the poor-minded use it in their crappy Mofti$h os...

    ------------------
  • Ever hear of servlets bud? Didn't think so.
  • Sun is going to release the source, but not under its Community Source License (it says this on Sun's site). The source will be available for a flat fee. See here [sun.com] check the third question.
  • Fully agree upto:
    "As far as waiting on Java, I somewhat agree with you. I still don't trust it enough to bet the farm on it, but it's the performance issues that worry me, and it looks as if those aren't going to be around long."
    MHO: If you are not betting on or at least learning (read: writing real code in)Java, you will find yourself WAY behind over the next year or so. There are serious players 'betting the farm' on Java and related technologies... and these people are not about to lose. Even MiSFiT is cranking out new (and improved) VMs...
  • There are a lot of optimizations the compiler can't do in C/C++, because the program can be very sensitive to things like data structure layout. Not to mention the fact that C++ is so complex, it's incredibly hard just to get the compiler right, let alone do fancy transformations.

    Also, because Java defines things like memory allocation and threading, the Java compiler and runtime can cooperate to make optimizations involving those features. In C/C++ you can basically roll your own allocation and threads, which is cool, but it means the compiler doesn't know how to help you and can't make assumptions about what you're trying to do.
  • I don't know if this is public yet, but I haven't signed any NDAs, so here goes ...

    1) IBM research is working on a Hotspot like thing, codename: Jalapeno. They know what they're doing, they have some great people, it should rock. Still a fair way out, though. The interesting part is that Jalapeno is itself written in Java...

    2) IBM is fiercely committed to making Java the COBOL of the 21st century, i.e. the language in which all the crufty old inhouse code is written. That would be interesting.
  • Nothing against Dylan... but it was made by Apple. I wonder if this is merely an extension of the standard Mac-evangelist's "it's-better'cause-it's-Apple-so-there" philosophy.


    As for Java... well, Java Is Cool. It may not be the greatest language for every task but what it does, it does pretty well IMHO.

  • Doesn't gcj (part of egcs) compile java natively?

Slashdot Top Deals

It was kinda like stuffing the wrong card in a computer, when you're stickin' those artificial stimulants in your arm. -- Dion, noted computer scientist

Close