Skip to content
Snippets Groups Projects
  1. Jul 27, 2020
  2. Aug 25, 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. Aug 19, 2013
  6. Aug 16, 2013
  7. Aug 09, 2013
  8. Mar 29, 2013
  9. Feb 21, 2013
  10. 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
  11. Jun 30, 2011
  12. Jun 29, 2011
  13. Dec 04, 2010
  14. Oct 14, 2010
  15. Oct 13, 2010
  16. Sep 21, 2010
  17. Aug 13, 2010
  18. Apr 19, 2010
    • Tofu Linden's avatar
      Change Linux fasttimer implementation back to RDTSC - using a reliable syscall... · 7462911b
      Tofu Linden authored
      Change Linux fasttimer implementation back to RDTSC - using a reliable syscall was REALLY chewing CPU time.  Sigh.  I didn't realize how incredibly often this gets called.  So, back to the assembly.
      But be more careful with CPU clock count on linux, so the fasttimer values are much more accurate than they were the last time we were with RDTSC, in absolute terms - back in the right order of magnitude anyway.
      
      Also change many instances of Mhz to MHz.
      Also some minor comment fixes.
      7462911b
  19. Mar 18, 2010
  20. Mar 05, 2010
  21. Mar 04, 2010
  22. May 22, 2009
    • Brad Kittenbrink's avatar
      DEV-27646 dll linkage for login module. · 01d39082
      Brad Kittenbrink authored
      Ok, finally got this to a point where it doesn't break the build and I can check
      in. llcommon can be built as a shared library (disabled but can be enabled with
      cmake cache var LLCOMMON_LINK_SHARED.
      
      reviewed by Mani on tuesday (I still need to get his suggested changes
      re-reviewed)
      01d39082
  23. Jan 07, 2009
  24. Jun 25, 2008
  25. Dec 21, 2007
  26. Oct 04, 2007
  27. Aug 21, 2007
  28. Jul 25, 2007
  29. Jul 02, 2007
  30. Apr 11, 2007
  31. Jan 02, 2007
Loading