From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Kartik Ohri <kartikohri13(at)gmail(dot)com> |
Cc: | pljava-dev(at)lists(dot)postgresql(dot)org |
Subject: | Re: Starting build-system work (Windows/Mac users please speak up) |
Date: | 2020-05-29 13:21:49 |
Message-ID: | 5ED10C6D.2020000@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pljava-dev |
On 05/29/20 08:14, Chapman Flack wrote:
> It may take some study and iteration to figure out patterns to search for
> in that output that will be sensitive to the most useful messages. But
> just getting the output saved somewhere is a good start.
Honestly, looks like the vast majority are local refs exceeding capacity in
com.sun.management.internal.DiagnosticCommandImpl.getDiagnosticCommandInfo.
I think a whole sequence like this is one warning and its stack trace:
INFO: WARNING: JNI local refs: %d, exceeds capacity: %d
INFO: at com.sun.management.internal.DiagnosticCommandImpl.getDiag...
INFO: at ...
...(22 more lines)...
INFO: at java.lang.management.ManagementFactory.getPlatformMBeanServer...
INFO: - locked <%#016x>
INFO: (a java.lang.Class for java.lang.management.ManagementFactory)
INFO: at org.postgresql.pljava.internal.DualState.<clinit>...
I was scratching my head why DualState.<clinit> would be getting called
so many times (I was expecting *one*), but I think what happens is it
starts the PlatformMBeanServer off in its own thread and that just reuses
the whole stack trace it inherited at birth forever.
I am pretty sure if sequences of just that one pattern were filtered out,
the result would be way, way shorter and the messages remaining in it
would be interesting ones.
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2020-05-29 13:33:42 | Re: Starting build-system work (Windows/Mac users please speak up) |
Previous Message | Chapman Flack | 2020-05-29 12:14:40 | Re: Starting build-system work (Windows/Mac users please speak up) |