1. 05 Dec, 2019 3 commits
  2. 04 Dec, 2019 3 commits
  3. 11 Oct, 2019 3 commits
    • Lubomir Bulej's avatar
      Try bumping the test time limit to 45 seconds · c34d7ce8
      Lubomir Bulej authored
      Again, this is to accomodate the "dispatchmp" test on slower
      machines (it takes 14-15 seconds on a modern machine).
      c34d7ce8
    • Lubomir Bulej's avatar
      Increase test time limit to 20 seconds · 93054bab
      Lubomir Bulej authored
      This may be necessary for the "dispatchmp" test to finish
      on slower machines.
      93054bab
    • Lubomir Bulej's avatar
      Fix race in "dispatchmp" test and repeatedly force GC · 54396d6c
      Lubomir Bulej authored
      The race was in the code displaying the "So far received..." message.
      After the check if the counter value modulo 1000000 was zero, the
      value actually displayed was queried again, potentially obtaining a
      different value (another thread might have incremented the counter).
      
      To force the client to send notifications about garbage collected
      objects, the client code forces the GC repeatedly and waits a bit
      between the attempts.
      54396d6c
  4. 09 Oct, 2019 3 commits
  5. 05 Apr, 2019 2 commits
  6. 13 Nov, 2018 1 commit
  7. 06 Nov, 2018 1 commit
    • Lubomir Bulej's avatar
      Remove setMultipleValDelim() from the marker Parameter class · 5800edd8
      Lubomir Bulej authored
      This was a source of issues with markers which forgot to set the
      delimiter prior to requesting multiple values. Instead, the
      getMultipleValues() method has been modified to require the delimiter
      as an argument, forcing the users of the Parameter class to supply the
      delimiter on use. The BytecodeMarker, InsnNodeMarker, and the
      StrictBytecodeMarker were updated to reflect the change.
      5800edd8
  8. 20 Oct, 2018 8 commits
  9. 15 Oct, 2018 2 commits
  10. 12 Oct, 2018 2 commits
  11. 11 Oct, 2018 1 commit
    • Lubomir Bulej's avatar
      Call shutdown() on socket before close() in DiSL and Shadow VM agents · bf0727c3
      Lubomir Bulej authored
      This is to ensure that data that may still be in socket
      buffers when close() is called are sent to the other side.
      This mainly applies to the Shadow VM agent, because it only
      sends data to the Shadow VM server and does not expect any
      reply, but it is probably a good practice in general.
      bf0727c3
  12. 17 Sep, 2018 1 commit
  13. 27 Apr, 2018 10 commits