Does Java has compiler options?

S

Sanny

In C language we can put -o etc to compile a program.

I want to compile java such that it do not do error checking at run
time to increase the efficiency of the code.

As when a/b is done it see diviision by 0 or not.

When assigning array1[55]="dfgdfg"; It checks whether array1[] size is
ok.

int ii="sdfsdf"; Here it checks for Casting etc.

I want that when the program is running it do not waste time in
verifying various things. As my Program is already tested and there is
no error left.

Can I ask the compiler to compile in such a way that it do not look
for errors when runniung and it helps speed up of my Program.

And if it is possible how much fast the program will become when it do
not check for errors at runtime.

I know It is possible in C++ Language but what about Java.

Bye
Sanny
 
S

Stefan Ram

Sanny said:
Does Java has compiler options?
http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html

I want to compile java such that it do not do error checking at run
time to increase the efficiency of the code.
http://java.sun.com/jsp_utils/PrintPage.jsp?url=http://java.sun.com/docs/hotspot/PerformanceFAQ.html
http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.html

When assigning array1[55]="dfgdfg"; It checks whether array1[]
size is ok.

Hotspot removes such checks, whereever possible.
I want that when the program is running it do not waste time in
verifying various things. As my Program is already tested and
there is no error left.

Of course.
 
S

Stefan Ram

Supersedes: <[email protected]>

Sanny said:
Does Java has compiler options?
http://java.sun.com/javase/6/docs/technotes/tools/windows/javac.html

I want to compile java such that it do not do error checking at run
time to increase the efficiency of the code.
http://java.sun.com/jsp_utils/PrintPage.jsp?url=http://java.sun.com/docs/hotspot/PerformanceFAQ.html
http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.html
http://blogs.sun.com/nike/entry/hotspot_internals_q_a

When assigning array1[55]="dfgdfg"; It checks whether array1[]
size is ok.

Hotspot removes such checks, whereever possible.
I want that when the program is running it do not waste time in
verifying various things. As my Program is already tested and
there is no error left.

Of course.

Supersedes: <[email protected]>
 
L

Lew

Stefan said:
Have a look at gcj. I believe, one might be able to
disable more checks there:

http://gcc.gnu.org/java/

Then avoid using it.

Certain checks are defined by the Java Language itself, e.g., array bounds
checking and division by zero. You can't get rid of them without it being not
Java.

As to "how fast" a program will get when you prematurely optimize it without
regard for whether your so-called "optimizations" will help at all, or whether
the code in question is a chokepoint, the answer is, "that depends, but quite
possibly slower than without the 'optimizations'."

Part of the language. Must happen.
When assigning array1[55]="dfgdfg"; It checks whether array1[] size is
ok.

Part of the language. Must happen.
int ii="sdfsdf"; Here it checks for Casting [sic] etc.

This expression will be rejected at compile time. There is no run-time cost.
I want that when the program is running it do [sic] not waste time in
verifying various things. As my Program [sic] is already tested and there is
no error left.

Presumably you have proven your algorithms with assert statements and other
techniques. Even so, since the types of checks you seem to wish to avoid are
all dependent on run-time values, there is no magic wand that will protect you
against bad data except run-time checks of the data.

As Stefan Ram pointed out, the runtime optimizer will do what it can to
mitigate the cost of the checks.

Have you any evidence that these checks that you are so anxious to avoid
actually affect your runtime performance?
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

Sanny said:
In C language we can put -o etc to compile a program.

I want to compile java such that it do not do error checking at run
time to increase the efficiency of the code.

As when a/b is done it see diviision by 0 or not.

When assigning array1[55]="dfgdfg"; It checks whether array1[] size is
ok.

int ii="sdfsdf"; Here it checks for Casting etc.

I want that when the program is running it do not waste time in
verifying various things. As my Program is already tested and there is
no error left.

Can I ask the compiler to compile in such a way that it do not look
for errors when runniung and it helps speed up of my Program.

And if it is possible how much fast the program will become when it do
not check for errors at runtime.

I know It is possible in C++ Language but what about Java.

You can not do that in Java.

All these checks are core Java functionality.

If you want to code in C++ then use C++.

And even though there are formal methods to prove code correct,
then real world apps always has the chance of some circumstances
triggering an exception.

Arne
 
J

Joshua Cranmer

Arne said:
And even though there are formal methods to prove code correct,
then real world apps always has the chance of some circumstances
triggering an exception.

There are formal methods, true, but I believe the general case of
proving code correct is equivalent to the Halting problem.
 
E

Eric Sosman

Sanny wrote On 10/05/07 14:00,:
In C language we can put -o etc to compile a program.

I want to compile java such that it do not do error checking at run
time to increase the efficiency of the code.

As when a/b is done it see diviision by 0 or not.

On many (perhaps most) implementations, this check
is performed by the CPU hardware/firmware as a by-product
of the division opcode. You can turn off the check by
replacing the CPU with a new model of your own design.
When assigning array1[55]="dfgdfg"; It checks whether array1[] size is
ok.

The JVM guarantees (or tries to guarantee) a safe
operating environment for all the code it runs, including
itself. In order to make the guarantee, it must defend
against this sort of error. Remember, if *you* can turn
off bounds checking, so can a less responsible programmer
whose code is loaded before yours ...
int ii="sdfsdf"; Here it checks for Casting etc.

The example won't compile, of course. But you'll
still get run-time checking to catch errors like

Object o = "42.0";
Double d = (Double) o;

Again, the JVM *must* make such checks if it is to be
able to extend its safety guarantees to your code. If it
didn't, that other guy's code could ruin yours.
I want that when the program is running it do not waste time in
verifying various things. As my Program is already tested and there is
no error left.

Donald Knuth offers monetary rewards to people who find
errors in his code or in his books. Are you willing to do
the same? You can offer an extravagantly large sum, since
your code is bug-free and you will never need to pay.
Can I ask the compiler to compile in such a way that it do not look
for errors when runniung and it helps speed up of my Program.

No. Some checks (array bounds, for example) are made
internally by the JVM and not by compiler-generated code.
Some (like casts) are initiated by compiler-generated code
and you could omit them by generating your own bytecodes.
You'd have trouble getting the JVM to load the resulting
classes, though: the bytecode verifier wouldn't like them.
And if it is possible how much fast the program will become when it do
not check for errors at runtime.

How fast does the wind blow in a vacuum?
I know It is possible in C++ Language but what about Java.

A lot of things are possible in C++ but not in Java.
You can read about some of them in the CERT advisories.
 
C

Christian

Joshua said:
There are formal methods, true, but I believe the general case of
proving code correct is equivalent to the Halting problem.
Then I will give you the thesis that halting can be proven for any
"nice" program.

And any program you program will be with a high probability of the set
of "nice" programs.
---------------

The problem I see with prooving a program to be correct is that it is
too complicated.. jml might be easy for some people that dream in hoare
triples though I think it still costs too much time compared to setting
up extensive junit tests.
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

Christian said:
The problem I see with prooving a program to be correct is that it is
too complicated.. jml might be easy for some people that dream in hoare
triples though I think it still costs too much time compared to setting
up extensive junit tests.

Which is why we always expect n bugs per KLOC.

Arne
 
K

Karl Uppiano

Stefan Ram said:
Sanny said:
Does Java has compiler options?
[snip]
I want that when the program is running it do not waste time in
verifying various things. As my Program is already tested and
there is no error left.

Of course.

You seem incredulous. It is possible. I once almost *completely* debugged
"Hello World".
 
L

Laurent D.A.M. MENTEN

And only NASA can afford to get n < 1.

And even getting n<1 did not keep them to land a rocket into the sea a
few years ago by mixing nautical and statute miles in their computations.
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

Laurent said:
And even getting n<1 did not keep them to land a rocket into the sea a
few years ago by mixing nautical and statute miles in their computations.

It only require one bug in the entire app ...

Arne
 
L

Lew

Arne said:
It only require one bug in the entire app ...

More importantly, in only required one gaping flaw in their development process.

The calculations in nautical miles (or km. or whatever it was) were completely
accurate. The module in question didn't have any bugs.

Likewise the calculations in statute miles also were completely accurate. No
bugs in that module either.

Put the two together and SPLOOSH.

Had the development teams had proper communication, and more importantly,
oversight, then things might've gone better.
 
L

Laurent D.A.M. MENTEN

That proves one simple thing... there is a lot to do before simply
thinking about having runnable code with no sanity checks.

The last thing I'll ever assume is everything is gonna run without
problems, even if it does by now or for ages I will NEVER assume this is
a stable situation.

Yet the miles problem was not a computer problem, the computer was just
a part of a system, and human was another part of the same system. There
was a bug in the system, whatever part was buggy does not matter.

This is just my point of view...
 
T

Thomas Kellerer

Lew wrote on 06.10.2007 16:12:
More importantly, in only required one gaping flaw in their development
process.

The calculations in nautical miles (or km. or whatever it was) were
completely accurate. The module in question didn't have any bugs.

Likewise the calculations in statute miles also were completely
accurate. No bugs in that module either.

Put the two together and SPLOOSH.

Had the development teams had proper communication, and more
importantly, oversight, then things might've gone better.
If have heard the rumour that the misunderstanding regarding the units was
casused by the fact that the development lead was asked to document everything
using a PowerPoint presentation. As that presentation became too long certain
aspects were simply removed ("management summary"!) and thus the information
which units were used were lost.

I too have seen companies were important information was "compressed" beyond
recognition just to satisfy some dumb manager - "Can you make a PowerPoint out
of that (50+ pages) manual? I don't have time to read everything".

Thomas
 
L

Lew

Thomas said:
I too have seen companies were important information was "compressed"
beyond recognition just to satisfy some dumb manager - "Can you make a
PowerPoint out of that (50+ pages) manual? I don't have time to read
everything".

Such a person would, no doubt, miss the (power) point of
<http://norvig.com/Gettysburg/>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top