Mars Rover Controlled By Java

[Rod Davison]

Re: Mars Rover Controlled By Java

<reply satirical_mode= "on">
Actually, the use of Java on the Mars rover is quite brilliant because of
Java's write once run anywhere model.

This means that NASA can re-license the code to run forklifts, golf
carts,wheelchai rs, or any conveyance that could have its own on board
JVM.

Just think of how all that extra licensing revenue will enable us to meet
the President's goal of landing the Democratic candidate for President on
the moon before the election and returning him within four years. More or
less.

Unless the rover was developed under the GPL?
</reply>

Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.


--
............... ............... ............... .....
99 percent of lawyers give the rest a bad name.

Rod Davison - Critical Knowledge Systems Inc.

[Rod Davison]

Re: Mars Rover Controlled By Java

<reply satirical_mode= "on">
Actually, the use of Java on the Mars rover is quite brilliant because of
Java's write once run anywhere model.

This means that NASA can re-license the code to run forklifts, golf
carts,wheelchai rs, or any conveyance that could have its own on board
JVM.

Just think of how all that extra licensing revenue will enable us to meet
the President's goal of landing the Democratic candidate for President on
the moon before the election and returning him within four years. More or
less.

Unless the rover was developed under the GPL?
</reply>

Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.


--
............... ............... ............... .....
99 percent of lawyers give the rest a bad name.

Rod Davison - Critical Knowledge Systems Inc.

[David Gay]

Re: Mars Rover Controlled By Java


hhc314@yahoo.co m (Harry Conover) writes:[color=blue]
> First of all, obviously Java is not an operating system. It's an
> application programming language or tool targeted to the production of
> Internet (particularly browser applications). You also cannot
> implement a true operating system using Java as your programming
> language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
> of online memory and chuckle as you try!)[/color]

A logical conclusion from this statement is that you can't write a "true"
(wonder what that means?) operating system in Lisp. Oops. Symbolics.

Hint: when you're doing that, you add a few well chosen extensions which
you use in the appropriate places.

--
David Gay
dgay@acm.org

[David Gay]

Re: Mars Rover Controlled By Java


hhc314@yahoo.co m (Harry Conover) writes:[color=blue]
> First of all, obviously Java is not an operating system. It's an
> application programming language or tool targeted to the production of
> Internet (particularly browser applications). You also cannot
> implement a true operating system using Java as your programming
> language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
> of online memory and chuckle as you try!)[/color]

A logical conclusion from this statement is that you can't write a "true"
(wonder what that means?) operating system in Lisp. Oops. Symbolics.

Hint: when you're doing that, you add a few well chosen extensions which
you use in the appropriate places.

--
David Gay
dgay@acm.org

[Harry Conover]

Re: Mars Rover Controlled By Java

Jan C. Vorbrüggen <jvorbrueggen@m ediasec.de> wrote in message news:<400F7DA7. 8891E58C@medias ec.de>...

Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding.
[color=blue][color=green]
> > d) There is no reason to believe a real time system cannot be virtual
> > machine based. It is technicaly feasible and all the benefits of seperating
> > code from hardware/OS are just as relevant on embedded systems as they are
> > on desktops. Just look at cell phones.[/color][/color]

I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.

The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.

This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.

With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.

For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.

The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.

Harry C.

[Harry Conover]

Re: Mars Rover Controlled By Java

Jan C. Vorbrüggen <jvorbrueggen@m ediasec.de> wrote in message news:<400F7DA7. 8891E58C@medias ec.de>...

Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding.
[color=blue][color=green]
> > d) There is no reason to believe a real time system cannot be virtual
> > machine based. It is technicaly feasible and all the benefits of seperating
> > code from hardware/OS are just as relevant on embedded systems as they are
> > on desktops. Just look at cell phones.[/color][/color]

I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.

The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.

This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.

With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.

For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.

The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.

Harry C.

[Michael N. Christoff]

Re: Mars Rover Controlled By Java


"Harry Conover" <hhc314@yahoo.c om> wrote in message
news:7ce4e226.0 401220947.78824 fe7@posting.goo gle.com...[color=blue]
> Jan C. Vorbrüggen <jvorbrueggen@m ediasec.de> wrote in message[/color]
news:<400F7DA7. 8891E58C@medias ec.de>...[color=blue]
>
> Sorry Jan, I couldn't locate the original source of the text you
> quoted and to which I am responding.
>[color=green][color=darkred]
> > > d) There is no reason to believe a real time system cannot be virtual
> > > machine based. It is technicaly feasible and all the benefits of[/color][/color][/color]
seperating[color=blue][color=green][color=darkred]
> > > code from hardware/OS are just as relevant on embedded systems as they[/color][/color][/color]
are[color=blue][color=green][color=darkred]
> > > on desktops. Just look at cell phones.[/color][/color]
>
> I believe that accuracy of this statement depends entirely on the
> degree of reaction latency that can be tollerated in the real time
> system. Even at today's fantastic execution rates, critical real-time
> must occur within only a few machine execution cycles.
>
> The execution latency penalty imposed by my concept of a virtual
> machine will, at least in my mind, knock it from consideration for
> anything approaching that which is normally required for critical
> real-time performance. Here often anything greater than a few
> processor instruction cycle latency leads to a non-recoverable error
> situation.
>
> This is precisely why interrupt level service routines, fast device
> drivers, and similar time-critical operations are generally
> implemented in assembly or other low-level code optimized to minimize
> the number and duration of required machine instruction executions.
>
> With today's focus on high-level programming languages and software
> implemented virtual machines, many people lose sight of the very
> fundamental differences that exist between software that simply
> executes quickly and real-time system software where interrupt level
> response processing must be assured to be alway less than some
> critical latency limit. Couple this with the fact that in most
> real-time control and operating systems, these latency requirements
> are often only a few microseconds and the need for very tightly coded
> software becomes obvious.
>
> For an example of real-time OS design, compare the kernel
> implementation in something like Wind River's VxWorks RTOS vs. that of
> a non-real-time OS such as early Unix or Microsoft Windows.
> Particularly note the fact the the task scheduler in a real-time OS of
> any reasonable complexity will be both dynamic priority weighted and
> perform pre-emptive scheduling because you can't have a slow process
> (like I/O) hogging the system and locking out tasks that need to
> execute in milliseconds or microseconds.
>
> The above and other considerations in real-time are what cause me to
> believe that the utility of a virtual machine so very unrealistic for
> RTOS use.
>[/color]

If you're interested into getting to the bottom of this, I'd suggest you
peruse the real time specification for java. That and other related
information can be found here.

http://www.rtj.org/

I'm sure it could address your questions better than I ever could. I'd be
interested to hear your comments.



l8r, Mike N. Christoff

[Michael N. Christoff]

Re: Mars Rover Controlled By Java


"Harry Conover" <hhc314@yahoo.c om> wrote in message
news:7ce4e226.0 401220947.78824 fe7@posting.goo gle.com...[color=blue]
> Jan C. Vorbrüggen <jvorbrueggen@m ediasec.de> wrote in message[/color]
news:<400F7DA7. 8891E58C@medias ec.de>...[color=blue]
>
> Sorry Jan, I couldn't locate the original source of the text you
> quoted and to which I am responding.
>[color=green][color=darkred]
> > > d) There is no reason to believe a real time system cannot be virtual
> > > machine based. It is technicaly feasible and all the benefits of[/color][/color][/color]
seperating[color=blue][color=green][color=darkred]
> > > code from hardware/OS are just as relevant on embedded systems as they[/color][/color][/color]
are[color=blue][color=green][color=darkred]
> > > on desktops. Just look at cell phones.[/color][/color]
>
> I believe that accuracy of this statement depends entirely on the
> degree of reaction latency that can be tollerated in the real time
> system. Even at today's fantastic execution rates, critical real-time
> must occur within only a few machine execution cycles.
>
> The execution latency penalty imposed by my concept of a virtual
> machine will, at least in my mind, knock it from consideration for
> anything approaching that which is normally required for critical
> real-time performance. Here often anything greater than a few
> processor instruction cycle latency leads to a non-recoverable error
> situation.
>
> This is precisely why interrupt level service routines, fast device
> drivers, and similar time-critical operations are generally
> implemented in assembly or other low-level code optimized to minimize
> the number and duration of required machine instruction executions.
>
> With today's focus on high-level programming languages and software
> implemented virtual machines, many people lose sight of the very
> fundamental differences that exist between software that simply
> executes quickly and real-time system software where interrupt level
> response processing must be assured to be alway less than some
> critical latency limit. Couple this with the fact that in most
> real-time control and operating systems, these latency requirements
> are often only a few microseconds and the need for very tightly coded
> software becomes obvious.
>
> For an example of real-time OS design, compare the kernel
> implementation in something like Wind River's VxWorks RTOS vs. that of
> a non-real-time OS such as early Unix or Microsoft Windows.
> Particularly note the fact the the task scheduler in a real-time OS of
> any reasonable complexity will be both dynamic priority weighted and
> perform pre-emptive scheduling because you can't have a slow process
> (like I/O) hogging the system and locking out tasks that need to
> execute in milliseconds or microseconds.
>
> The above and other considerations in real-time are what cause me to
> believe that the utility of a virtual machine so very unrealistic for
> RTOS use.
>[/color]

If you're interested into getting to the bottom of this, I'd suggest you
peruse the real time specification for java. That and other related
information can be found here.

http://www.rtj.org/

I'm sure it could address your questions better than I ever could. I'd be
interested to hear your comments.



l8r, Mike N. Christoff

[Michael N. Christoff]

Mars Rover Not Responding

"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."

"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."

http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm

l8r, Mike N. Christoff

[Michael N. Christoff]

Mars Rover Not Responding

"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."

"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."

http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm

l8r, Mike N. Christoff

[Joe \Nuke Me Xemu\ Foster]

Re: Mars Rover Not Responding

"Michael N. Christoff" <mchristoff@sym patico.caREMOVE THIS> wrote in message <news:LJXPb.173 71$cQ6.662625@n ews20.bellgloba l.com>...
[color=blue]
> "This is a serious problem. This is an extremely serious anomaly," said Pete
> Theisinger Spirit project manager.
> "There is no single fault that explains all the observables."
>
> "...but Spirit was only transmitting "pseudo-noise", a random series of
> zeroes and ones in binary code and not anything the scientists could
> decipher."
>
>
> http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm[/color]

Are they sure it's not just Sun's JVM taking a break to do a GC?

--
Joe Foster <mailto:jlfoste r%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

Re: Mars Rover Not Responding

"Michael N. Christoff" <mchristoff@sym patico.caREMOVE THIS> wrote in message <news:LJXPb.173 71$cQ6.662625@n ews20.bellgloba l.com>...
[color=blue]
> "This is a serious problem. This is an extremely serious anomaly," said Pete
> Theisinger Spirit project manager.
> "There is no single fault that explains all the observables."
>
> "...but Spirit was only transmitting "pseudo-noise", a random series of
> zeroes and ones in binary code and not anything the scientists could
> decipher."
>
>
> http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm[/color]

Are they sure it's not just Sun's JVM taking a break to do a GC?

--
Joe Foster <mailto:jlfoste r%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Michael N. Christoff]

Re: Mars Rover Not Responding


"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
news:1074811925 .53656@news-1.nethere.net.. .[color=blue]
> "Michael N. Christoff" <mchristoff@sym patico.caREMOVE THIS> wrote in[/color]
message <news:LJXPb.173 71$cQ6.662625@n ews20.bellgloba l.com>...[color=blue]
>[color=green]
> > "This is a serious problem. This is an extremely serious anomaly," said[/color][/color]
Pete[color=blue][color=green]
> > Theisinger Spirit project manager.
> > "There is no single fault that explains all the observables."
> >
> > "...but Spirit was only transmitting "pseudo-noise", a random series of
> > zeroes and ones in binary code and not anything the scientists could
> > decipher."
> >
> >
> > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm[/color]
>
> Are they sure it's not just Sun's JVM taking a break to do a GC?
>[/color]

If they were using standard Java (ie: not a real-time version) that would
not be beyond the realm of possibility. Hopefully its something just as
recoverable. (Note: I'm pretty certain Java is not actually running on
the rover itself).



l8r, Mike N. Christoff

[Michael N. Christoff]

Re: Mars Rover Not Responding


"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
news:1074811925 .53656@news-1.nethere.net.. .[color=blue]
> "Michael N. Christoff" <mchristoff@sym patico.caREMOVE THIS> wrote in[/color]
message <news:LJXPb.173 71$cQ6.662625@n ews20.bellgloba l.com>...[color=blue]
>[color=green]
> > "This is a serious problem. This is an extremely serious anomaly," said[/color][/color]
Pete[color=blue][color=green]
> > Theisinger Spirit project manager.
> > "There is no single fault that explains all the observables."
> >
> > "...but Spirit was only transmitting "pseudo-noise", a random series of
> > zeroes and ones in binary code and not anything the scientists could
> > decipher."
> >
> >
> > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm[/color]
>
> Are they sure it's not just Sun's JVM taking a break to do a GC?
>[/color]

If they were using standard Java (ie: not a real-time version) that would
not be beyond the realm of possibility. Hopefully its something just as
recoverable. (Note: I'm pretty certain Java is not actually running on
the rover itself).



l8r, Mike N. Christoff

[Andrew Thompson]

Re: Mars Rover Not Responding

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
news:1074811925 .53656@news-1.nethere.net.. .
| "Michael N. Christoff" <mchristoff@sym patico.caREMOVE THIS> wrote in
message <news:LJXPb.173 71$cQ6.662625@n ews20.bellgloba l.com>...
|
| > "This is a serious problem. This is an extremely serious anomaly," said
Pete
| > Theisinger Spirit project manager.
| > "There is no single fault that explains all the observables."
| >
| > "...but Spirit was only transmitting "pseudo-noise", a random series of
| > zeroes and ones in binary code and not anything the scientists could
| > decipher."
| >
| >
| > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
|
| Are they sure it's not just Sun's JVM taking a break to do a GC?

Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).

In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site