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

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Initializing all Java classes at Start-Up 56

Posted by Hemos from the good-thinking-meekin dept.
Jean-Marie Dautelle writes "Java classes are initialized at first-use only which can introduce significant runtime delays detrimental to real-time or games applications (for which accurate scheduling is often required). To solve this problem, the latest open-source Javolution library supports initialization of all Java classes at start-up (e.g. javolution.lang.ClassInitializer.initializeAll(); // Initialize runtime classes (rt.jar) and all classes in classpath). Note: Runtime class initialization (rt.jar) takes typically a few seconds and about 3 Mbytes of memory."
This discussion has been archived. No new comments can be posted.

Initializing all Java classes at Start-Up More

Initializing all Java classes at Start-Up

Comments Filter:
  • A whopping 3 MB of memory... eh, what the heck, I'll even give 'im 5 'cause I'm so generous!

    On a serious note, This is interesting. I program in java, some games in fact, and I think I'll be checking this one out, just to see if/what an impact it makes.

  • tumbleweed? (Score:4, Funny)

    by Cronky ( 541988 ) <ollie-slashdot@nOsPAm.cronky.net> on Monday November 07, 2005 @07:50AM (#13968612) Homepage
    system.tumbleWeed.initialise() ?
  • "A few seconds" and 3MB of memory for rt.jar sound nice but I wonder how timings and memory consumption would look like with a couple of more libraries in the CLASSPATH, how about a full Eclipse environment?

    The problem with Java startup times is that every Java app loads it's own complete runtime environment. This is not easy to fix, since many apps depend on the fact that they get their own.

    • Re:Benefits for anything other than games? (Score:5, Interesting)

      by breadbot ( 147896 ) on Monday November 07, 2005 @09:05AM (#13969022) Homepage
      Sun has been talking about shared VMs for a while now -- I can't remember if it's scheduled for version 6 or 7 -- the object space would be partitioned among the running Java "processes", but only one JVM would be necessary. It would improve startup times, memory consumption, etc. They could all share one instance of rt.jar, for example, assuming it was process-safe (it may not be now, but fixing it would be something Sun would have to do for the actual release). I don't see it listed in the Java 6 (Mustang) notes (for example here [sun.com]), so I would guess that it's slated for versin 7 (Dolphin).

    • There are benefits outside of gaming, for example, when testing applications, especially distributed ones, a random bit of latency can be the difference between a pass and a fail, and can also be a total bastard to debug, so being able to minimise the unexpected is a welcome tool.

      Regardless of this, the garbage collector can always throw a spanner in somewhere, so it's a moot point.

      • There are benefits outside of gaming, for example, when testing applications, especially distributed ones, a random bit of latency can be the difference between a pass and a fail, and can also be a total bastard to debug, so being able to minimise the unexpected is a welcome tool.

        During testing, wouldn't you want the application to fail if it at all can, to find bugs ? Wouldn't adding random latency help the testing process ?

        Or what did you mean ?

        • Yes, you do want it to fail due to programming errors, but not due to random latency in the VM. Granted, if your application is suffering from that latency you have a problem, but not an easy one to find or fix. If they can get rid of these random errors, then it will be easier to find and fix the real problems.

          • Yes, you do want it to fail due to programming errors, but not due to random latency in the VM.

            If it fails due to random latency in the VM, then it has a programming error. After all, no multitasking system can possibly guarantee certain latencies - the system could have a higher-priority thread running just when your thread needs to be run. Or some piece of data or code you need might be swapped out (altought that can be prevented by locking it in memory). Or something else might go wrong.

            Any program

        • During testing, wouldn't you want the application to fail if it at all can, to find bugs ?

          In most cases, yes; 'though testing usually just proves compliance to an agreed set of interfaces and service levels, the fact that the testing process finds bugs is an agreeable side effect.

          Also the JVM and it's contents may not be under test, they may be part of the test harness.

          Wouldn't adding random latency help the testing process ?

          When testing, we minimise the unknown and then measure one thing at a time.

  • Very, very rarely a good idea (Score:5, Interesting)

    by /ASCII ( 86998 ) on Monday November 07, 2005 @08:47AM (#13968909) Homepage
    There are two reasons why lazy initialization is almost always the better solution:
    • Not all classes are used. Why pay a memory and performance penalty for having e.g. the Java2d API installed if your application never uses it?
    • Startup time will suffer. A 3 second startup penalty for only the bare minimum runtime, and probably much more for any non-trivial application is a huge deal.

    The advantage of doing eager initialization is predictability, and in the case where almost all classes get initialized sooner or later (which would be very rare considering the size of the Java API) a slight performance increase.

    Maybe some kinds of games would benefit from this, but almost all other applications would benefit from more lazy initialization, not less.
    • Well, keep classes in a priority queue. Time spent initializing classes after the post-startup phase is used to prioritize the classes, and set a budget of so many MB. If the 80/20 rule holds, you get most of the benefit for a fraction of the cost.

      When a new class rises to the level of the weakest member of the startup herd, it takes its place. Over time the system will coverge to optimal behavior given the resources you're willing to devote to this purpose, adjusting as the usage of the computer chang
    • There are two reasons why lazy initialization is almost always the better solution

      Of course. No one is questioning this. But the blurb says it is doing this for real-time and game applications. These are the exceptions and not the norm, but are no less valid because they are not the norm.

      Most dynamically typed languages suck like a Hoover when it comes to realtime, so this is a solution that may help.

  • Shameless Plug or Valid Selfpromotion? (Score:5, Interesting)

    by dorkygeek ( 898295 ) on Monday November 07, 2005 @08:56AM (#13968976) Journal

    Let's see. Submitter of story: Jean-Marie Dautelle. Javolution project owner: Jean-Marie Dautelle.

    • Well, Jean-Marie *has* contributed a lot to the Java community. While this particular post may look trivial or not super important, the Javolution framework does have a lot of nice features and is RTSJ (real-time Java) compliant. He's also contributed a lot to JScience, which is another interesting framework for scientific calculations.

      BTW, a lot of realtime Java has to do with deterministic behavior, and lazy initialization is non-deterministic. I don't think the main point here is to save a little bit of
  • At least in terms of unused code. I ran PMD's unused code rules [sourceforge.net] on it and found no problems. Good stuff!
    • Give me a break. All that means is that someone ran the same (or similar) analysis against the code, and deleted everything it complained about.

      At best, I suppose it suggests that the programmer may be thorough and methodical, and I'll grant that those are good attributes for a programmer to have. But it says nothing about security, efficiency, expandability, reusability, and so forth. Certainly, not enough to proclaim "Great code quality".

    • A good IDE, like Eclipse, will visually show you any unused code. No need to run another tool.
      • an IDE will show you unreachable code, not code that is never reached...

        int foo(int x)
        {
            if(x <= 2) return 0;
            int f = factorial(x);
            if(isprime(f){return -1;}
            return 1;
        }

        That never returns -1, but a compiler can't know that

        • And your point with this code?

          With this particular example, it's absolutely certain that if any analysing tool tells you every control path is covered, then it's lying. It cannot tell you however that this code will never be reached, unless you run test cases for an infinite number of numbers, which is hardly achievable in a life time.

          Unfortunately your example is flawed and demonstrates the contrary of what you apparently want to say. However it's a great example to show that tools are just what they ar

  • If you want to dictate how the JVM starts up at a fundamental level, go hack on Apache Harmony [apache.org], the open source Java [javaopen.net] implementation. They're just getting started so your contribution could go a long way.
  • I speed up my java load times by using this tecnique that I like to call C++.

    On a more serious note, one of the problems with load times I have noticed in a lot of Java is that people unnecessarily include namespaces where they don't need/use them. Sometimes there's no reason to go into another library when there's an equivalent function in one you're already using and there's certainly no need to reference things you don't use. That also creates a design problem in addition to the performance issue IMO bec
    • Yes, "import" is a problem. It's such a PITA to identify the actual bits you need, that most code just imports huge chunks of the API.

      Furthermore, "import" has no dependency handling. For instance, org.xml.sax.XMLReader is no use without org.xml.sax.helpers.XMLReaderFactory. Rather than have to manually hunt down the dependencies in the few functions they use, most programmers import org.xml.sax.*.

      In C/C++/Objective-C, at least include files tend to include their dependencies.
    • I don't want to sound adversarial or anything, but please get a clue first...

      The only time that excess namespaces delay processing is during the compilation phase (you know, the *.java -> *.class process). In fact, the class files do not have the concept of import statements, as all class identifiers are fully expanded.

      (this applies only to java, I have no experience on the .Net side of things.)
  • [...] supports initialization of [...] all classes in classpath

    "He who packs his entire wardrobe for a row across the lake becomes the best-dressed fish around." (Source unknown)

Slashdot Top Deals

Whoever dies with the most toys wins.

Close