Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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.
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,788
Rep:
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.
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.
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,788
Rep:
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.
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 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.