Selection of L1B compiler from the command line building of JNode
| Project: | JNode Core |
| Component: | Code |
| Category: | task |
| Priority: | minor |
| Assigned: | tango_java_06 |
| Status: | closed |
Description
That L1B cannot be getting choosed as baseline compiler for building JNode.
Here that bug fixed. We can specify now the L1B or L1A for building time of JNode.
The example make.cmd for Windows platform builder will be as :
Make.cmd :
set ANT_HOME=E:\ant set ANT_LIB=E:\ant\lib set JAVA_HOME=%PROGRAMFILES%\Java\jdk1.6.0_02 set JAVACMD=%PROGRAMFILES%\Java\jdk1.6.0_02\bin\java.exe build.bat -Djnode.compiler=l1B cd-x86-lite> buildlog.txt
The build.sh in Linux should work as :
$./build.sh -Djnode.compiler=l1B cd-x86-lite>buildlog.txt
| Attachment | Size |
|---|---|
| L1B compiler selection.patch | 1.41 KB |
- Login to post comments
#1
What you are trying to do is a good idea, but I think you are doing it the wrong way.
User modifiable build options should be specified in the "jnode.properties" file not as "-D" options on the command line. When my build configuration tool is complete, the "jnode.properties" file will be created and updated by that tool. Right now the file is created from "jnode.properties.dist" and updated by hand using a text editor.
The code in your patch would be simpler (IMO better) if you used String.equalsIgnoreCase() to compare the compiler names rather than calling String.equals() for each possible permutation of upper and lower case in the names. There are also contains a number of code style errors; 5 by my count.
#2
Thanks Stephen first, for your comments.
For designing the compilers, and enhancing the current one, this will be a good way for developers for testing their compilers for building JNode.
I just tried in that way. So, any new ideas are welcome for taking decision on this matter that how the compiler selection will be easiest for the new Testing compilers.
Thanks for the String.equalsIgnoreCase()'s info. I also searching that perticular method. But, i overlooked. I sending a new patch with that method
#3
Applied a fix based on this patch. Marking as fixed.
#4
Steve, if you'd like to work on the L1B compiler (now or in the future) please make a note here or somewhere as Levente planned to remove L1B.
#5
I would indeed like to do some work on the compiler. I don't know which one one (L1A, L1B, L2 or something else) is an appropriate place to work though. Its not likely to happen for a month or so.
If Levente plans to remove compilers, IMO he should first provide some outline documentation to explain what they do / did. While deleted stuff can be retrieved from SVN, someone doing devt work would have to know that it is there ... and preferably where and when.
Even if I don't work on it, we can assume that someone will ... eventually.
#6
Actually that one is me in that case. L1B was created a loong time ago when Ewout was still active. He created it basically for me to make some tests while keeping the original compiler. You could select at build time if you want l1a or l1b.
Everything that was worthy was moved to l1a afterwards, so right now l1a and l1b are basically the same (except the extended bytecode stats in l1b).
L2 was thought as an optimizing compiler that compiles hotspots (given you have profiling data, at least method invocation counts). I have no idea about its state but it had always been far from usable. Despite that instead of L2 porting jikesopt would still be an option and is what the jikes branch was/is about.
I'm not sure how to proceed with this. But if you like to extend/optimize the baseline compiler, l1b would indeed be a good idea, on the other hand if noone plans to work on that I still wouldn't mind deleting it (as it's basically a copy of l1a).
#7
I'm really marking this as fixed now
#8
Automatically closed -- issue fixed for two weeks with no activity.
#9
Manually closed.