Jikes RVM

Patches item #1209805, was opened at 2005-05-27 12:27
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=1209805&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
Submitted By: jeremy singer (giraffe21)
Assigned to: Nobody/Anonymous (nobody)
Summary: comment fixes for JNI stack frame layouts on PowerPC Linux

Initial Comment:
I have noticed some inconsistencies in the comments for
PowerPC/Linux stack frame layouts during JNI calls. The
issues came to light as I modified the PowerPC/Linux
code to run on our ARM/Linux experimental backend.

To set up the stack for a JNI call (from Java to C), it
is necessary to construct two "mini frames" also known
as "glue frames". These are labelled in comments as
"mini frame (1)" and "mini frame (2)". However they are
not labelled consistently!

This patch tries to resolve the inconsistencies. Now,
mini frame (1) should always be closer to the Java
caller frame, and mini frame (2) should always be
closer to the C native callee frame.

I've only looked at the baseline compiler, and I
haven't touched any GC code. So there may still be
inconsistencies lurking elsewhere...


 STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR

I, _____Jeremy Singer_________: 

(a) represent that either:

  (i) I am the only author and owner of the contributed
software 
      (described as/entitled _______Jikes RVM
patch_____________________), 
      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.


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

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

Hi,

I did a CVS update and to my regret I now find the following errors from 
Jikes:

Found 1 semantic error compiling "java/lang/Object.java":

     7. import com.ibm.JikesRVM.VM_ObjectModel;
                                ^------------^
*** Semantic Error: A candidate for type "VM_ObjectModel" was found, but 
it is invalid and needs to be fixed before this type will successfully 
compile.

Found 7 semantic errors compiling "org/mmtk/vm/Scanning.java":

    81.   public static void enumeratePointers(ObjectReference object, 
Enumerate _enum)
                                                                       
^-------^
*** Semantic Error: Type "org.mmtk.vm.Enumerate" was not found.


   114.       enumeratePointers(VM_Scheduler.threads, preCopyEnum);
              ^--------------------------------------------------^
*** Semantic Error: No applicable overload for a method with signature 
"enumeratePointers(com.ibm.JikesRVM.VM_Thread[], 
org.mmtk.utility.scan.PreCopyEnumerator)" was found in type 
"org.mmtk.vm.Scanning". Perhaps you wanted the overloaded version "void 
enumeratePointers(org.vmmagic.unboxed.ObjectReference object, ?? _enum) 
throws org.vmmagic.pragma.UninterruptiblePragma, 
org.vmmagic.pragma.InlinePragma;" instead?


   121.         enumeratePointers(thread, preCopyEnum);
                ^------------------------------------^
*** Semantic Error: No applicable overload for a method with signature 
"enumeratePointers(com.ibm.JikesRVM.VM_Thread, 
org.mmtk.utility.scan.PreCopyEnumerator)" was found in type 
"org.mmtk.vm.Scanning". Perhaps you wanted the overloaded version "void 
enumeratePointers(org.vmmagic.unboxed.ObjectReferenceobject, ?? _enum) 
throws org.vmmagic.pragma.UninterruptiblePragma, 
org.vmmagic.pragma.InlinePragma;" instead?


   122.         enumeratePointers(thread.contextRegisters, preCopyEnum);
                ^-----------------------------------------------------^
*** Semantic Error: No applicable overload for a method with signature 
"enumeratePointers(com.ibm.JikesRVM.VM_Registers, 
org.mmtk.utility.scan.PreCopyEnumerator)" was found in type 
"org.mmtk.vm.Scanning". Perhaps you wanted the overloaded version "void 
enumeratePointers(org.vmmagic.unboxed.ObjectReference object, ?? _enum) 
throws org.vmmagic.pragma.UninterruptiblePragma, 
org.vmmagic.pragma.InlinePragma;" instead?


   123.         enumeratePointers(thread.hardwareExceptionRegisters, 
preCopyEnum);
                
^---------------------------------------------------------------^
*** Semantic Error: No applicable overload for a method with signature 
"enumeratePointers(com.ibm.JikesRVM.VM_Registers, 
org.mmtk.utility.scan.PreCopyEnumerator)" was found in type 
"org.mmtk.vm.Scanning". Perhaps you wanted the overloaded version "void 
enumeratePointers(org.vmmagic.unboxed.ObjectReference object, ?? _enum) 
throws org.vmmagic.pragma.UninterruptiblePragma, 
org.vmmagic.pragma.InlinePragma;" instead?


   128.           enumeratePointers(thread.jniEnv, preCopyEnum);
                  ^-------------------------------------------^
*** Semantic Error: No applicable overload for a method with signature 
"enumeratePointers(com.ibm.JikesRVM.jni.VM_JNIEnvironment, 
org.mmtk.utility.scan.PreCopyEnumerator)" was found in type 
"org.mmtk.vm.Scanning". Perhaps you wanted the overloaded version "void 
enumeratePointers(org.vmmagic.unboxed.ObjectReference object, ?? _enum) 
throws org.vmmagic.pragma.UninterruptiblePragma, 
org.vmmagic.pragma.InlinePragma;" instead?


   144.   private static void enumeratePointers(Object object, Enumerate 
_enum)
                                                               ^-------^
*** Semantic Error: Type "Enumerate" was not found.

Found 2 semantic errors compiling "org/mmtk/vm/ScanThread.java":

   213.     VM_GCMapIteratorGroup iteratorGroup = collector.iteratorGroup;
                                                            ^-----------^
*** Semantic Error: No accessible field named "iteratorGroup" was found 
in type "com.ibm.JikesRVM.memoryManagers.mmInterface.VM_CollectorThread".


   214.     iteratorGroup.newStackWalk(t);
            ^---------------------------^
*** Semantic Error: No applicable overload for a method with signature 
"newStackWalk(com.ibm.JikesRVM.VM_Thread)" was found in type 
"com.ibm.JikesRVM.memoryManagers.mmInterface.VM_GCMapIteratorGroup". 
Perhaps you wanted the overloaded version "void 
newStackWalk(com.ibm.JikesRVM.VM_Thread thread, 
org.vmmagic.unboxed.Address registerLocation) throws 
org.vmmagic.pragma.UninterruptiblePragma;" instead?

Found 1 semantic error compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/utility/gcspy/Subspace.java":

     9. import org.mmtk.vm.gcspy.Util;
               ^--------------------^
*** Semantic Error: The import "org/mmtk/vm/gcspy/Util" is not valid, 
since it does not name a type in a package.

Found 4 semantic errors compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/utility/gcspy/drivers/AbstractDriver.java":

    10. import org.mmtk.vm.gcspy.ServerSpace;
               ^---------------------------^
*** Semantic Error: The import "org/mmtk/vm/gcspy/ServerSpace" is not 
valid, since it does not name a type in a package.


    11. import org.mmtk.vm.gcspy.ServerInterpreter;
               ^---------------------------------^
*** Semantic Error: The import "org/mmtk/vm/gcspy/ServerInterpreter" is 
not valid, since it does not name a type in a package.


    12. import org.mmtk.vm.gcspy.Util;
               ^--------------------^
*** Semantic Error: The import "org/mmtk/vm/gcspy/Util" is not valid, 
since it does not name a type in a package.


    34.   protected ServerSpace space;                  // The GCspy 
space abstraction
                    ^---------^
*** Semantic Error: Type "ServerSpace" was not found.

Found 10 semantic errors compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/utility/gcspy/drivers/TreadmillDriver.java":

    12. import org.mmtk.utility.gcspy.Subspace;
                                      ^------^
*** Semantic Error: A candidate for type "Subspace" was found, but it is 
invalid and needs to be fixed before this type will successfully compile.


    16. import org.mmtk.vm.gcspy.ServerInterpreter;
               ^---------------------------------^
*** Semantic Error: The import "org/mmtk/vm/gcspy/ServerInterpreter" is 
not valid, since it does not name a type in a package.


    17. import org.mmtk.vm.gcspy.ServerSpace;
               ^---------------------------^
*** Semantic Error: The import "org/mmtk/vm/gcspy/ServerSpace" is not 
valid, since it does not name a type in a package.


    18. import org.mmtk.vm.gcspy.Stream;
               ^----------------------^
*** Semantic Error: The import "org/mmtk/vm/gcspy/Stream" is not valid, 
since it does not name a type in a package.


    33. public class TreadmillDriver extends AbstractDriver
                                             ^------------^
*** Semantic Error: A candidate for type "AbstractDriver" was found, but 
it is invalid and needs to be fixed before this type will successfully 
compile.


    76.   private Stream usedSpaceStream;
                  ^----^
*** Semantic Error: Type "Stream" was not found.


    77.   private Stream objectsStream;
                  ^----^
*** Semantic Error: Type "Stream" was not found.


   132.     space = new ServerSpace(
                        ^---------^
*** Semantic Error: Type "ServerSpace" was not found.


   147.            = new Stream(
                         ^----^
*** Semantic Error: Type "Stream" was not found.


   164.    objectsStream = new Stream(
                               ^----^
*** Semantic Error: Type "Stream" was not found.

Found 1 semantic error compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/utility/Treadmill.java":

     6. import org.mmtk.utility.gcspy.drivers.TreadmillDriver;
                                              ^-------------^
*** Semantic Error: A candidate for type "TreadmillDriver" was found, 
but it is invalid and needs to be fixed before this type will 
successfully compile.

Found 1 semantic error compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/policy/LargeObjectSpace.java":

     8. import org.mmtk.utility.Treadmill;
                                ^-------^
*** Semantic Error: A candidate for type "Treadmill" was found, but it 
is invalid and needs to be fixed before this type will successfully compile.

Found 2 semantic errors compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/plan/BasePlan.java":

     9. import org.mmtk.policy.LargeObjectSpace;
                               ^--------------^
*** Semantic Error: A candidate for type "LargeObjectSpace" was found, 
but it is invalid and needs to be fixed before this type will 
successfully compile.


    26. import org.mmtk.vm.PlanConstants;
               ^-----------------------^
*** Semantic Error: The import "org/mmtk/vm/PlanConstants" is not valid, 
since it does not name a type in a package.

Found 2 semantic errors compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/utility/heap/HeapGrowthManager.java":

     7. import org.mmtk.plan.BasePlan;
                             ^------^
*** Semantic Error: A candidate for type "BasePlan" was found, but it is 
invalid and needs to be fixed before this type will successfully compile.


    11. import org.mmtk.vm.PlanConstants;
               ^-----------------------^
*** Semantic Error: The import "org/mmtk/vm/PlanConstants" is not valid, 
since it does not name a type in a package.

Found 1 semantic error compiling 
"com/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread.java":

     8. import org.mmtk.utility.heap.HeapGrowthManager;
                                     ^---------------^
*** Semantic Error: A candidate for type "HeapGrowthManager" was found, 
but it is invalid and needs to be fixed before this type will 
successfully compile.

Found 1 semantic error compiling "com/ibm/JikesRVM/VM_Magic.java":

     9. import 
com.ibm.JikesRVM.memoryManagers.mmInterface.VM_CollectorThread;
                                                           
^----------------^
*** Semantic Error: A candidate for type "VM_CollectorThread" was found, 
but it is invalid and needs to be fixed before this type will 
successfully compile.

Found 1 semantic error compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/plan/StopTheWorldGC.java":

    18. import org.mmtk.vm.PlanConstants;
               ^-----------------------^
*** Semantic Error: The import "org/mmtk/vm/PlanConstants" is not valid, 
since it does not name a type in a package.

Found 2 semantic errors compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/plan/Generational.java":

    21. import org.mmtk.vm.PlanConstants;
               ^-----------------------^
*** Semantic Error: The import "org/mmtk/vm/PlanConstants" is not valid, 
since it does not name a type in a package.


    55. public abstract class Generational extends StopTheWorldGC
                                                   ^------------^
*** Semantic Error: A candidate for type "StopTheWorldGC" was found, but 
it is invalid and needs to be fixed before this type will successfully 
compile.

Found 1 semantic error compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/plan/GenMS.java":

    54. public class GenMS extends Generational implements Uninterruptible {
                                   ^----------^
*** Semantic Error: A candidate for type "Generational" was found, but 
it is invalid and needs to be fixed before this type will successfully 
compile.

Found 2 semantic errors compiling 
"com/ibm/JikesRVM/memoryManagers/mmInterface/VM_AllocatorHeader.java":

     9. import org.mmtk.vm.PlanConstants;
               ^-----------------------^
*** Semantic Error: The import "org/mmtk/vm/PlanConstants" is not valid, 
since it does not name a type in a package.


    15. import com.ibm.JikesRVM.VM_Magic;
                                ^------^
*** Semantic Error: A candidate for type "VM_Magic" was found, but it is 
invalid and needs to be fixed before this type will successfully compile.

Found 1 semantic error compiling "com/ibm/JikesRVM/VM_ObjectModel.java":

     8. import 
com.ibm.JikesRVM.memoryManagers.mmInterface.VM_AllocatorHeader;
                                                           
^----------------^
*** Semantic Error: A candidate for type "VM_AllocatorHeader" was found, 
but it is invalid and needs to be fixed before this type will 
successfully compile.

Found 1 semantic error compiling 
"com/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface.java":

    30. import org.mmtk.vm.PlanConstants;
               ^-----------------------^
*** Semantic Error: The import "org/mmtk/vm/PlanConstants" is not valid, 
since it does not name a type in a package.

Found 1 semantic error compiling "Dummy.java":

     7. import com.ibm.JikesRVM.memoryManagers.mmInterface.MM_Interface;
                                                           ^----------^
*** Semantic Error: A candidate for type "MM_Interface" was found, but 
it is invalid and needs to be fixed before this type will successfully 
compile.

Found 1 semantic error compiling 
"/home/simgroup/IanR/current/symlink-antigua/MMTk/src/org/mmtk/utility/scan/Scan.java":

    62.       Scanning.enumeratePointers(object, _enum);
              ^---------------------------------------^
*** Semantic Error: No applicable overload for a method with signature 
"enumeratePointers(org.vmmagic.unboxed.ObjectReference, 
org.mmtk.utility.scan.Enumerator)" was found in type 
"org.mmtk.vm.Scanning". Perhaps you wanted the overloaded version "void 
enumeratePointers(org.vmmagic.unboxed.ObjectReference object, ?? _enum) 
throws org.vmmagic.pragma.UninterruptiblePragma, 
org.vmmagic.pragma.InlinePragma;" instead?
...compilation FAILED) jbuild.compile: The Jikes compiler exited with 
status 1

Is this being fixed? or is my CVS repository out of sync?

Thanks,

Ian Rogers

After the 2.3.6 release goes out, I plan to remove support for all 
versions of GNU classpath prior to 0.15. 

There have been some fairly extensive changes to classpath since 0.10, 
which makes all of the versions of the VM booting and library 
initialization code complex and hard to maintain. I'm also generally in 
favor of deleting code/configurations we don't test.  Supporting Jikes RVM 
on 7 versions of classpath  (only two of which we actually test nightly) 
is too much. 

I will leave in all of the general framework for building with multiple 
versions of classpath.  That is very useful, since we will always have to 
build and test with at least two versions of classpath (latest release and 
cvs head).

--dave

Bugs item #1208774, was opened at 2005-05-25 16:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1208774&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: tools
Group: confirmed
Status: Open
Resolution: None
Priority: 8
Submitted By: Dave Grove (dgrove-oss)
Assigned to: Nobody/Anonymous (nobody)
Summary: update of _timestamp file broken

Initial Comment:
Last worked on 5/22.

Suspect victim of changes in sf infrastructure that
became effective on the 23rd.

Related issue.  Need to do housecleaning in CVSROOT to
remove crud leftover from developerworks and aborted
attempts to get various things working on sourceforge.
 It's a little murky exactly which subset of the
scripts and config files are actually active

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

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

timestamping mechanism stopped working on 5/22. 

My guess is that it is due to changes in sf cvs/web infrastructure that 
were made on the 23rd.  I'm investigating briefly; will open defect if I 
can't resolve in next 45 minutes.

--dave

Feature Requests item #1208566, was opened at 2005-05-25 11:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712771&aid=1208566&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: build
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Dave Grove (dgrove-oss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Separate code and data in bootimage

Initial Comment:
Restructure bootimage writer so that code and data get
output into separate files.  Then mmap these files into
different address ranges. 

Similar motivations as
http://sourceforge.net/tracker/index.php?func=detail&aid=1208562&group_id=128805&atid=712771
but the mechanisms are different.

Also need to do this in a forward-looking manner to
enable future direct-call enhancements planned for the
compilers.

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

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

Feature Requests item #1208562, was opened at 2005-05-25 11:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712771&aid=1208562&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: GC
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Dave Grove (dgrove-oss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Separate code space for dynamically generated code

Initial Comment:
Add a separate code space to MMTk.

Currently in Jikes RVM code and data are allocated
together (one big happy heap).  This is simple, but
opens us to a host of performance problems.  Some of
the issues are:
  (1) mixing code and mutable data causes havoc with
trace caches.
  (2) Inefficiences in allocation and GC
  (3) If the code is in a moving space, we have
problems with getting icache/dcache in sync on PPC and
general confusion of hardware predictors as the code
moves around.
  (4) Poor usage of i-TLB 
  (5) and so on, and so on.....

For bonus points, we should have two code spaces. One
for cold (baseline compiled) code and one for hot (opt
compiled) code.  This may have further slight
advantages, but the biggest win will be just having at
least one code space to segregate the code and the data.






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

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

Feature Requests item #1207781, was opened at 2005-05-24 08:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712771&aid=1207781&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: baseline compiler
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Dave Grove (dgrove-oss)
Assigned to: Nobody/Anonymous (nobody)
Summary: IA32 Baseline compiler: don't use dedicated JTOC register

Initial Comment:
On IA32, the opt compiler has long exploited the fact
that the JTOC is at a non-moving, well-known location.
 This enables the generation of load/store operations
without a base register (ie, at a constant address).

Making a similar change in the baseline compiler would
enable us to "undedicate" the JTOC register in the IA32
baseline compiler, which would cleanup the code and
maybe save a few instructions here and there.  I don't
expect measurable performance gains; the motivation is
code cleanup/simplification and slight reduction in
code space.



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

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

Feature Requests item #1206953, was opened at 2005-05-23 10:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712771&aid=1206953&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: baseline compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Rogers (captain5050)
Assigned to: Nobody/Anonymous (nobody)
Summary: Handling of JVM operand stack is inefficient

Initial Comment:
For the sequence of bytecodes:

iload 1        // load local variable one
biconst 10  // push the int value 10
iadd            // add 2 stack values
istore 1       // store the result in local variable one

we generate the following Intel code:

push memory operand  // store value at memory location
                                   // to stack (in memory)
push 10                       // push constant 10 to stack
pop T0                         // pop value from stack
into T0
add [stack location], T0 // add value on stack in
memory to T0
pop memory operand    // pop value to memory location

of the generated instructions there are 2+1+1+2+2=8
memory references.

A simple way to improve this inefficiency is to capture
the use of the stack in a separate abstraction. This
abstraction can simulate the use of the stack by
pushing/popping tokens. When an add bytecode is reached
it can directly access the constant tokens, or plant
accesses to local variables as necessary. This would
amount to a very small compilation cost, but a great
boost to baseline performance.

Ian Rogers

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

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

Patches item #1205798, was opened at 2005-05-20 17:54
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=1205798&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
Submitted By: Ian Rogers (captain5050)
Assigned to: Nobody/Anonymous (nobody)
Summary: More efficient [df]cmp[gl] and lcmp for Intel baseline

Initial Comment:
This patch removes branch code from the fcmpg, fcmpl,
dcmpg, dcmpl and lcmp and uses conditional moves
instead. The Intel optimization guide recomends this
for branches without predictable behaviour.

       STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR

I, _Ian Rogers_: 

(a) represent that either:

  (i) I am the only author and owner of the contributed
software 
      (described as/entitled
____________________________), 
      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.


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

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

Patches item #1205034, was opened at 2005-05-19 15:41
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=1205034&group_id=128805

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Rogers (captain5050)
Assigned to: Nobody/Anonymous (nobody)
Summary: Faster long shifts on Intel

Initial Comment:
Long shifts by 1 can be optimized using the carry flag.
Long shifts of registers can be optimized using
conditional moves rather than jumps.

        STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR

I, _Ian Rogers_: 

(a) represent that either:

  (i) I am the only author and owner of the contributed
software 
      (described as/entitled
____________________________), 
      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.


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

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

I got Jikes RVM working on classpath 0.15 last night.  I'll be checking in 
the required changes later today and switching the watson night sanity 
runs over to using classpath 0.15.

Assuming no unexpected regressions appear, I plan to make a 2.3.6 release 
on Friday.  We could delay until Monday if there are additional minor 
things people want to get into the release.  Let me know (if I hear 
nothing, then I will most likely proceed with a release on Friday based on 
cvs as of Thursday night at start of nightly regression).

--dave