Skip to content
Snippets Groups Projects
  1. Jul 10, 2017
  2. May 10, 2017
  3. May 02, 2017
    • Nat Goodspeed's avatar
      DRTVWR-418, MAINT-6996: Rationalize LLMemory wrt 64-bit support. · 52899ed6
      Nat Goodspeed authored
      There were two distinct LLMemory methods getCurrentRSS() and
      getWorkingSetSize(). It was pointless to have both: on Windows they were
      completely redundant; on other platforms getWorkingSetSize() always returned
      0. (Amusingly, though the Windows implementations both made exactly the same
      GetProcessMemoryInfo() call and used exactly the same logic, the code was
      different in the two -- as though the second was implemented without awareness
      of the first, even though they were adjacent in the source file.)
      
      One of the actual MAINT-6996 problems was due to the fact that
      getWorkingSetSize() returned U32, where getCurrentRSS() returns U64. In other
      words, getWorkingSetSize() was both useless *and* wrong. Remove it, and change
      its one call to getCurrentRSS() instead.
      
      The other culprit was that in several places, the 64-bit WorkingSetSize
      returned by the Windows GetProcessMemoryInfo() call (and by getCurrentRSS())
      was explicitly cast to a 32-bit data type. That works only when explicitly or
      implicitly (using LLUnits type conversion) scaling the value to kilobytes or
      megabytes. When the size in bytes is desired, use 64-bit types instead.
      
      In addition to the symptoms, LLMemory was overdue for a bit of cleanup.
      
      There was a 16K block of memory called reserveMem, the comment on which read:
      "reserve 16K for out of memory error handling." Yet *nothing* was ever done
      with that block! If it were going to be useful, one would think someone would
      at some point explicitly free the block. In fact there was a method
      freeReserve(), apparently for just that purpose -- which was never called. As
      things stood, reserveMem served only to *prevent* the viewer from ever using
      that chunk of memory. Remove reserveMem and the unused freeReserve().
      
      The only function of initClass() and cleanupClass() was to allocate and free
      reserveMem. Remove initClass(), cleanupClass() and the LLCommon calls to them.
      
      In a similar vein, there was an LLMemoryInfo::getPhysicalMemoryClamped()
      method that returned U32Bytes. Its job was simply to return a size in bytes
      that could fit into a U32 data type, returning U32_MAX if the 64-bit value
      exceeded 4GB. Eliminate that; change all its calls to getPhysicalMemoryKB()
      (which getPhysicalMemoryClamped() used internally anyway). We no longer care
      about any platform that cannot handle 64-bit data types.
      52899ed6
  4. Nov 10, 2015
  5. Dec 22, 2014
  6. Oct 17, 2014
  7. Mar 19, 2014
  8. Dec 03, 2013
  9. Oct 25, 2013
  10. Sep 11, 2013
  11. Sep 09, 2013
  12. Aug 22, 2013
  13. Aug 21, 2013
  14. Aug 20, 2013
  15. Aug 19, 2013
  16. Aug 16, 2013
  17. Aug 09, 2013
  18. Jul 19, 2013
  19. Jul 18, 2013
  20. Jun 05, 2013
  21. Jun 04, 2013
  22. Jun 02, 2013
  23. May 30, 2013
  24. Mar 29, 2013
  25. Jan 22, 2013
  26. Nov 15, 2012
    • Richard Linden's avatar
      SH-3406 WIP convert fast timers to lltrace system · 9d77e030
      Richard Linden authored
      cleaning up build
      moved most includes of windows.h to llwin32headers.h to disable min/max macros, etc
      streamlined Time class and consolidated functionality in BlockTimer class
      llfasttimer is no longer included via llstring.h, so had to add it manually in several places
      9d77e030
  27. Nov 07, 2012
  28. Feb 22, 2013
  29. Feb 21, 2013
  30. Jan 10, 2012
  31. Dec 13, 2011
  32. Aug 05, 2011
  33. Aug 03, 2011
  34. Jul 12, 2011
    • Nat Goodspeed's avatar
      CHOP-753: Eliminate redundant array-of-pair-arrays in LLMemoryInfo. · ed648b1f
      Nat Goodspeed authored
      (per Monty code review)
      The notion of storing LLMemoryInfo data both as an LLSD::Map and an
      LLSD::Array of pair arrays arose from a (possibly misguided) desire to
      continue producing stats output into the viewer log in the same order it
      always used to be produced. There is no evidence that anyone cares about the
      order of those stats in the log; there is no other use case for preserving
      order. At Monty's recommendation, eliminate generating and storing the
      array-of-pair-arrays form: directly store LLSD::Map.
      ed648b1f
    • Nat Goodspeed's avatar
      CHOP-753: Defend against boost::regex exceptions. · e58a0e9b
      Nat Goodspeed authored
      (per Monty code review)
      Explain why we intentionally don't suppress exceptions from boost::regex
      objects constructed with string literals. Catch std::runtime_error from
      boost::regex_search() and boost::regex_match(); log and return false.
      e58a0e9b
Loading