The thoughts of the ignorant
Rob L'Estrange
I've got a thought. It's probably stupid but the end result will be that
I'll be enlightened I'm sure hehe
To me, starting a new instance of the JVM for each Java application seems a
bit wasteful of machine resources. Instead of running each new application
on it's own JVM using main(), why wasn't Java and the JVM designed so that
each Java application ran as a thread on the same JVM?
Just the thoughts of someone who doesn't know better :) Any feedback
appreciated.
Thanks
Rob
Bret Hansen
application that would tell it what class to load and run in a new thread,
HOWEVER the main reason is that there would be many side effects having all
applications run in the same memory space.
I think the most obvious and infamous are the predecessors of NT and 95. You
end up with an operating system that can be crashed by one careless
application. It only took Bill and the boys 10 years to catch up.
Later,
Bret Hansen
Rob L'Estrange <rob.new...@StrangeSites.net> wrote in message
news:83s8qv$c3f$1...@bunyip.cc.uq.edu.au...
Hank Shiffman
> news:83s8qv$c3f$1...@bunyip.cc.uq.edu.au...
> > Hi All
> >
> > I've got a thought. It's probably stupid but the end result will be that
> > I'll be enlightened I'm sure hehe
> >
> > To me, starting a new instance of the JVM for each Java application seems
> a
> > bit wasteful of machine resources. Instead of running each new application
> > on it's own JVM using main(), why wasn't Java and the JVM designed so that
> > each Java application ran as a thread on the same JVM?
Bret Hansen wrote:
> I think the most obvious and infamous are the predecessors of NT and 95. You
> end up with an operating system that can be crashed by one careless
> application. It only took Bill and the boys 10 years to catch up.
Right. This is the model that Lisp Machines used: one image in which
everything ran. (For those of you who never experienced a Lisp Machine,
imagine a Java chip in a box the size of a refrigerator.) The problem
with that model is that any application could (and often did) modify the
behavior of classes that other applications relied upon.
When I did customer support at Data General many, many years ago we had
two standard answers to any customer question: FINR (fixed in next
revision) and RTFM. At Symbolics we had a third: try that in an image
that doesn't have an expert system shell installed. Because inevitably
when a customer called with peculiar behavior in their environment it
could be traced to something that one of the big expert system packages
modified.
It's *possible* to write code in a shared environment that doesn't break
other applications. I've just never seen it done.
Hank
--
Hank Shiffman http://www.disordered.org
Have Opinion, Will Travel ha...@disordered.org
Mountain View, California
Java Developer
>
> It's *possible* to write code in a shared environment that doesn't
> break other applications. I've just never seen it done.
>
Digital's VAX/VMS
Regards,
Java Developer
Stuart D. Gathman
> You could construe such a beast by simply sending a message to your
> application that would tell it what class to load and run in a new thread,
> HOWEVER the main reason is that there would be many side effects having all
> applications run in the same memory space.
>
> I think the most obvious and infamous are the predecessors of NT and 95. You
> end up with an operating system that can be crashed by one careless
> application. It only took Bill and the boys 10 years to catch up.
While applications sharing a VM might share the same memory space (this is up to
the JVM), this is irrelevant since Java code can't access memory. Applications
/ applets / EJBeans / whatever do *not* share the same object space. Classes
are immutable. Even class names spaces are separated by ClassLoader instances.
The holes in Java's security model are still limited to denial of service
attacks (tight infinite loops eating up lots of memory). These things can and
do happen in Unix and NT also (although many Unixen, e.g. AIX, can limit CPU and
memory use by process). The Java object model is every bit as secure as
hardware memory protection. Are you worried that processes in your Unix or NT
box are sharing the same physical memory? Think about it, thousands of pages
randomly selected from your running programs and the OS are scattered though
your RAM!
--
Stuart D. Gathman <stu...@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Microsoft is the QWERTY of Operating Systems" - SDG
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
(HINT: Find a translation of the "Dies Irae".)
Hank Shiffman
Java Developer wrote:
>
> Hank Shiffman wrote:
> >
> > It's *possible* to write code in a shared environment that doesn't
> > break other applications. I've just never seen it done.
> >
>
> Digital's VAX/VMS
Non sequitor. VMS is a protected mode OS, not the kind of open shared
memory environment under discussion here.
Peter van der Linden
>To me, starting a new instance of the JVM for each Java application seems a
>bit wasteful of machine resources. Instead of running each new application
>on it's own JVM using main(), why wasn't Java and the JVM designed so that
>each Java application ran as a thread on the same JVM?
Rob -- that's an insightful and clever idea.
The same idea occured to a talented and hard-working programmer
named Luke Gorrie, and he implemented it, and made the results available
to everyone, including source code!
See http://www.javagroup.org/echidna
--
The Java FAQ is at
http://www.afu.com
Might be worth bookmarking it, or looking thru it for other info.
Eelco Rustenburg
mainframe alike Vector for every instantiated object, holding on to the
version of the object, its class signature, the userspace it is run in
etcetera. If a new version of a claass is loaded, and there are still
versions used of the old class, then both are heldonto by the VM. This is
easily done by using the version in the classloader.
The problem of memory sharing is always solvable, I mean that's what
hardware engineers have been doing for the past 100 years or so. If you
create a memory pool of which a VM-application can retrieve pages on demand,
this could work. I am not saying it is the easiest way to go, but if they
want Java on server platforms running thousands of clients they will have to
address this.
Eelco Rustenburg
Rob L'Estrange <rob.new...@StrangeSites.net> wrote in message
news:83s8qv$c3f$1...@bunyip.cc.uq.edu.au...
> Hi All
>
> I've got a thought. It's probably stupid but the end result will be that
> I'll be enlightened I'm sure hehe
>
> To me, starting a new instance of the JVM for each Java application seems
a
> bit wasteful of machine resources. Instead of running each new application
> on it's own JVM using main(), why wasn't Java and the JVM designed so that
> each Java application ran as a thread on the same JVM?
>
Phil Earnhardt
wrote:
>> I think the most obvious and infamous are the predecessors of NT and 95. You
>> end up with an operating system that can be crashed by one careless
>> application. It only took Bill and the boys 10 years to catch up.
>
>Right. This is the model that Lisp Machines used: one image in which
>everything ran. (For those of you who never experienced a Lisp Machine,
>imagine a Java chip in a box the size of a refrigerator.) The problem
>with that model is that any application could (and often did) modify the
>behavior of classes that other applications relied upon.
Ah, Symbolics.
One question: why didn't those expert applications implement
extensions to the existing LISP code? Why did they replace it?
>Hank
--phil
Phil Earnhardt
wrote:
>It's *possible* to write code in a shared environment that doesn't break
>other applications. I've just never seen it done.
This brings up a somewhat tangential question: how good are UNIX
implementations at sharing pure code between JVMs?
From what I can tell about the class format, Java doesn't lend itself
at all well to sharing the pure parts of the classes. Hopefully, I'm
mistaken...
>Hank
--phil
Rob L'Estrange
Thanks VERY much for your replies. Read them all.
Firstly, yup, I know it can be done. After all, applets and servlets pretty
much work in the way I was describing. They're just threads on the same JVM,
but, at the same time, they are threads that act very much like their own
process, in that they are not really part of an overall application.
Secondly. But... What I really wanted to know was why wasn't Java designed
from the ground up so that each Java app 'process' ran on the same JVM
instance? Is there a good reason. For all I know, there's a great reason.
Because I'm not too experienced with Java I'm assuming that there was
probably a good reason for the Java architects to go the way they did, even
though I can't see it.
I saw in some of the original replies that people mentioned memory sharing
problems, but doesn't this mean that the applet and servlet schema would be
flawed by the same problem, if it is in fact a problem?
Thanks again for your replies.
Rob
Artur Biesiadowski
> This brings up a somewhat tangential question: how good are UNIX
> implementations at sharing pure code between JVMs?
AFAIK no genrally available JVM shares any of bytecode. I'm not counting
here various precompilers with dll made of core libs - I suppose
something could be found here, but as far as arbitrary classes are
concerned we are out of luck.
There was a project called chives, which wanted to share classes, JITted
code etc, but it gone dead. If you want to look at it check out
http://sunsite.auc.dk/chives/
Artur
Hank Shiffman
Phil Earnhardt wrote:
>
> On 23 Dec 1999 11:43:38 EST, Hank Shiffman <ha...@disordered.org>
> wrote:
>
> >> I think the most obvious and infamous are the predecessors of NT and 95. You
> >> end up with an operating system that can be crashed by one careless
> >> application. It only took Bill and the boys 10 years to catch up.
> >
> >Right. This is the model that Lisp Machines used: one image in which
> >everything ran. (For those of you who never experienced a Lisp Machine,
> >imagine a Java chip in a box the size of a refrigerator.) The problem
> >with that model is that any application could (and often did) modify the
> >behavior of classes that other applications relied upon.
>
> Ah, Symbolics.
>
> One question: why didn't those expert applications implement
> extensions to the existing LISP code? Why did they replace it?
This is a guess, based on fifteen year old memories. But I suspect it
was a combination of arrogance (my changes couldn't possibly hurt
anything else), laziness (the right solution - creating new subclasses
with the new behavior and then using them - was more work) and
sloppiness (in spite of the arrogance those changes *did* hurt other
applications).
Keep in mind that there were all kinds of clever ways to modify existing
classes without touching their code. The Flavors system (the object
system that preceded the Common Lisp Object System) had :BEFORE and
:AFTER methods, WRAPPERS, WHOPPERS and probably a bunch of others I've
forgotten. And with all those cool mechanisms just dying to be used,
well, people used them.
To misquote Winston Churchill, "Never in the field of human computing
was so much broken for so many by so few."
Hank
Roland Paterson-Jones
> Secondly. But... What I really wanted to know was why wasn't Java designed
> from the ground up so that each Java app 'process' ran on the same JVM
> instance? Is there a good reason. For all I know, there's a great reason.
> Because I'm not too experienced with Java I'm assuming that there was
> probably a good reason for the Java architects to go the way they did, even
> though I can't see it.
The problem is behaviour of static (class-local) members. Current
'multi-process'shells (AFAIK) suffer the problem of statics being shared
between all 'processes' using the
same (shared) class.
On the other hand, using the same JVM and reloading classe files for each new
java
'process' buys you very little. Your memory usage is going to be similar to
multi-JVM
since you're duplicating classes for each process. The JVM code itself is
typically in a
shared library, so that's already shared between JVM's.
There are technical difficulties with sharing byte-code between processes due
to java's
late binding. For example invoke instructions bind their target on first-use.
Two processes
with different CLASSPATH's might bind the target differently due to
ClassLoader's loading
different classes with the same name and package, for example.
Hope that helps
Roland
Harlan Messinger
>You could construe such a beast by simply sending a message to your
>application that would tell it what class to load and run in a new thread,
>HOWEVER the main reason is that there would be many side effects having all
>applications run in the same memory space.
>
>I think the most obvious and infamous are the predecessors of NT and 95. You
>end up with an operating system that can be crashed by one careless
>application. It only took Bill and the boys 10 years to catch up.
You mean NT launches a new instance of NT in which to run each
application? Of course it doesn't. Why can't one JVM operate separate
running Java apps in separate memory spaces, the way NT runs separate
Win32 apps?
--
Harlan Messinger
There are no Zs in my actual e-mail address.
Artur Biesiadowski
> You mean NT launches a new instance of NT in which to run each
> application? Of course it doesn't. Why can't one JVM operate separate
> running Java apps in separate memory spaces, the way NT runs separate
> Win32 apps?
Of course it can. Just run many instances of JVM - OS will take care of
sharing basic jvm dlls. Problem is with sharing java bytecodes/JITted
code - it is inside the heap of JVM, not the static part.
Sharing JITted code would not be even possible in most cases with smart
JITs - inlining decisions valid for given subset of classes might be not
correct for other subset or modified classes.
Artur
Harlan Messinger
>Harlan Messinger wrote:
>
>> You mean NT launches a new instance of NT in which to run each
>> application? Of course it doesn't. Why can't one JVM operate separate
>> running Java apps in separate memory spaces, the way NT runs separate
>> Win32 apps?
>
>Of course it can. Just run many instances of JVM - OS will take care of
>sharing basic jvm dlls. Problem is with sharing java bytecodes/JITted
>code - it is inside the heap of JVM, not the static part.
The reason a single JVM couldn't set up a separate heap for each
application is . . . ?
>
>Sharing JITted code would not be even possible in most cases with smart
>JITs - inlining decisions valid for given subset of classes might be not
>correct for other subset or modified classes.
The reason a single JVM couldn't load one class independently into a
separate memory space for each application, thereby avoiding these
problems, is . . . ?
Steve Chapel
>
> You could construe such a beast by simply sending a message to your
> application that would tell it what class to load and run in a new thread,
> HOWEVER the main reason is that there would be many side effects having all
> applications run in the same memory space.
>
> I think the most obvious and infamous are the predecessors of NT and 95. You
> end up with an operating system that can be crashed by one careless
> application. It only took Bill and the boys 10 years to catch up.
What do you mean *predecessors* of 95? Windows 95 and 98 definitely
have the same problems as Windows 3.1 in terms of resource protection.
Windows NT is a significant improvement, but is still not as stable as
most versions of Unix.
Artur Biesiadowski
> The reason a single JVM couldn't set up a separate heap for each
> application is . . . ?
Yes gain nothing by it - maybe only less entries in process table, but
no memory gain. On the other hand you might lose OS proces sheduling
facilities, reliability (JVMs are not perfect), ability to kill one
runaway application from outside etc.
> The reason a single JVM couldn't load one class independently into a
> separate memory space for each application, thereby avoiding these
> problems, is . . . ?
If you mean loading each of classes for each of applications in
different part of memory than you gain nothing (as in previous case). If
you mean loading only classes that differ separately, then it is
non-trivial thing to do. You have to know when class for given
application is different from same named class for other application. To
achieve this you need to create full dependence graph for freshly loaded
class and check if all classes it is dependent on are the same in both
applications. This include all superclasses, interfaces implemented by
given class and all other classes referenced from constants pool - there
is a lot of them. It can be done - but it is not nearly as easy as dll
or .text part sharing for native apps.
Even if you will do this, there is a problem of generated code. Static
fields has to be referenced from jitted code and they would have to go
through some indirection layer to allow different values for them in
different applications. You cannot do some optimizalizations in
generated code - for example normally you could forego runtime checks
for initialization of class if at time of compiling method it was
already initialized. But if this code is to be shared, you have to
insert this initialization at every possible place, as you don't know if
this code won't be used by another apps in different state with given
class not initialized yet. Also aggresive inlining as done by hotspot
could be tricky here - chain of dependecies could grow expotentially. If
we are at subject of hotspot, runtime detection of hotspots and context
of calls will also possibly be screwed - various applications could
behave different, so generic one code fits all has to be used.
As you see, it can be done, but it is non-trivial and there is not sure
gain from it. It is a lot better to run apps by some kind of software
dispatcher - as long as they do not depend on static variables in way
not allowing to run them in same vm you get very good footprint.
Artur
Artur Biesiadowski
One more thing - you might want to check out
http://sunsite.auc.dk/chives/doc/code-maintenance.html
there are some words about things that needed to be taken care of to
allow class sharing.
Artur
Harlan Messinger
>Harlan Messinger wrote:
>
>> The reason a single JVM couldn't set up a separate heap for each
>> application is . . . ?
>
>Yes gain nothing by it - maybe only less entries in process table, but
>no memory gain. On the other hand you might lose OS proces sheduling
>facilities, reliability (JVMs are not perfect), ability to kill one
>runaway application from outside etc.
>
You have me confused. You mentioned a couple of problems involved in
using a single JVM, which to me sounded like they were caused by (a)
having everything on one heap and (b) sharing loaded classes between
applications. I asked why (a) you couldn't just *not* have everything
on one heap and (b) you couldn't just *not* share loaded classes
between applications, and you replied that that wouldn't really make
anything better. I'm sure you don't mean to say that fixing the
problems won't fix the problems, so I must be misunderstanding you.
>> The reason a single JVM couldn't load one class independently into a
>> separate memory space for each application, thereby avoiding these
>> problems, is . . . ?
>
>If you mean loading each of classes for each of applications in
>different part of memory than you gain nothing (as in previous case).
Vis Suddha
memory money), to initiate? What would you save by executing every app from the
same JVM? What would it cost? Everythings a trade off between time and money.
Vis
Rob L'Estrange wrote:
> Hi All
>
> Thanks VERY much for your replies. Read them all.
>
> Firstly, yup, I know it can be done. After all, applets and servlets pretty
> much work in the way I was describing. They're just threads on the same JVM,
> but, at the same time, they are threads that act very much like their own
> process, in that they are not really part of an overall application.
>
> Secondly. But... What I really wanted to know was why wasn't Java designed
> from the ground up so that each Java app 'process' ran on the same JVM
> instance? Is there a good reason. For all I know, there's a great reason.
> Because I'm not too experienced with Java I'm assuming that there was
> probably a good reason for the Java architects to go the way they did, even
> though I can't see it.
>
Artur Biesiadowski
> You have me confused. You mentioned a couple of problems involved in
> using a single JVM, which to me sounded like they were caused by (a)
> having everything on one heap and (b) sharing loaded classes between
> applications. I asked why (a) you couldn't just *not* have everything
> on one heap and (b) you couldn't just *not* share loaded classes
> between applications, and you replied that that wouldn't really make
> anything better. I'm sure you don't mean to say that fixing the
> problems won't fix the problems, so I must be misunderstanding you.
What is the reason for running many applications in one VM ? Only one
which comes up to my mind is trying to reduce memory footprint. I was
trying to show that it is impossible to use less memory by loading apps
in same VM without using advanced techniques. But if you see other
benefits except memory/generated code sharing please tell me - I can't
see any.
Artur
Harlan Messinger
>Harlan Messinger wrote:
>
>> You have me confused. You mentioned a couple of problems involved in
>> using a single JVM, which to me sounded like they were caused by (a)
>> having everything on one heap and (b) sharing loaded classes between
>> applications. I asked why (a) you couldn't just *not* have everything
>> on one heap and (b) you couldn't just *not* share loaded classes
>> between applications, and you replied that that wouldn't really make
>> anything better. I'm sure you don't mean to say that fixing the
>> problems won't fix the problems, so I must be misunderstanding you.
>
>What is the reason for running many applications in one VM ? Only one
>which comes up to my mind is trying to reduce memory footprint.
I've rarely encountered anyone so blase about massive memory
consumption.
> I was
>trying to show that it is impossible to use less memory by loading apps
>in same VM without using advanced techniques.
Why? Is the VM itself minuscule? I assumed it took up some memory and
resources, hence, fewer VMs = less memory and fewer resources, without
even getting to any question of saving memory on the applications that
run *under* the VM(s).
>But if you see other
>benefits except memory/generated code sharing please tell me - I can't
>see any.
Tor Iver Wilhelmsen
> To me, starting a new instance of the JVM for each Java application seems a
> bit wasteful of machine resources. Instead of running each new application
> on it's own JVM using main(), why wasn't Java and the JVM designed so that
> each Java application ran as a thread on the same JVM?
Write an application which only reads names of classes and arguments,
then fires off a Thread which runs the class' main() with the
arguments nicely chopped up.
--
Tor Iver Wilhelmsen <to...@multinett.no>
The pretty things are going to hell
They wore it out, but they wore it well. - David Bowie
Blair Wyman
>
> The holes in Java's security model are still limited to denial of service
> attacks (tight infinite loops eating up lots of memory).
...just keep your users out of native methods -- nearly all the stops are
opened up otherwise, eh?
--
___ _ Blair Wyman (bla...@us.ibm.com) / Ph: 507.253.2891
( /_) / _ ' _ Advisory Programmer, Dept GZAA / TieLine: 553.2891
_/__)_/_<_/_/_/_' SLIC Program Model, IBM Rochester/ VM: RCHLAND(BLAIR)
Opinions expressed are not IBM's
David Hopwood
"Stuart D. Gathman" wrote:
[...]
> The holes in Java's security model are still limited to denial of service
> attacks (tight infinite loops eating up lots of memory). These things can
> and do happen in Unix and NT also (although many Unixen, e.g. AIX, can
> limit CPU and memory use by process). The Java object model is every bit
> as secure as hardware memory protection.
No it isn't, from a practical point of view: current Java implementations
have had (and will have in future) many more security bugs than have
implementations of hardware memory protection. You could argue that this
isn't a flaw of the model, but that would be wrong; the reason why
implementations of the Java model have more bugs is that it's much more
complex, and too little attention has been paid to formalising it.
Also note that to maintain strict independence of applications to the same
degree as provided by memory protection, you would need to load most of the
API (including large libraries such as Swing, etc.) multiple times in
different ClassLoaders. In that case, you lose much of the performance
advantage of sharing a single VM. Maybe you could still share code (and
the overhead of JIT compilation) between identical classes in different
ClassLoaders, but it's non-trivial to do that, since even identical classes
may need to be linked differently.
- --
David Hopwood <hop...@zetnet.co.uk>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBOGrVEzkCAxeYt5gVAQGlLQgAlw+t0Uh0jMWbZYfebGvu8yy5SCfHtyWf
zrhOUmm/INgxteFIi/gHDQRv01RiSoWcG2B1mAV2OcnM1C6kwBAFTvZojT8KCMvr
s9Klr3fGh+oOb1voBejpn7yGg6XakJlkP958eAmPEA4heL8usIspHK/4aWEDuZwv
GJvhW2+VOK1wor42n72UvGBrWGuL92OVYZURdVcbs8aJOxWyE6r8CGtgY8zzElRs
qABZKWB27ije3QnWSQ1dFx4FBS3LbcTTVAuNmeCYnYXYoXUToeI1J8fvhIHfu3Zy
0297EqSwONRZDo6ATP3qtlMb8HMZZ/mIocvsDxzx9qhEnjcy9RffoQ==
=Iny2
-----END PGP SIGNATURE-----
Stuart D. Gathman
> > The holes in Java's security model are still limited to denial of service
> > attacks (tight infinite loops eating up lots of memory). These things can
> > and do happen in Unix and NT also (although many Unixen, e.g. AIX, can
> > limit CPU and memory use by process). The Java object model is every bit
> > as secure as hardware memory protection.
>
> No it isn't, from a practical point of view: current Java implementations
> have had (and will have in future) many more security bugs than have
> implementations of hardware memory protection.
I agree.
> You could argue that this
> isn't a flaw of the model, but that would be wrong; the reason why
> implementations of the Java model have more bugs is that it's much more
> complex, and too little attention has been paid to formalising it.
But I still argue that the model is good :-)
> Also note that to maintain strict independence of applications to the same
> degree as provided by memory protection, you would need to load most of the
> API (including large libraries such as Swing, etc.) multiple times in
> different ClassLoaders. In that case, you lose much of the performance
> advantage of sharing a single VM. Maybe you could still share code (and
> the overhead of JIT compilation) between identical classes in different
> ClassLoaders, but it's non-trivial to do that, since even identical classes
> may need to be linked differently.
If I want strict independence of applications, you are correct. However, I
simply want to share large libraries such as Swing between multiple applications
for the same user - or users with the same security considerations. The Java
object model prevents application bugs from corrupting memory. By ensuring that
each user has their own event thread (which is doable for AWT anyway - I have
done it, don't know about swing), most bugs in practice affect only the user
encountering it. One exception to this is an infinite recursion bug. Many JVMs
crash the whole VM rather than throwing StackOverflow for the offending thread.
However, I consider this a JVM bug rather than a flaw in the model.
Another good reason to use multiple JVMs is that Garbage Collection is more
efficient with smaller object spaces. You can *increase* performance with large
numbers of objects by splitting them into multiple JVMs. I am not arguing that
only one JVM should ever be used on a machine. I want the flexibility to use
multiple JVMs *and* multiple applications on each JVM.
Reasons to use a separate JVM include: stronger security firewalls, reduced GC
overhead, JVMs protected from bugs in other JVMs.
Reasons to combine applications in a JVM include: reduced startup cost for
additional applications, shared resources including stable libraries, reduced
memory consumption.
A significant flaw in the current model is the lack of a safe way to terminate a
Thread externally. Thread.stop() is deprecated for good reason - but there is no
replacement that can be used to cancel an evil or buggy Thread. The
Thread.interrupt() suggestion only works for correct and morally upright code.
> "Attempts to control the use of encryption technology are wrong in principle,
> unworkable in practice, and damaging to the long-term economic value of the
> information networks." -- UK Labour Party pre-election policy document
So did the Labour Party change their tune after the elections?
Artur Biesiadowski
> Why? Is the VM itself minuscule? I assumed it took up some memory and
> resources, hence, fewer VMs = less memory and fewer resources, without
> even getting to any question of saving memory on the applications that
> run *under* the VM(s).
Operating system does sharing of vm for you - same for all executable
files and dynamic libraries. Code for VM together with native libs takes
about 2-5MB at runtime - and this is per entire system, not matter how
many vms are launched. This has nothing to do with java - it is true for
every application.
Of course there is a cost of additional entry in kernel process table -
but it is neglible compared with runtime size of java application.
Additionally if you would use one vm for every java app on system you
would hit all OS limitations - for example maximum number of file
handles would be a limit for all java apps in sum, not for every one
separately.
Artur
Wayne Price
The first problem is security and robustness. If you share classes like you
share DLLs, you have the same 'DLL hell' problem, with every application
installing and loading its version of the class (same as DLL). This is a very
difficult troubleshooting problem because it is intermittent and depends on the
sequence of user actions - and may not be easily repeatable. The security
issue comes in when my class replaces your class and has it do mischief like
record your password when you enter it. This is why the String class was made
final - it can't be subclassed to allow buffer overflows - a favorite hacker
technique. To really preserve the JVM integrity for multiple user/applications,
you would need to load and track each class by application and user space. The
only memory space you might save is with classes that have identical bytecodes.
Doing a byte compare of classes with the same name would really slow loading -
and garbage collection, too, since you must check all the user and application
spaces before removing an object from memory. I believe that in most cases, all
the tracking and security checks would use more memory and more CPU time than
separate JVMs. The JIT issues just add to the mess.
Separate JVMs are a fair simpler and more elegant solution. Providing threads
allowed Java to have all the multi-processing advantages while avoiding the
problems of sharing a JVM between applications and users.
Memory and CPU time are relatively cheap and getting cheaper. Most users do not
use all the power they have, and a lot more of those resources are wasted by
sloppy operating systems....
Wayne Price
Rob L'Estrange wrote:
> Hi All
>
> Thanks VERY much for your replies. Read them all.
>
> Firstly, yup, I know it can be done. After all, applets and servlets pretty
> much work in the way I was describing. They're just threads on the same JVM,
> but, at the same time, they are threads that act very much like their own
> process, in that they are not really part of an overall application.
>
> Secondly. But... What I really wanted to know was why wasn't Java designed
> from the ground up so that each Java app 'process' ran on the same JVM
> instance? Is there a good reason. For all I know, there's a great reason.
> Because I'm not too experienced with Java I'm assuming that there was
> probably a good reason for the Java architects to go the way they did, even
> though I can't see it.
>
> I saw in some of the original replies that people mentioned memory sharing
> problems, but doesn't this mean that the applet and servlet schema would be
> flawed by the same problem, if it is in fact a problem?
>
> Thanks again for your replies.
> Rob
>
> Rob L'Estrange <rob.new...@StrangeSites.net> wrote in message
> news:83s8qv$c3f$1...@bunyip.cc.uq.edu.au...
> > Hi All
> >
> > I've got a thought. It's probably stupid but the end result will be that
> > I'll be enlightened I'm sure hehe
> >
> > To me, starting a new instance of the JVM for each Java application seems
> a
> > bit wasteful of machine resources. Instead of running each new application
> > on it's own JVM using main(), why wasn't Java and the JVM designed so that
> > each Java application ran as a thread on the same JVM?
> >
Rob L'Estrange
Great reply. Very informative.
Got a question. This is to get your view and learn more about this, not to
argue with you... The servlet schema suggested by Sun uses one JVM to
service all servlet requests. If you regard each servlet as its own process,
what we have is a bunch (perhaps scores) of different (and quite possibly
unrelated and authored by different organisations) individual servlets and
we also have a bunch (perhaps scores) instances of the same servlet running
simultaneously on the one JVM. Is this servlet schema of Suns flawed by the
same problems you raised? If so, why is Sun suggesting that this is the way
to do things?
Like I said, not trying to shoot your reply down, but these are the
questions that come to mind when I read your (and other peoples') replies.
Thanks
Rob
Wayne Price <wlp...@earthlink.net> wrote in message
news:386FA956...@earthlink.net...