News: DevStream Memory Scope Released - Java Memory Leak Analysis

  1. Java Memory Leaks have plagued Java/J2EE production operations for years. Developers can't reproduce the problem, and administrators don’t have the tools to locate memory leaks in production. DevStream claims this is no longer case with their release of Memory Scope – a tool which locates Java memory leaks with zero analysis effort.

    It also has a low overhead memory profiler, as the goal isn’t to provide developers/administrators with excessive information about memory allocation/garbage collection, but rather to simply identify and resolve Java memory leaks.

    DevStream is so confident of the new release, that they guarantee that MScope will locate any memory leak in any java code. MScope supports most J2EE application servers, including BEA Weblogic, IBM WebSphere, Oracle iAS, JBoss, JRun, and more on all major OS’s including Sun Solaris, HP-UX, Windows, Linux, IBM AIX, HP NonStop Server, and HP Tru64.

    MScope is a plug-in to DevStream’s JView 2004 – a leading J2EE Production Performance Profiler and Monitor.

    Learn more about MScope

    Threaded Messages (8)

  2. We are many that want to know![ Go to top ]

    "DevStream is so confident of the new release, that they guarantee that MScope will locate any memory leak.."

    So what are the results then? Was there any leak in the popular servers? (Weblogic, Websphere etc.) Or wasn't it?

    Rolf Tollerud
  3. Looking at J2EE Application servers[ Go to top ]

    Rolf - JView uses (configurable) filters to filter out non end-user code - JView hasn't been used to look at vendor application server memory leaks. It would be an interesting idea. Stay Tuned - I'll post more information in this forum.
  4. Looking at J2EE Application servers[ Go to top ]

    finally proof

    I am looking forward to it. The 100-200 post long thread full with squirming excuses :) Anyhow, however it falls out it will be good advertising for your company. If no leaks are found, you will be known as the company that squashed an ill-meant and untrue rumor ("Java Memory Leaks have plagued Java/J2EE production operations for years."). On the other hand if you find a lot of leaks. I leave it to your imagination..! Remember:

    "all publicity is good publicity"

    Rolf Tollerud
  5. No pricing available?[ Go to top ]

    Why no pricing listed on the web site? I'm always suspicious of companies that make you call somebody in order to get pricing.
  6. No Demo either[ Go to top ]

    I need to use it before I can buy it.
  7. Re: Demo[ Go to top ]

    There is a fully-functional 20-day trial of the core product, JView 2004, for performance profiling (no other enterprise J2EE production monitor competitor offers this).

    Due to the one-time use needs of Memory profiling, it is not generally available. If you're interested, email sales at devstream dot com and a consultant will work with you.
  8. I'll have to unmemleak a Swing app a short time from now.
    I'm an OptimizeIt user. The most challenging task is to interpret the
    information reported by the memory profiler.

    I bookmarked and I'm going to verify you claims ...
  9. zero analysis effort?[ Go to top ]

    Hi Mario,

    Can you explain how zero analysis is calculated? What is this measurement based on? I looked at the screenshots on the website but I still do not see how zero analysis could be attributed to the product.

    I have yet to see a memory leak that did not require some analysis. Questions still need to be answered as to WHY and HOW which in most cases is application and architecture specific and what I classify as analysis and not identification (pinpointing) which is what I think the marketing statement is referring to.

    Can you tell me will the product 'pinpoint' problems in server side code that is indirectly attributed to the cause of the memory leak. You mention that the product focuses on user code. Does this mean it only monitors instance references related to user code reference entry points? I know of many cases where the problem data structure is in system (container) code but which is caused (directly/indirectly) by user code (container contracts being broken).

    Can you please elaborate a bit more on what the product does and how it does it in the general sense?


    William Louth
    JDBInsight Product Architect