Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34470

Re: Java program "debugging" itself...

Show all headers | View raw

In article <slrnnl3aa2.456.avl@login.logic.tuwien.ac.at>, Andreas 
Leitgeb (avl@logic.at) says...

> The tasks are auto-converted from another language that had no concept
> of a heap, and its static and local variables were quite limited in size.
> 
> The converted tasks themselves "cannot" leak nor pack-rat memory,
> but my own methods (that make up the library) may have bugs.
> 
> As the (converted) application is in productive use already for
> about a year now, the remaining bugs seem to have become pretty rare.
> 
> Changing all array creations to method calls would be a pretty big
> change with a non-trivial risk of introducing new bugs.  And I'd
> have to wrap StringBuilder and many Collection classes, too.
> 
> That's why I hoped for some "meta-API" of the JVM, that would allow
> me to control maximum allowable array-sizes (and maybe other settings
> that I haven't even yet dreamt of), which would allow me to set up a
> custom advanced safety net beyond the standard one within the JVM.

Probably you could do this:

1. use an MBean to trigger a warning mechanism, before reaching memory 
limits:

http://www.inoneo.com/en/blog/8/java/monitoring-jvm-memory-usage-inside-
a-java-application

1a: have this warning mechanism call "jcmd <pid> GC.class_histogram" to 
dump into a file how many instances of each class are currently on the 
heap (make sure you set a timed limit when to trigger this, you don't 
want to fill your HD with dumps, and you don't want to dump too often).

or 

1b: with a little bit use of deprecated APIs, (Java9 will hate you), 
dump an estimate of the amount of bytes each thread allocated:

final com.sun.management.ThreadMXBean threadMXBean = 
(com.sun.management.ThreadMXBean) ManagementFactory.getThreadMXBean();
final long[] threadIDs = threadMXBean.getAllThreadIds();
final ThreadInfo[] threadInfos = threadMXBean.getThreadInfo(threadIDs);

final Map<ThreadInfo, Long> threadToMem = new HashMap<>();
Arrays.stream(threadInfos)
 .forEach(
  info -> threadToMem.put(info, threadMXBean.getThreadAllocatedBytes
(info.getThreadId())));

final TreeMap<ThreadInfo, Long> sortedMap 
 = new TreeMap<>((i1, i2) -> -Long.compare(threadToMem.get(i1), 
threadToMem.get(i2)));

sortedMap.putAll(threadToMem);

//dump info:
sortedMap
 .forEach((i, m) -> System.out.println(m + "\t" + i.getThreadName()));


Note that the number of bytes will not decrease on garbage collection, 
it will increase monotonically. Still, depending on how the program 
works, it may still provide a good hint which thread is excessivelly 
filling up memory.

See also: 
https://docs.oracle.com/javase/7/docs/jre/api/management/extension/com/s
un/management/ThreadMXBean.html


Kind regards,
Wanja


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 13:36 +0000
  Re: Java program "debugging" itself... Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-02 14:17 +0000
    Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 15:06 +0000
      Re: Java program "debugging" itself... Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-02 11:14 -0400
        Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 15:43 +0000
  Re: Java program "debugging" itself... "comp.lang.coffee" <kirandesai84@gmail.com> - 2016-06-02 07:21 -0700
    Re: Java program "debugging" itself... Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-02 10:38 -0400
      Re: Java program "debugging" itself... Robert Klemme <shortcutter@googlemail.com> - 2016-06-02 22:24 +0200
    Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 15:28 +0000
      Re: Java program "debugging" itself... Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-02 22:22 +0000
        Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-03 15:58 +0000
          Re: Java program "debugging" itself... Wanja Gayk <brixomatic@yahoo.com> - 2016-06-04 21:32 +0200

csiph-web