Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Technology Project and PMC » OT: NexT Gen JVM
OT: NexT Gen JVM [message #19269] Tue, 27 August 2002 11:41 Go to next message
Eclipse UserFriend
Originally posted by: radu.racaru.aldratech.com

Hello everybudy,

If IBM opens now new windows of performance for desktop computing in Java
with the help of SWT/Jface technologies I wonder if it has any plans on
updating its JVM to respond to speed requirements of modern JIT ed
platforms.

For quite a while I've been hearing about how cool JVM will be in the near
future, about technologies that will made JVM better than native code.

One of them is unfortunatly implemented in .NET as a result of M$
"inventivity".

As i know the Java is based in this era on a HotSpot implemetation wich uses
some kind of smart profiling and JIT - interpreted code runing states. This
is cool tech but suks every time on startup of any application.
This is due to the fact that every time you run a java app the JVM makes the
same steps.
..NET uses a JIT only tech and fools the user by imediatly translating the il
code to native and saving the optimizad code for later running. this is so
called assembly.
This feature is neat and could save a bounch of seconds for application
start-up times. Why then not implemet an method of saving profiled and
native data for every app that jvm runned in a special folder for later
refference and usage.
Another trick that could make JVM not suck is to minimize the amount of
memory that it consumes.
Today we know that for each java app we must lauch a separate JVM as a
separate app wich does the same thing TM for every app. This sucks big time!

Why not make a system based on JVM code sharing for every java app. We could
have a process (os proccess) or deamon that is the jvm wich instantiates the
HotSpot and GC components for java apps that it runs. the java.exe will be a
boot strap app that tels that process to create a new instance of hotspot
and GC for that app, not to load an completly new jvm.
Glad to hear your comments,
Regards.
Radu

Report message to a moderator

Re: NexT Gen JVM [message #19499 is a reply to message #19269] Tue, 27 August 2002 21:24 Go to previous messageGo to next message
Anoop Ranganath is currently offline Anoop RanganathFriend
Messages: 2
Registered: July 2009
Junior Member
>> Why not make a system based on JVM code sharing for every java app. We
could
> have a process (os proccess) or deamon that is the jvm wich instantiates
the
> HotSpot and GC components for java apps that it runs. the java.exe will be
a
> boot strap app that tels that process to create a new instance of hotspot
> and GC for that app, not to load an completly new jvm.

I believe this is what Apple does with their implementation of the JVM on
Mac OS X. They gave that code back to Sun for implementation in future
JDKs.

Anoop

Report message to a moderator

Re: NexT Gen JVM [message #19634 is a reply to message #19499] Wed, 28 August 2002 08:05 Go to previous messageGo to next message
Issam Mouslim is currently offline Issam MouslimFriend
Messages: 9
Registered: July 2009
Junior Member
Hope this will be for soon!
whenever I say Java, they say slow and memory consuming

Report message to a moderator

Re: NexT Gen JVM [message #19677 is a reply to message #19634] Wed, 28 August 2002 09:52 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: radu.racaru.aldratech.com

Yep this will rock!
Hope that Sun or IBM are workin on it.

"Issam Mouslim" <imouslim@islandis.com> wrote in message
news:akhv3g$b5a$1@rogue.oti.com...
> Hope this will be for soon!
> whenever I say Java, they say slow and memory consuming
>
>

Report message to a moderator

Re: NexT Gen JVM [message #20812 is a reply to message #19269] Wed, 04 September 2002 17:18 Go to previous message
Renaud Waldura is currently offline Renaud WalduraFriend
Messages: 4
Registered: July 2009
Junior Member
Your suggestions are sensible but nothing new. They're easy to come up with
during a brainstorming session on how to make Java faster, an order of
magnitude more difficult to implement.

Saving the bytecode between invocations is not feasible for Sun (this
question is asked to the VM team at every JavaOne conference), while I
remember hearing about research being done at IBM to implement this "one VM
for all" approach.

A google will certainely tell you more.




"Radu" <radu.racaru@aldratech.com> wrote in message
news:akfnv1$5u6$1@rogue.oti.com...
> Hello everybudy,
>
> If IBM opens now new windows of performance for desktop computing in Java
> with the help of SWT/Jface technologies I wonder if it has any plans on
> updating its JVM to respond to speed requirements of modern JIT ed
> platforms.
>
> For quite a while I've been hearing about how cool JVM will be in the near
> future, about technologies that will made JVM better than native code.
>
> One of them is unfortunatly implemented in .NET as a result of M$
> "inventivity".
>
> As i know the Java is based in this era on a HotSpot implemetation wich
uses
> some kind of smart profiling and JIT - interpreted code runing states.
This
> is cool tech but suks every time on startup of any application.
> This is due to the fact that every time you run a java app the JVM makes
the
> same steps.
> .NET uses a JIT only tech and fools the user by imediatly translating the
il
> code to native and saving the optimizad code for later running. this is so
> called assembly.
> This feature is neat and could save a bounch of seconds for application
> start-up times. Why then not implemet an method of saving profiled and
> native data for every app that jvm runned in a special folder for later
> refference and usage.
> Another trick that could make JVM not suck is to minimize the amount of
> memory that it consumes.
> Today we know that for each java app we must lauch a separate JVM as a
> separate app wich does the same thing TM for every app. This sucks big
time!
>
> Why not make a system based on JVM code sharing for every java app. We
could
> have a process (os proccess) or deamon that is the jvm wich instantiates
the
> HotSpot and GC components for java apps that it runs. the java.exe will be
a
> boot strap app that tels that process to create a new instance of hotspot
> and GC for that app, not to load an completly new jvm.
> Glad to hear your comments,
> Regards.
> Radu
>
>
>

Report message to a moderator

Re: NexT Gen JVM [message #574051 is a reply to message #19269] Tue, 27 August 2002 21:24 Go to previous message
Anoop Ranganath is currently offline Anoop RanganathFriend
Messages: 2
Registered: July 2009
Junior Member
>> Why not make a system based on JVM code sharing for every java app. We
could
> have a process (os proccess) or deamon that is the jvm wich instantiates
the
> HotSpot and GC components for java apps that it runs. the java.exe will be
a
> boot strap app that tels that process to create a new instance of hotspot
> and GC for that app, not to load an completly new jvm.

I believe this is what Apple does with their implementation of the JVM on
Mac OS X. They gave that code back to Sun for implementation in future
JDKs.

Anoop

Report message to a moderator

Re: NexT Gen JVM [message #574137 is a reply to message #19499] Wed, 28 August 2002 08:05 Go to previous message
Issam Mouslim is currently offline Issam MouslimFriend
Messages: 9
Registered: July 2009
Junior Member
Hope this will be for soon!
whenever I say Java, they say slow and memory consuming

Report message to a moderator

Re: NexT Gen JVM [message #574199 is a reply to message #19634] Wed, 28 August 2002 09:52 Go to previous message
Radu is currently offline RaduFriend
Messages: 44
Registered: July 2009
Member
Yep this will rock!
Hope that Sun or IBM are workin on it.

"Issam Mouslim" <imouslim@islandis.com> wrote in message
news:akhv3g$b5a$1@rogue.oti.com...
> Hope this will be for soon!
> whenever I say Java, they say slow and memory consuming
>
>

Report message to a moderator

Re: NexT Gen JVM [message #575082 is a reply to message #19269] Wed, 04 September 2002 17:18 Go to previous message
Renaud Waldura is currently offline Renaud WalduraFriend
Messages: 4
Registered: July 2009
Junior Member
Your suggestions are sensible but nothing new. They're easy to come up with
during a brainstorming session on how to make Java faster, an order of
magnitude more difficult to implement.

Saving the bytecode between invocations is not feasible for Sun (this
question is asked to the VM team at every JavaOne conference), while I
remember hearing about research being done at IBM to implement this "one VM
for all" approach.

A google will certainely tell you more.




"Radu" <radu.racaru@aldratech.com> wrote in message
news:akfnv1$5u6$1@rogue.oti.com...
> Hello everybudy,
>
> If IBM opens now new windows of performance for desktop computing in Java
> with the help of SWT/Jface technologies I wonder if it has any plans on
> updating its JVM to respond to speed requirements of modern JIT ed
> platforms.
>
> For quite a while I've been hearing about how cool JVM will be in the near
> future, about technologies that will made JVM better than native code.
>
> One of them is unfortunatly implemented in .NET as a result of M$
> "inventivity".
>
> As i know the Java is based in this era on a HotSpot implemetation wich
uses
> some kind of smart profiling and JIT - interpreted code runing states.
This
> is cool tech but suks every time on startup of any application.
> This is due to the fact that every time you run a java app the JVM makes
the
> same steps.
> .NET uses a JIT only tech and fools the user by imediatly translating the
il
> code to native and saving the optimizad code for later running. this is so
> called assembly.
> This feature is neat and could save a bounch of seconds for application
> start-up times. Why then not implemet an method of saving profiled and
> native data for every app that jvm runned in a special folder for later
> refference and usage.
> Another trick that could make JVM not suck is to minimize the amount of
> memory that it consumes.
> Today we know that for each java app we must lauch a separate JVM as a
> separate app wich does the same thing TM for every app. This sucks big
time!
>
> Why not make a system based on JVM code sharing for every java app. We
could
> have a process (os proccess) or deamon that is the jvm wich instantiates
the
> HotSpot and GC components for java apps that it runs. the java.exe will be
a
> boot strap app that tels that process to create a new instance of hotspot
> and GC for that app, not to load an completly new jvm.
> Glad to hear your comments,
> Regards.
> Radu
>
>
>

Report message to a moderator

Previous Topic:Problem attaching source to jar
Next Topic:linux versions
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sat Nov 09 04:59:16 GMT 2024

Powered by FUDForum. Page generated in 0.04258 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly