Skip to content
Snippets Groups Projects
  1. Jul 03, 2020
  2. Apr 09, 2020
  3. Jul 10, 2017
  4. May 10, 2017
  5. 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
  6. Nov 12, 2018
  7. Nov 10, 2015
  8. Dec 22, 2014
  9. Oct 17, 2014
  10. Mar 19, 2014
  11. Dec 03, 2013
  12. Oct 25, 2013
  13. Sep 11, 2013
  14. Sep 09, 2013
  15. Aug 22, 2013
  16. Aug 21, 2013
  17. Aug 20, 2013
  18. Aug 19, 2013
  19. Aug 16, 2013
  20. Aug 09, 2013
  21. Jul 19, 2013
  22. Jul 18, 2013
  23. Jun 05, 2013
  24. Jun 04, 2013
  25. Jun 02, 2013
  26. May 30, 2013
  27. Mar 29, 2013
  28. Jan 22, 2013
  29. 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
  30. Nov 07, 2012
  31. Feb 22, 2013
  32. Feb 21, 2013
  33. Jan 10, 2012
  34. Dec 13, 2011
  35. Aug 05, 2011
Loading