LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   java compiler? (https://www.linuxquestions.org/questions/linux-software-2/java-compiler-633475/)

airswit 04-06-2008 01:09 PM

java compiler?
 
Hi All,

i am trying to compile a java app (hoping it will run faster), but i am running into a problem. I am trying to compile with gcj (gcc v3.4.4), but my app was built with java v1.6.

a couple questions:
1. is there an easier compiler to use/install for redhat (work computer)
2. how can i install a second version of gcc/gcj (newest release), without overwriting the original (i can't, anyway)
3. can/should i use the -target 1.x option for my app build, and if so, does anyone know what version i should use to work with my version of gcj/gcc?

any help appreciated

-Trevor

Uncle_Theodore 04-06-2008 01:38 PM

Quote:

Originally Posted by airswit (Post 3112682)
Hi All,

i am trying to compile a java app (hoping it will run faster), but i am running into a problem. I am trying to compile with gcj (gcc v3.4.4), but my app was built with java v1.6.

I think, it would be much better for you to just download and install Sun's JDK from their site. http://developers.sun.com/downloads/

airswit 04-06-2008 01:42 PM

does it include an ahead-of-time compiler?

jlliagre 04-06-2008 04:14 PM

It doesn't and I doubt it is in the Java community agenda to work in that direction.

Focusing on understanding why your program doesn't perform as well as you expect and improving it where it needs to be might be more productive than trying to run it under gcj. There is no strong evidence that a gcj compiled applications will run significantly faster (if faster at all) than the same one under recent JVMs.

airswit 04-06-2008 08:58 PM

well, this application analyzes on the order of millions of lines of data each time it updates it's information. i need any speedup i can get (the interface is not the slow part, it is the updating of state information that the app tracks).

also, before i got my hands on this project, it was running of of swap space (holding on to maybe 20k records, each having ~10 strings in them), and i had to get around that by putting a limit on the amount of data that i could track.

jlliagre 04-07-2008 02:44 AM

According to your description, there would be no significant advantage in ahead of time compiling. The JIT compiling time being peanuts compared to execution time.

Garbage collecting algorithms and heap sizing might make a difference. You may consider using a 64 bit JVM too.

airswit 04-07-2008 05:37 PM

i didn't realize that the 'java' app was a jit compiler. i thought it was an interpreter.

could you tell me how to increase the heap size? is this a compile-time option or a runtime option?

jlliagre 04-07-2008 06:24 PM

These are runtime options.

Try "java -Xint ..." and feel what pure interpretation performance looks like ...

To set the heap size:

-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size

eg. "java -Xms1g -Xmx1g ..."

jtshaw 04-07-2008 06:35 PM

You also might want to look at Sun's Tuning Whitepaper for it's JVM.

airswit 04-07-2008 08:56 PM

thanks for the tips. i guess the book i read is a bit out of date (circa '99, i think), and it implied that the basic running of a java app was using interpreted, not a jit.

for reference (and to get an idea on what i might increase my heap size to be), is there any way to find out what the default heap size is?

-Thanks

jlliagre 04-08-2008 02:09 AM

The default maximum heap size is 64M.

jtshaw 04-08-2008 06:11 AM

Quote:

Originally Posted by airswit (Post 3114067)
thanks for the tips. i guess the book i read is a bit out of date (circa '99, i think), and it implied that the basic running of a java app was using interpreted, not a jit.

I might be a little fuzzy on the details... but I believe the way it worked in its original implementation was the java "compiler" compiled into byte code (the platform independent stuff) that was interpreted by the JVM. Overtime they went to just-in-time compilation of the byte code into native code which dramatically increased speed. Now days I believe they have gone even further with some implementations and the JVM uses dynamic recompilation to optimize the program as it sees fit during runtime. In the end game, you can actually end up with a program that runs faster/more efficient then statically compiled code.


All times are GMT -5. The time now is 02:15 AM.