Re: building jikes on redhat 9

Hi Jon,

The latest release 2.3.0 and the current cvs head have been tested
on a "clean" RH 9.0 machine (i.e. installed from scratch just for
the purposes of testing this release).  Here are the details from
an off-line email:

> For the record, it is a vanilla RedHat 9.0 "Workstation" install with
> the following two post installs:
> 
>    . Blackdown 1.4.1 in /opt/j2sdk1.4.1
>         j2sdk-1.4.1-01-linux-i586-gcc2.95.bin
>    . jikes 1.18 in /usr/bin
>         jikes-1.18-1.i386.rpm
> 
> No other changes or additions have been made.
> 
> Cheers,
> 
> --Steve

The key thing is that a RedHat "Workstation" install includes a bunch
of important development tools and libraries.  The email Sunil mentioned
was with respect to a minimal RedHat install.  If you do a "Workstation"
install and make the above two additions (blackdown & jikes), you should
have no problems.  I hope this helps.

Cheers,

--Steve

bug in BC to HIR conversion

Hello,
Jikes refuses to compile (using opt compiler) the following sequence of 
bytecodes that I believe is legal according to the language spec:

    astore 1
l:  aload 1
    invokevirtual
    ...
    goto l

The problem is related to the incorrect passing of information about 
locals. This is my understanding of what happens. When the compilers 
visits the astore and aload instructions for the first time (when 
executing OPT_BC2IR.generateFrom()) it considers them to be located in 
the same basic block BBLE. It correctly computes the information about 
the values of local variable 1  in the beginning of this basic block and 
stores them into "localState" variable of BBLE (this value is null - 
variable 1 gets set in the middle of this basic block). When it visits 
goto instruction it realizes that BBLE must be split and regenerated. It 
splits BBLE int BBLE1 and BBLE2 and copies the state of local variables 
from BBLE1 to BBLE2. However, the value of local variable at the beginning 
of BBLE2 is NOT NULL. When the compiler tries to use value of variable 1 
when generating code for BBLE2 it gets null and crashes.
			
My major question is whether this could be considered a bug in the 
compiler or the HIR has been intentionally (e.g. for simplicity) 
implemented this way since this sequence of bytecode is unlikely to be 
generated by Javac. I stumbled upon this problem because I am rewriting 
the bytecode and it is essential for me to be able to compile this kind of 
code.

Re: bug in BC to HIR conversion

Re: jbui.linkBooter error during build

On Fri, 29 Aug 2003, Steven Augart wrote:
>
> I bet you're running GCC 2.95 or 2.96 on a Linux/x86 platform.

Yup I'm using gcc 2.95 on Debian. Not sure on the exact distribution
version. The machine is administered by another group.

>
> That version of the compiler does not understand the flags
> -Wno-float-equal, nor the flag -Wno-unreachable-code.
> Go into rvm/bin/jconfigure, line # 2695.  Remove those two flags from after
> ${BOOTER_CXX}.  Rerun jconfigure.
>

I removed the flags from jconfigure and I get the following result:

jbuild.expand: (templates cleaned) 0 s
jbuild.copy: (sources cleaned) 0 s
jbuild.compile: (classes cleaned) 0 s
jbuild.linkImage: (primordials cleaned) (bootimage cleaned) 0 s
jbuild.linkBooter: (booter cleaned) 0 s
jbuild.expand: (classloader templates expanded) 12 s
jbuild.copy: preprocessModifiedFiles.C:948: warning: `unused' attribute
ignored
preprocessModifiedFiles.C: In function `char * getToken(char **, int &)':
preprocessModifiedFiles.C:949: warning: unused parameter `int & trouble'
(preprocessor built) (classpath.jar copied) 28 s
jbuild.compile: (classes compiled) (jksvm.jar built) (jksvmsrc.jar built)
44 s
jbuild.linkImage: (bootimage cleaned) (primordial class names written)
(built workaround zip) (bootimage linked) 69 s
jbuild.linkBooter: (booter cleaned) (classpath native libraries copied)
preprocessModifiedFiles.C:948: warning: `unused' attribute ignored
preprocessModifiedFiles.C: In function `char * getToken(char **, int &)':
preprocessModifiedFiles.C:949: warning: unused parameter `int & trouble'
syswrap.C:381: warning: `unused' attribute ignored
syswrap.C:388: warning: `unused' attribute ignored
syswrap.C:388: warning: `unused' attribute ignored
syswrap.C:388: warning: `unused' attribute ignored
syswrap.C:395: warning: `unused' attribute ignored
syswrap.C:402: warning: `unused' attribute ignored
In file included from /usr/include/linux/net.h:23,
                 from sys.C:47:
/usr/include/linux/wait.h:4: warning: `WNOHANG' redefined
/usr/include/bits/waitflags.h:26: warning: this is the location of the
previous definition
/usr/include/linux/wait.h:5: warning: `WUNTRACED' redefined
/usr/include/bits/waitflags.h:27: warning: this is the location of the
previous definition
sys.C:1527: warning: `unused' attribute ignored
sys.C:2074: warning: `unused' attribute ignored
sys.C:2074: warning: `unused' attribute ignored
sys.C:2159: warning: `unused' attribute ignored
sys.C:2159: warning: `unused' attribute ignored
sys.C:2160: warning: `unused' attribute ignored
sys.C:2160: warning: `unused' attribute ignored
sys.C:2161: warning: `unused' attribute ignored
sys.C:2161: warning: `unused' attribute ignored
sys.C:2268: warning: `unused' attribute ignored
sys.C:2269: warning: `unused' attribute ignored
sys.C:2270: warning: `unused' attribute ignored
libvm.C:578: warning: `unused' attribute ignored
libvm.C:658: warning: `unused' attribute ignored
cc1plus: Invalid option `-Wno-unreachable-code'
ihnpdsm.C:2026: warning: `unused' attribute ignored
ihnpdsm.C:2334: warning: `unused' attribute ignored
ihnpdsm.C:2477: warning: `unused' attribute ignored
ihnpdsm.C:2827: warning: `unused' attribute ignored
ihnpdsm.C:2864: warning: `unused' attribute ignored
ihnpdsm.C:3329: warning: `unused' attribute ignored
ihnpdsm.C:3353: warning: `unused' attribute ignored
ihnpdsm.C:3453: warning: `unused' attribute ignored
ihnpdsm.C:3472: warning: `unused' attribute ignored
ihnpdsm.C:3493: warning: `unused' attribute ignored
ihnpdsm.C:3514: warning: `unused' attribute ignored
ihnpdsm.C:3534: warning: `unused' attribute ignored
ihnpdsm.C:3598: warning: `unused' attribute ignored
ihnpdsm.C:4888: warning: `unused' attribute ignored
ihnpdsm.C:4942: warning: `unused' attribute ignored
74 s
jbuild: Trouble while running "./jbuild.linkBooter " (exit status 1);
aborting execution

All the messages seem to be warnings so in theory they should not cause
problems with the build.

frojas <at> ccs.neu.edu
TEL: 617 373 7921
FAX: 617 373 5121

Re: jbui.linkBooter error during build

Hi,
there's another -Wno-unreachable-code at line #2714. I think that might be 
your problem

Sunil

> cc1plus: Invalid option `-Wno-unreachable-code'

Re: jbui.linkBooter error during build

I believe Sunil's answer is correct.  Your build failed because the
compiler ran into -Wno-unreachable-code and couldn't understand it.
--Steve

|---------+-------------------------------------------------------->
|         |           "Sunil V. Soman" <sunils <at> cs.ucsb.edu>        |
|         |           Sent by:                                     |
|         |           jikesrvm-researchers-admin <at> www-124.southbury.|
|         |           usf.ibm.com                                  |
|         |                                                        |
|         |                                                        |
|         |           02/09/2003 12.24                             |
|         |           Please respond to jikesrvm-researchers       |
|         |                                                        |
|---------+-------------------------------------------------------->
  >-------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                   |
  |       To:       jikesrvm-researchers <at> www-124.southbury.usf.ibm.com                                                |
  |       cc:                                                                                                         |
  |       Subject:  Re: [Jikesrvm-researchers] jbui.linkBooter error during build                                     |
  |                                                                                                                   |
  >-------------------------------------------------------------------------------------------------------------------|

Hi,
there's another -Wno-unreachable-code at line #2714. I think that might be
your problem

Sunil

> cc1plus: Invalid option `-Wno-unreachable-code'

Re: jbui.linkBooter error during build

I think Steve B was (implicitly) saying: it would be best to upgrade to the
"right" version of gcc ..... Eliot

inliner error?

Hi there,

In the work that I am doing, we are adding a parameter to the allocation
sequence. To do this, in OPT_ExpandRuntimServices.java, the parameter is
being added to the conversion of new -> call. I have noticed that when I
add an extra parameter to NEW_opcode, this causes an
ArrayIndexOutOfBoundsException to occur during inlining. Is this a bug?

Thanks,
-Maria

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 4
        at com.ibm.JikesRVM.opt.ir.OPT_BC2IR.<init>(OPT_BC2IR.java:186)
        at com.ibm.JikesRVM.opt.ir.OPT_BC2IR.generateHIR(OPT_BC2IR.java:88)
        at com.ibm.JikesRVM.opt.ir.OPT_Inliner.execute(OPT_Inliner.java:389)
        at com.ibm.JikesRVM.opt.ir.OPT_Inliner.execute(OPT_Inliner.java:75)
        at com.ibm.JikesRVM.opt.OPT_ExpandRuntimeServices.inline(OPT_ExpandRuntimeServices.java:382)
        at com.ibm.JikesRVM.opt.OPT_ExpandRuntimeServices.inline(OPT_ExpandRuntimeServices.java:358)
        at com.ibm.JikesRVM.opt.OPT_ExpandRuntimeServices.perform(OPT_ExpandRuntimeServices.java:103
)
        at com.ibm.JikesRVM.opt.OPT_CompilerPhase.performPhase(OPT_CompilerPhase.java:129)
        at com.ibm.JikesRVM.opt.OPT_OptimizationPlanAtomicElement.perform(OPT_OptimizationPlanAtomic
Element.java:80)
        at com.ibm.JikesRVM.opt.OPT_OptimizationPlanCompositeElement.perform(OPT_OptimizationPlanCom
positeElement.java:141)
        at com.ibm.JikesRVM.opt.OPT_CompilationPlan.execute(OPT_CompilationPlan.java:111)
        at com.ibm.JikesRVM.opt.OPT_Compiler.compile(OPT_Compiler.java:223)
        at com.ibm.JikesRVM.VM_RuntimeCompiler.optCompile(VM_RuntimeCompiler.java:262)
        at com.ibm.JikesRVM.VM_RuntimeCompiler.recompileWithOpt(VM_RuntimeCompiler.java:404)

where OPT_ExpandRuntimeServices.perform(OPT_ExpandRuntimeServices.java:103)
line numbers are:
 98        if (ir.options.INLINE_NEW) {
 99          if (inst.getBasicBlock().getInfrequent()) container.counter1++;
100          container.counter2++;
101          if (!ir.options.FREQ_FOCUS_EFFORT || !inst.getBasicBlock().getInfrequent()) {
102            VM.sysWriteln("Inlining: ");
103            inline(inst, ir);
104          }
105        }

---------------------------------------------------------------------
Maria Jump                                        mjump <at> cs.utexas.edu
Computer Science Department                              512.232.7446
University of Texas @ Austin                              ACES 3SEi2C

Re: inliner error?

do the number and types of your actual parameters match the numbers and types of the formal parameters of the method that you are calling?  That would be the usual reason for an ArrayIndexOutOfBoundsException on that line of BC2IR.

It's probably completely random, but I have seen more than one GC bug in the past that has surfaced as ArrayIndexOutOfBoundsException.  The bounds check basically just grabs a random word of memory that is supposed to be an array length, compares it to the value of the index, and then traps if it is out of bounds.  If you have a corrupted heap, ArrayIndexOutOfBounds and CheckCastException are two common confusing ways in which it can show up.  Of course, I'm mainly a compiler guy, so I always want to blame the GC first

--dave

inserting code in the epilogue

Hi,
I'm trying to add some code to the epilogue. Something like:

asm.emitMOV_Reg_RegDisp (EBX, SP, STACKFRAME_MY_RETURN_ADDRESS_OFFSET);
asm.emitCMP_Reg_Imm (EBX, 0);
asm.emitCMOV_Cond_RegDisp_Reg (asm.EQ, SP, 
STACKFRAME_RETURN_ADDRESS_OFFSET, EBX);       

I'm positive that EBX is non-zero (for a certain method) after the first 
MOV. I've tried both compilers. An unconditional MOV (for the same method) 
instead of the CMOV seems to work (and the return address points to 
wherever I want it to). But the CMOV just doesn't seem to execute. I tried 
other instructions (just for the heck of it): 

asm.emitSET_Cond_RegDisp_Byte(asm.EQ, SP, 
STACKFRAME_RETURN_ADDRESS_OFFSET); // attempting to mess up the return 
address

This always executes (no matter what the compare or condition is) - seems 
to me something's really wrong with the flags for my code ?

Is there anyway I can look at the actual runtime x86 stack/x86flags/etc. ? 
I've already looked at the generated x86 code (mc=true).
Can someone see something wrong with this please ? I would really 
appreciate any advice/feedback/suggestions.

Thanks much.
Sunil