You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Brad Cox <br...@gmail.com> on 2005/05/16 02:23:04 UTC
Introduction, and a question
Hello. I'm an old-timer with OO languages (Objective-C originator) but a
newcomer to open source. I've just signed up to this list because
Harmony sounds like something I could really get excited by. I'd welcome
suggestions as to how to get started, traps to avoid, etc.
I'll start by venturing what I suspect might be a naive question. Java
is fast enough once it gets its legs beneath it, but the classloader is
giving it a bad rap for speed. That's my impression, not measured fact.
Has there been any consideration to stealing an old trick from
Smalltalk/Lisp environments...a "restart" option that reloads the
dynamic state saved by a previous execution, typically one that has just
completed loading an app's classes but before run-specific instances
were created?
I seems too simple to not have been tried, particularly with such as
Peter Deutch involved with the JIT compiler.
Re: Introduction, and a question
Posted by Brad Cox <br...@gmail.com>.
Doubt it would/should be done automatically. Checkpoints would be
triggered by a checkpoint() library call which would save the executable
state as an executable file (and exit without returning). When the file
is executed, execution would resume as if returning from the
checkpoint() function.
Christian Damsgaard wrote:
> I brought up this idea with Lars Bak (HotSpot architect at Sun back
> then) at a conference some years back when Sun introduced the HotSpot
> VM. The argument back then was that a program mays not execute in the
> same pattern every time and the optimization made previously may no
> longer apply.
>
> Regards
> Christian Damsgaard
>
> Brad Cox wrote:
>
>> Hello. I'm an old-timer with OO languages (Objective-C originator)
>> but a newcomer to open source. I've just signed up to this list
>> because Harmony sounds like something I could really get excited by.
>> I'd welcome suggestions as to how to get started, traps to avoid, etc.
>>
>> I'll start by venturing what I suspect might be a naive question.
>> Java is fast enough once it gets its legs beneath it, but the
>> classloader is giving it a bad rap for speed. That's my impression,
>> not measured fact.
>>
>> Has there been any consideration to stealing an old trick from
>> Smalltalk/Lisp environments...a "restart" option that reloads the
>> dynamic state saved by a previous execution, typically one that has
>> just completed loading an app's classes but before run-specific
>> instances were created?
>>
>> I seems too simple to not have been tried, particularly with such as
>> Peter Deutch involved with the JIT compiler.
>
>
>
>
Re: Introduction, and a question
Posted by Steve Blackburn <St...@anu.edu.au>.
Take a look at Quicksilver (no longer active).
http://www.research.ibm.com/quicksilver/
"The Quicksilver project is exploring novel compilation models for Java.
Our goals are to support deep analysis, aggressive optimization,
testability and control over executables, all in the context of a fully
compliant Java system. Our prototype is implemented within the Jalapeño
compiler project."
--Steve
Christian Damsgaard wrote:
> I brought up this idea with Lars Bak (HotSpot architect at Sun back
> then) at a conference some years back when Sun introduced the HotSpot
> VM. The argument back then was that a program mays not execute in the
> same pattern every time and the optimization made previously may no
> longer apply.
>
> Regards
> Christian Damsgaard
>
> Brad Cox wrote:
>
>> Hello. I'm an old-timer with OO languages (Objective-C originator)
>> but a newcomer to open source. I've just signed up to this list
>> because Harmony sounds like something I could really get excited by.
>> I'd welcome suggestions as to how to get started, traps to avoid, etc.
>>
>> I'll start by venturing what I suspect might be a naive question.
>> Java is fast enough once it gets its legs beneath it, but the
>> classloader is giving it a bad rap for speed. That's my impression,
>> not measured fact.
>>
>> Has there been any consideration to stealing an old trick from
>> Smalltalk/Lisp environments...a "restart" option that reloads the
>> dynamic state saved by a previous execution, typically one that has
>> just completed loading an app's classes but before run-specific
>> instances were created?
>>
>> I seems too simple to not have been tried, particularly with such as
>> Peter Deutch involved with the JIT compiler.
>
>
Re: Introduction, and a question
Posted by Torsten Curdt <tc...@apache.org>.
> True, but if you saved the entire state of the JVM memory on disk (an
> JVM 'hibernation'?) then you could just start from where you left,
> instruction pointer included.
huuuh ...that would be awesome!
> Not sure how hard it is to write, but doesn't sound like a bad idea to me.
absolutely!
cheers
--
Torsten
Re: Introduction, and a question
Posted by Ian Darwin <ia...@darwinsys.com>.
> >True, but if you saved the entire state of the JVM memory on disk (an
> >JVM 'hibernation'?) then you could just start from where you left,
> >instruction pointer included.
>
> Just one _teensy_ snag. Open files and sockets. And all state external
> to the JVM.
No, that's not the snag. This is not a new idea, as pointed out Emacs and other
stuff has used it for years. The actual technique is you pre-load the application
but don't start it running (see also the Zombie calls in JikesRVM). Since it hasn't
been started, there is no external state, no open files, etc.
As is now obvious, the snag for doing it in Java is: how do you know what classes
to load and precompile? There is no right answer, but the simple answer is to inspect
the byte code for all classes that are instantiated. This works for the cases without
dynamic loading, so HelloWorldJDBC.java won't run. Unless you also support dynamic
loading in your VM.
Re: Introduction, and a question
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> Christian Damsgaard wrote:
>
>> I brought up this idea with Lars Bak (HotSpot architect at Sun back
>> then) at a conference some years back when Sun introduced the HotSpot
>> VM. The argument back then was that a program mays not execute in the
>> same pattern every time and the optimization made previously may no
>> longer apply.
>
>
> True, but if you saved the entire state of the JVM memory on disk (an
> JVM 'hibernation'?) then you could just start from where you left,
> instruction pointer included.
Just one _teensy_ snag. Open files and sockets. And all state external
to the JVM.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Introduction, and a question
Posted by Zaw Win Aung <zw...@gmail.com>.
I think what Brad brought up is good. Do we have any way to optimise
the saved classes for current environment before instantiation.
On 5/16/05, Stefano Mazzocchi <st...@apache.org> wrote:
> Christian Damsgaard wrote:
> > I brought up this idea with Lars Bak (HotSpot architect at Sun back
> > then) at a conference some years back when Sun introduced the HotSpot
> > VM. The argument back then was that a program mays not execute in the
> > same pattern every time and the optimization made previously may no
> > longer apply.
>
> True, but if you saved the entire state of the JVM memory on disk (an
> JVM 'hibernation'?) then you could just start from where you left,
> instruction pointer included.
>
> Not sure how hard it is to write, but doesn't sound like a bad idea to me.
>
> (wasn't this was EMACS was doing with the 'core dump trick'?)
>
> --
> Stefano.
>
>
Re: Introduction, and a question
Posted by Stefano Mazzocchi <st...@apache.org>.
Christian Damsgaard wrote:
> I brought up this idea with Lars Bak (HotSpot architect at Sun back
> then) at a conference some years back when Sun introduced the HotSpot
> VM. The argument back then was that a program mays not execute in the
> same pattern every time and the optimization made previously may no
> longer apply.
True, but if you saved the entire state of the JVM memory on disk (an
JVM 'hibernation'?) then you could just start from where you left,
instruction pointer included.
Not sure how hard it is to write, but doesn't sound like a bad idea to me.
(wasn't this was EMACS was doing with the 'core dump trick'?)
--
Stefano.
Re: Introduction, and a question
Posted by Christian Damsgaard <ch...@damsgaard.biz>.
I brought up this idea with Lars Bak (HotSpot architect at Sun back
then) at a conference some years back when Sun introduced the HotSpot
VM. The argument back then was that a program mays not execute in the
same pattern every time and the optimization made previously may no
longer apply.
Regards
Christian Damsgaard
Brad Cox wrote:
> Hello. I'm an old-timer with OO languages (Objective-C originator) but
> a newcomer to open source. I've just signed up to this list because
> Harmony sounds like something I could really get excited by. I'd
> welcome suggestions as to how to get started, traps to avoid, etc.
>
> I'll start by venturing what I suspect might be a naive question. Java
> is fast enough once it gets its legs beneath it, but the classloader
> is giving it a bad rap for speed. That's my impression, not measured
> fact.
>
> Has there been any consideration to stealing an old trick from
> Smalltalk/Lisp environments...a "restart" option that reloads the
> dynamic state saved by a previous execution, typically one that has
> just completed loading an app's classes but before run-specific
> instances were created?
>
> I seems too simple to not have been tried, particularly with such as
> Peter Deutch involved with the JIT compiler.
Re: Introduction, and a question
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 15, 2005, at 8:23 PM, Brad Cox wrote:
> Hello. I'm an old-timer with OO languages (Objective-C originator)
> but a newcomer to open source. I've just signed up to this list
> because Harmony sounds like something I could really get excited
> by. I'd welcome suggestions as to how to get started, traps to
> avoid, etc.
>
> I'll start by venturing what I suspect might be a naive question.
> Java is fast enough once it gets its legs beneath it, but the
> classloader is giving it a bad rap for speed. That's my impression,
> not measured fact.
>
> Has there been any consideration to stealing an old trick from
> Smalltalk/Lisp environments...a "restart" option that reloads the
> dynamic state saved by a previous execution, typically one that has
> just completed loading an app's classes but before run-specific
> instances were created?
No, but that's a good one :)
>
> I seems too simple to not have been tried, particularly with such
> as Peter Deutch involved with the JIT compiler.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org