×

Loading...
Ad by
Ad by

xordos, inside please...

thanks for your info. It looks like JVMTI is available in 1.5. I did check JVMPI and JVMDI in older version, but had a few concerns due to the requirement.
Basically, what I want to do is to write a small piece of program to dump heap watch, thread and monitor information when certain criterial, such as outofmemory error or dramatic performance downgrade or any other application specific condition, is meet. However, a few restrictions have to be applied.
The jvm has to be 1.3 or 1.4.
It's best the small program is platform independent, writing a agent libary isn't a easy task and tend to be error prone.
It shouldn't slow down application noticably and use too much memory.
After all, profiling a 6000-thousand-java-file application isn't an easy task, some fatal issues can only be captured on production.
Any suggestions? Thanks.
Report

Replies, comments and Discussions:

  • 工作学习 / 专业技术讨论 / 请问如何用CODE 动态生成在JVM中所有的THREAD DUMP. JVM VERSION 是1.3 OR 1.4. 谢谢.我绝得需要用NATIVE CALL,但是没有一点头绪.谢谢
    • check J2SE source code how to implement that when you press ^Break
      • I know ctrl-break make jvm spit out thread dump. but how does it handle it? where to find that code to handle this keystoke? no clue. more hints please? thanks.
        • up
        • are you writing something like JVM inspector?
          • xordos, inside please...
            thanks for your info. It looks like JVMTI is available in 1.5. I did check JVMPI and JVMDI in older version, but had a few concerns due to the requirement.
            Basically, what I want to do is to write a small piece of program to dump heap watch, thread and monitor information when certain criterial, such as outofmemory error or dramatic performance downgrade or any other application specific condition, is meet. However, a few restrictions have to be applied.
            The jvm has to be 1.3 or 1.4.
            It's best the small program is platform independent, writing a agent libary isn't a easy task and tend to be error prone.
            It shouldn't slow down application noticably and use too much memory.
            After all, profiling a 6000-thousand-java-file application isn't an easy task, some fatal issues can only be captured on production.
            Any suggestions? Thanks.
            • I think I can't give you more helpful info..:(
              but, i want to say:
              1. Maybe a commerical production is more suitable. we use OptimizeIt from Borland, and it is quite cool.
              2. If you are really want to write your own, I think maybe you need study JDK source code, or ask your question to other more professional forum/list.
              Good luck.