Jikes RVM

Possible fix for FreeListPageResource.releasePages()
----------------------------------------------------

                 Key: RVM-605
                 URL: http://jira.codehaus.org/browse/RVM-605
             Project: RVM
          Issue Type: Bug
          Components: MMTk
    Affects Versions: 2.9.3, 2.9.2
            Reporter: Michael Bond
            Assignee: Michael Bond
             Fix For: 3.0.1
         Attachments: releasePages-possible-fix.patch

When adding a RawPageSpace and doing many acquire() and release() calls, I sometimes get a crash because the following line in FreeListPageResource.freeContiguousChunk() fails, i.e., returns -1:

      int tmp = freeList.alloc(Space.PAGES_IN_CHUNK, chunkStart); // then alloc the entire chunk

Many Log.write()s later :) I think there may be a corner case in FreeListPageResource.releasePages() that needs slightly different handling.  The attached patch eliminates the errors I was getting, but could an MMTk expert please check the change and verify that it's correct since I don't fully understand the code?

thanks,
Mike

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Grove updated RVM-589:
----------------------------

    Fix Version/s:     (was: 3.0)
                   3.0.1

> Crash in GetStringUTFChars running xalan on ppc32-aix and ppc64-aix
> -------------------------------------------------------------------
>
>                 Key: RVM-589
>                 URL: http://jira.codehaus.org/browse/RVM-589
>             Project: RVM
>          Issue Type: Bug
>          Components: Instruction Architecture: PowerPC, Operating System: AIX, Runtime: JNI
>            Reporter: David Grove
>            Assignee: David Grove
>             Fix For: 3.0.1
>
>
> This is the most common failure on both ppc32-aix and ppc64-aix.  It seems to impact about 1 test every other run (ie, about 0.5 tests on average).
> ===== DaCapo xalan starting =====
> WARNING: attempt to get compiled method #0
> JikesRVM: internal error: recursive use of hardware exception registers (exiting)
> -- Stack --
>    at [0x4169dba4] Lorg/jikesrvm/runtime/RuntimeEntrypoints; deliverHardwareException(II)V at line 718
>    at [0x4169dc04] <hardware trap>
>    at [0x4169dc10] Lorg/jikesrvm/jni/JNIFunctions; GetStringUTFChars(Lorg/jikesrvm/jni/JNIEnvironment;ILorg/vmmagic/unboxed/Address;)Lorg/vmmagic/unboxed/Address; at line 3981
>    at [0x4169dc60] <invisible method>
>    at [0x4169dcc8] <native frame>
>    at [0x4169dd08] <native frame>
>    at [0x4169dd90] Lgnu/java/nio/VMChannel; open(Ljava/lang/String;I)I
>    at [0x4169de38] Lgnu/java/nio/VMChannel; openFile(Ljava/lang/String;I)V at line 732
>    at [0x4169de70] Lgnu/java/nio/FileChannelImpl; <init>(Ljava/io/File;I)V at line 151
>    at [0x4169deb0] Lgnu/java/nio/FileChannelImpl; create(Ljava/io/File;I)Lgnu/java/nio/FileChannelImpl; at line 141
>    at [0x4169dee0] Ljava/io/FileOutputStream; <init>(Ljava/io/File;Z)V at line 164
>    at [0x4169df28] Ljava/io/FileOutputStream; <init>(Ljava/io/File;)V at line 129
>    at [0x4169df50] Ldacapo/xalan/XalanHarness$XalanWorker; run()V at line 80
>    at [0x4169dfb0] Lorg/jikesrvm/scheduler/RVMThread; run()V at line 595
>    at [0x4169dfe8] Lorg/jikesrvm/scheduler/RVMThread; startoff()V at line 620
> One instance is: http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/core-ppc32/4370/prototype/default/dacapo/xalan
> I suspect a problem is that if a GC happens at this program point we're making a mistake when interpreting the stackframes, but it's possible that there is some other problem (or that this is an indirect crash caused by the current known problems of Identity HashMaps in the bootimage).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143365#action_143365 ] 

David Grove commented on RVM-442:
---------------------------------

I am looking at this, but it also fails on ppc-linux, so it is not AIX specific.


> All poisoned tests fail PPC 32
> ------------------------------
>
>                 Key: RVM-442
>                 URL: http://jira.codehaus.org/browse/RVM-442
>             Project: RVM
>          Issue Type: Bug
>          Components: Instruction Architecture: PowerPC, MMTk
>    Affects Versions: 2.9.2
>            Reporter: Ian Rogers
>            Assignee: David Grove
>            Priority: Critical
>             Fix For: 3.0
>
>
> Since enabling poisoned read/write barrier tests we are passing them nearly fully on IA32 but failing them all on PPC32 [1]. We appear to be deadlocking early in the VM.boot process.
> [1] http://jikesrvm.anu.edu.au/cattrack/results/excalibur.watson.ibm.com/sanity-ppc32/3456/regression_report

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Grove updated RVM-440:
----------------------------

    Fix Version/s:     (was: 3.0)
                   3.0.1

> Poisoned tests failing in finalizer thread
> ------------------------------------------
>
>                 Key: RVM-440
>                 URL: http://jira.codehaus.org/browse/RVM-440
>             Project: RVM
>          Issue Type: Bug
>          Components: Runtime
>    Affects Versions: 2.9.2
>            Reporter: Ian Rogers
>            Assignee: Daniel Frampton
>             Fix For: 3.0.1
>
>
> In r14119 poisoning regression tests were enabled. These stress read/write barriers. We got our first results [1] and there seems to be a problem in the finalizer thread, we have died in the PepTest of both Spec JBB versions [2] [3].
> [1] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32b.anu.edu.au/sanity/3447/statistics_report
> [2] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32b.anu.edu.au/sanity/3447/FullAdaptivePoisoned/default/SPECjbb2000/SPECjbb2000
> [3] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32b.anu.edu.au/sanity/3447/FullAdaptivePoisoned/default/SPECjbb2005/SPECjbb2005/default/Output.txt

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Grove updated RVM-596:
----------------------------

    Fix Version/s:     (was: 3.0)
                   3.0.1

> Updated installed JVMs on rvmppclnx64
> -------------------------------------
>
>                 Key: RVM-596
>                 URL: http://jira.codehaus.org/browse/RVM-596
>             Project: RVM
>          Issue Type: Sub-task
>          Components: Infrastructure: Test
>            Reporter: David Grove
>            Assignee: Daniel Frampton
>             Fix For: 3.0.1
>
>
> I'm using Java 5 SR7 to build on piano, and it seems to be able to build prototype & prototype-opt images without any problems.  
> I think it would be worth updating to the same level on rvmppclnx64.
> [dgrove@... ~]$ /opt/ibm/java2-ppc-50/bin/java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pxp32dev-20080315 (SR7))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux ppc-32 j9vmxp3223-20080315 (JIT enabled)
> J9VM - 20080314_17962_bHdSMr
> JIT  - 20080130_0718ifx2_r8
> GC   - 200802_08)
> JCL  - 20080314

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers updated RVM-423:
---------------------------

         Assignee: Ian Rogers
    Fix Version/s:     (was: 1000)
                   3.0

I believe this has settled down and we can close the issue. Cattrack is currently down, will close when I can confirm this.

> Fop performance strangeness
> ---------------------------
>
>                 Key: RVM-423
>                 URL: http://jira.codehaus.org/browse/RVM-423
>             Project: RVM
>          Issue Type: Bug
>            Reporter: Steve Blackburn
>            Assignee: Ian Rogers
>             Fix For: 3.0
>
>
> fop seems to have behaved strangely in the past day or so.  It *may* just be noise, but it is pretty weird.  Two of the contrasting data points seem to be for the same revision (which suggests noise), but the same performance seems to have persisted for a few runs.  
> Let's keep an eye on it.  If there's not a lot of commit activity, then it should soon become clear if it's just noise.
> http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3255/production/default/perf-dacapo/fop-10/fop-10-time.large.png

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Patches item #2030875, was opened at 2008-07-28 20:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712770&aid=2030875&group_id=128805

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: xlhuang (xlhuang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implementation of online object reordering (oopsla 2004)

Initial Comment:
        STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR

I, Xianglong Huang: 

(a) represent that either:

  (i) I am the only author and owner of the contributed software 
      (described as/entitled Online Object Reordering implementation), 
      which was neither derived nor copied from any other software,
  or 

 (ii) that any exception to (i) is software which was obtained under the 
      CPL (Common Public License), 

and   

(b)  hereby agree to license this contributed software under the CPL.

Description:
This patch is the implementation of Online Object Reordering
(OOR) algorithm from the OOPSLA 2004. This patch works
with JikesRVM version 2.9.3. This algorithm only works with GenCopy garbage collector. The commandline options this patch added are:

-X:aos:oor=true  // running oor optimization during the adaptive optimizing compilation. Default is "false"
-X:gc:copyOrder  // when given value "oor", it uses runtime information collected by adaptive compilation to direct copying objects into the older generation. the value of this option can also be "breadthfirst" or "depthfirst". Default is "depthfirst".
--X:aos:bb_threshold //This is a "hotness" threshold used by adaptive compilation. Only basic block with higher than this threshold "hotness" will be considered in the oor analysis. Default value is 0.5

 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712770&aid=2030875&group_id=128805

Require two different host JVMs to successfully build on Linux/PowerPC
----------------------------------------------------------------------

                 Key: RVM-604
                 URL: http://jira.codehaus.org/browse/RVM-604
             Project: RVM
          Issue Type: Bug
          Components: Instruction Architecture: PowerPC, Operating System: Linux
    Affects Versions: 3.0
            Reporter: David Grove
            Priority: Minor
             Fix For: 3.0.1


We currently need two different host JVMs to successfully build Jikes RVM on Linux/PowerPC.

One must use the IBM Java 6 JVM (currently recommend SR1) to build & compile the GNU Classpath class libraries.  GNU Classpath uses sun.misc.Unsafe.putOrderedObject, which is not defined in the IBM Java 5 SDKs, but is defined in the Java 6 SDK.  However, using this JVM as the host JVM for the bootimage writer produces non-working Jikes RVM images and/or crashes for some configurations.  To robustly run the bootimage writer, you need to use Java 5 (currently recommend SR7 or SR8).

The easiest way to workaround this, is to install both SDKs on the machine, but make the Java5 one the default one (found in the path when building Jikes RVM).  Hack the script RVM_ROOT/components/ecj/3.2/ecj-3.2/ecj to explictly invoke the Java 6 JVM instead of just 'java'.  This will let the GNU classpath build use Java 6 to compile its sources while using Java 5 to build the bootimage.  This is the workaround we are using for nightly regressions on both piano and rvmppclnx64.

As each new SR of Java 6 comes out, we need to see if it is capable of building the bootimage.  If it is, then we could simply switch the Java 6 across the board to build on Linux/PowerPC.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers reassigned RVM-33:
-----------------------------

    Assignee: Byeogncheol (BK) Lee

> JDWP & JVMTI support
> --------------------
>
>                 Key: RVM-33
>                 URL: http://jira.codehaus.org/browse/RVM-33
>             Project: RVM
>          Issue Type: New Feature
>          Components: Runtime
>            Reporter: Eslam AlMorshdy
>            Assignee: Byeogncheol (BK) Lee
>            Priority: Minor
>             Fix For: 1000
>
>         Attachments: RVM-33-collective-patch-against-gcp95
>
>   Original Estimate: 11 weeks
>  Remaining Estimate: 11 weeks
>
> Adding JDWP & JVMTI support
> JDWP & JVMTI  are standards introduced by sun to uniform the way JVM[s] are debugged/queried. They are not mandatory nor do they form requirements to comply with the JVM standard
> Java Debug Wire Protocol is an interface specification to debug/query the JVM status. It defines the format of information and requests transferred between the process being debugged and the debugger front end. JVMTI s a low-level native interface ( based on JNI) that defines the services a Java virtual machine provides for tools such as debuggers and profilers(which they are implemented as agents).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers resolved RVM-512.
----------------------------

         Assignee: Ian Rogers
       Resolution: Fixed
    Fix Version/s:     (was: 1000)
                   3.0

Fixed in r14318

> Experiment with freezing bucket array in VM_HashMap/VM_HashSet
> --------------------------------------------------------------
>
>                 Key: RVM-512
>                 URL: http://jira.codehaus.org/browse/RVM-512
>             Project: RVM
>          Issue Type: Improvement
>            Reporter: Ian Rogers
>            Assignee: Ian Rogers
>             Fix For: 3.0
>
>         Attachments: RVM-512.patch
>
>
> VM_HashMap and VM_HashSet perform open hashing, first having an array of buckets and then linking together buckets that are in the same array location. When the size of the HashMap/HashSet grows then the original array becomes garbage, which as the array is often/initially in the boot image, creates an array that is never reclaimed but always scanned in a stop-the-world GC. If we want to avoid the array becoming garbage then we can prevent a new one from being allocated. This will still let the open hashing work as elements will be linked together, the length of the links will get longer and make the average case use slower. The amount of space used in a development image for bucket arrays is 132KB or under 33,110 references. There is a trade-off in making the HashMap/HashSet slower after boot image creation and avoiding creating a unreclaimable garbage bucket array that is scanned during stop-the-world GC.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers closed RVM-234.
--------------------------


> Annotation issues: not implemented via proxy classes, support for serialization
> -------------------------------------------------------------------------------
>
>                 Key: RVM-234
>                 URL: http://jira.codehaus.org/browse/RVM-234
>             Project: RVM
>          Issue Type: Bug
>            Reporter: Ian Rogers
>            Assignee: Ian Rogers
>             Fix For: 3.0
>
>
> Proxy classes appear to be a better way to implement the virtual classes created by annotations. This isn't a requirement of the spec and could possibly lower
> performance.
> There's more info in the new Classpath Sun compatibility file:
> http://cvs.savannah.gnu.org/viewcvs/classpath/sun/reflect/annotation/AnnotationInvocationHandler.java?rev=1.1.4.1&root=classpath&view=markup
> We should look into this as its highly likely we don't have correctly serializable annotations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers reassigned RVM-91:
-----------------------------

    Assignee: Filip Pizlo

> Modularize threading system (native thread support)
> ---------------------------------------------------
>
>                 Key: RVM-91
>                 URL: http://jira.codehaus.org/browse/RVM-91
>             Project: RVM
>          Issue Type: Improvement
>          Components: Runtime: Threads and Concurrency
>            Reporter: Ian Rogers
>            Assignee: Filip Pizlo
>            Priority: Critical
>             Fix For: 1000
>
>
> Currently we only support M-to-N threading, that is mapping M Java threads on N virtual processors executing on N pthreads. This causes a number of issues when interacting with native code and we have a number of complicated solutions to this problem. The thread system should be redesigned to support the mapping of M Java threads to M pthreads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Improve intel baseline prologue/epilogue/call by use push/pop instead of mov [sp]
---------------------------------------------------------------------------------

                 Key: RVM-603
                 URL: http://jira.codehaus.org/browse/RVM-603
             Project: RVM
          Issue Type: Improvement
          Components: Compiler: Baseline, Instruction Architecture: Intel
            Reporter: Ian Rogers
            Assignee: Ian Rogers
             Fix For: 3.0


Currently all procedure calls use moves of values from sp rather than the shorter and faster push/pop instructions. It would be better to use push/pop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers resolved RVM-329.
----------------------------

         Assignee: Ian Rogers
       Resolution: Won't Fix
    Fix Version/s:     (was: 1000)
                   3.0

Fairly sure this isn't a performance win. What would be better is a IA32 disassembler that could be optional called as part of the assembler generation loop, then two variants of the loop can be created with and without the disassembler.

> Specialize IA32 assembler for lister vs. non-lister
> ---------------------------------------------------
>
>                 Key: RVM-329
>                 URL: http://jira.codehaus.org/browse/RVM-329
>             Project: RVM
>          Issue Type: Improvement
>          Components: Instruction Architecture: Intel
>            Reporter: David Grove
>            Assignee: Ian Rogers
>            Priority: Minor
>             Fix For: 3.0
>
>
> Suggestion by Ian in a commit message that I think could be a good one, so don't want to forget.....
> We could make the IA32 assembler into two classes: a superclass that doesn't print anything, and a subclass that does. In the listing version, each of the emit methods is overridden to call super, then do the print.
> The downside is we are very likely to take a virtual call on each emit method (although the opt compiler could probably still do some guarded inlining).  The plus is that we eliminate all the lister checks and calls in the superclass
> Not clear if this would actually be a performance win, since the "real" virtual call on the emit methods might out-weigh the gain from specializing away the lister checks, but it might be worth prototyping.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers resolved RVM-327.
----------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 1000)
                   3.0

We now inline all cases where the registers are constant and the generated code shows no signs of doing dispatch on an enum.

> Performance degredation in IA32 assembler
> -----------------------------------------
>
>                 Key: RVM-327
>                 URL: http://jira.codehaus.org/browse/RVM-327
>             Project: RVM
>          Issue Type: Bug
>          Components: Compiler: Baseline, Compiler: Optimizing, Instruction Architecture: Intel
>    Affects Versions: 2.9.3
>            Reporter: David Grove
>            Assignee: Ian Rogers
>            Priority: Minor
>             Fix For: 3.0
>
>
> r13833 introduced enumerations into the IA32 assembler, resulting in more maintainable code but a 8-10% slowdown in baseline compilation rate.
> See http://jira.codehaus.org/browse/RVM-322 for performance data.
> We need to get this performance back as baseline compile time can be a significant factor in startup performance of the VM on large programs.  It is also a chance to discover opportunities for improving the performance of code that is using enumerations in a controlled setting that may lead to optimizations that are more generally applicable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/RVM-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Rogers resolved RVM-597.
----------------------------

    Resolution: Fixed

Fix committed in r14811. Will close after some regression tests go by.

> Array index out of bounds in BC2IR generation context
> -----------------------------------------------------
>
>                 Key: RVM-597
>                 URL: http://jira.codehaus.org/browse/RVM-597
>             Project: RVM
>          Issue Type: Bug
>          Components: Compiler: Optimizing
>            Reporter: Ian Rogers
>            Assignee: Ian Rogers
>            Priority: Critical
>             Fix For: 3.0
>
>
> An example of the bug is here:
> http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4483/production/default/perf-jbb2000/jbb2000GC/1/Output.txt
> there appears to be a mismatch between the number of operands returned by the Call instruction and those expected by the method.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

OSR bytecodes cause the opt compiler bcIndex to be unintelligible
-----------------------------------------------------------------

                 Key: RVM-602
                 URL: http://jira.codehaus.org/browse/RVM-602
             Project: RVM
          Issue Type: Improvement
          Components: Compiler: Adaptive Optimization System, Compiler: Optimizing
            Reporter: Ian Rogers
            Assignee: David Grove
             Fix For: 3.1


If we a method that requires a special OSR prologue and epilogue for the opt compiler we turn the bytecodes into a single stream starting at index 0. In BC2IR we adjust the bytecode index of some instructions so that it corresponds to that of the original bytecode. There appear to be latent bugs in this - RVM-597 for example, I believe there is a similar problem for runtime exceptions such that null and bound check failures would get the wrong exception handler as the bcIndex appears in the code to be wrong by the bciAdjustment, however, the exception handler map has some adjustment to take this into account. The comments in the exception handler map and BC2IR indicate that this design is in the process of being rethought. This needs to be sorted out as these latent bugs are now surfacing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira