1. 01 Jan, 2015 3 commits
  2. 31 Dec, 2014 1 commit
  3. 12 Dec, 2014 2 commits
  4. 18 Dec, 2014 1 commit
  5. 10 Dec, 2014 3 commits
  6. 08 Nov, 2014 1 commit
  7. 07 Nov, 2014 2 commits
  8. 06 Nov, 2014 5 commits
  9. 05 Nov, 2014 2 commits
  10. 03 Nov, 2014 2 commits
  11. 31 Oct, 2014 1 commit
  12. 30 Oct, 2014 2 commits
    • Erik Brangs's avatar
    • Erik Brangs's avatar
      Backed out multiple changesets related to RVM-1083 because they belong to a... · 3a1b0c12
      Erik Brangs authored
      Backed out multiple changesets related to RVM-1083 because they belong to a line of development that isn't salvageable.
      
      The changeset af1e1b490a33822e0cf6d45bf714be856a786861 (RVM-1083 : Save guard information in GenerationContext.) was the final changeset in that line of development.
      
      The commits
      - 10986:fa4df3929879119ab88523b7d41eb6cc94a6c2bd (RVM-1083 : Move static methods that deal with guards from BC2IR to GenerationContext.)
      - 10987:ddbf1fe8c73bac8f7ef045b6ebf27cafdf722cc7 (RVM-1083 : Convert methods that deal with guards in GenerationContext to instance methods.)
      - 10988:6a62e43b1efa4caa7c57b3c8b1a87144dba1baed (RVM-1083 : Change all accesses to guards in the HIR to go through GenerationContext.)
      are part of changes to move the responsibility for saving guards from scratchObject in RegisterOperand to GenerationContext.
      
      The changes were incorrect because they did not properly deal with the guard information in RegisterOperand. The guard information was not propagated to copies of RegisterOperand made via copy(). The resulting lack of guard information caused more inlining which lead to an increase in the size of the bootimages.
      
      It is impractical to change all the places where copy() is used just to pull the guard information out of RegisterOperand. Therefore, this line of development needed to be abandoned. It is much saner to just leave the guard information in RegisterOperand.
      3a1b0c12
  13. 28 Oct, 2014 3 commits
  14. 27 Oct, 2014 4 commits
  15. 25 Oct, 2014 1 commit
    • Erik Brangs's avatar
      Add support for the JUnit test format in regression tests. · 5b33636d
      Erik Brangs authored
      The "JUnit test format" is the XML format that's used by the Ant JUnit task. AFAIK there is no formal specification of the format so we use what is understood by Jenkins. The alternatives would have been to write a Jenkins plugin that understands our format or to use another general format (e.g. TAP which is also supported via a Jenkins plugin, see https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin ). Both of these options were likely to require more work and it is unclear to me if they would have offered substantial advantages for the increased effort.
      
      It's not possible to do a 1-to-1 mapping of our format to the JUnit format. For example, the JUnit format provides a possibility to distinguish between the output of System.out and System.err . Such a distinction does not exist in our test results. Conversely, our test format contains some additional information (e.g. command lines, exit codes, parameters) that cannot be mapped onto the JUnit format. This problem is currently solved by putting the additional information from our reports into the JUnit output for System.err and the names of the testsuites.
      5b33636d
  16. 22 Oct, 2014 2 commits
  17. 21 Oct, 2014 3 commits
  18. 20 Oct, 2014 1 commit
    • Erik Brangs's avatar
      RVM-1083 : Save machine code offsets in a separate class instead of using... · 41033819
      Erik Brangs authored
      RVM-1083 : Save machine code offsets in a separate class instead of using Instruction's scratch field and remove the now unused field.
      
      This commit also introduces changes to cope with two instances of missing machine code offsets that have been revealed by the move to a separate data structure for the offset.
      
      Firstly, machine code offsets are not set for IR_PROLOGUE instructions in non-interruptible code. This is merely an oddity and it is not easily fixable, so the code works around that by dealing with IR_PROLOGUE instructions in a special way.
      
      Secondly, when the exception table is generated in OptExceptionTable, the code may encounter catch blocks that have no associated code (and therefore no machine code offsets) because they are unreachable according to the optimizing compiler. This occurs when building a development boot image in the method writeSFManifest(..) from gnu.java.util.jar.JarUtils . In such a case, it is safe to not add the entry to the table because it is impossible that the entry would be used. This is based on the assumption that the optimizing compiler was correct in determining that the catch block is unreachable. In any case, this behaviour is no worse than the previous behaviour of falsely claiming that there is a catch block at machine code offset 0, which is directly at the start of the method.
      
      The rest of the changes are pretty straightforward with the exception of some changes to the assemblers. It was necessary to save the machine code offsets in the assemblers via an instance variable which in turn made it necessary to move away from having a static generateCode() method as entrypoint for code generation.
      41033819
  19. 17 Oct, 2014 1 commit