Aleksey Shipilev wrote: > On Wed, Nov 12, 2008 at 10:52 AM, Wenlong Li <[EMAIL PROTECTED]> wrote: >> In my understanding (also from some related work[1]), the startup >> means the work before executing user's code in main(). So for startup >> optimization, we may think how to reduce the VM creation time, etc. > I'm afraid that definition of startup time as "time to get VM > initialized and ready to execute user code" is loose and does not > reflect the real impression of startup performance end user wants to > have. I presume that user wants to minimize the time it gets for code > to make some work completed: from the moment (s)he invokes JVM to the > moment JVM outputs the value. That's why SPECjvm2008:startup is > actually does *one* iteration of each of the benchmark -- just to > catch up what's the time for VM to initialize, get the user code, > *execute it* and produce some meaningful result.
That's an important use case -- having the runtime optimized for running small workloads, such as start-up run a short workload and tear down (think of script engines etc.); however, I think it is also valid and valuable to decompose the lifecycle and analyze the work involved with just the start-up phase. We did do some work a while ago to make the sharing of ZIP data more efficient (since Gregory demonstrated that there was excessive bytecode data copying taking place). I think there will be additional optimizations in the class library code for making the start-up quicker. Profile the start-up to the point of running main() and make that as slick as possible. Deferring JIT compilation etc is fine, but the best efficiency is to "just run less code". > And so, before actually diving into startup optimizations, it's better > to have the clue what's consuming the time on SPECjvm2008:startup: "VM > init takes X usecs", "classloading takes Y usecs, "JET compilation > takes Z secs", "compiled code takes XX usecs", etc. I had occasionally > prepared that data 1.5 years ago, so we need to do some fresh start. > > On the class sharing: I'm not sure if it helps in single VM scenario, > it's more like reducing the time of classloading when neighbor already > done all the work. Alexey Fedotov have much more expertise on that, > anyway :) These are all good areas to explore, and not at all mutually exclusive. Regards, Tim
