I am trying to profile (using jvirtualvm) a program that I have compiled ABCL into. I'm using ABCL to script the application, and rapidly prototype extensions.
The program is the PRISM model checker (http://www.prismmodelchecker.org/), for anyone who is interested.
Oddly, I find that the profiler's call graph shows not just my top level main() program as a root, but also multiple jobs running RMI TCP connection. These are all in the idle state, but seem to be chewing up a lot of CPU.
There are 16 of these processes and an RMI thread scheduler.
Is there any way that ABCL could be causing this to happen? I don't see any use of RMI in the host PRISM program, but then I don't see it in ABCL, either.
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 25 Nov 2014, at 21:55, Robert Goldman rpgoldman@sift.net wrote:
I am trying to profile (using jvirtualvm) a program that I have compiled ABCL into. I'm using ABCL to script the application, and rapidly prototype extensions.
I’m not familiar with jvirtualvm: what is it? Do you mean [JVisuamVM][1]?
[1]: http://docs.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html
The program is the PRISM model checker (http://www.prismmodelchecker.org/), for anyone who is interested.
Oddly, I find that the profiler's call graph shows not just my top level main() program as a root, but also multiple jobs running RMI TCP connection. These are all in the idle state, but seem to be chewing up a lot of CPU.
There are 16 of these processes and an RMI thread scheduler.
Is there any way that ABCL could be causing this to happen? I don't see any use of RMI in the host PRISM program, but then I don't see it in ABCL, either.
Stock ABCL contains no reference to Java RMI code, so I would suspect that the RMI-associated threads would be part of the profiling machinery you are using.
Mark Evenson wrote:
On 25 Nov 2014, at 21:55, Robert Goldman rpgoldman@sift.net wrote:
I am trying to profile (using jvirtualvm) a program that I have compiled ABCL into. I'm using ABCL to script the application, and rapidly prototype extensions.
I’m not familiar with jvirtualvm: what is it? Do you mean [JVisuamVM][1]?
Yes, that's right. Sorry about the typo.
At the expense of following up on my own thread.....
I have Java code that is calling Lisp according to some of the examples I have read.
I make a single Interpreter object, then I look up a function as defined in ABCL.
I store these both on the java object that calls the ABCL function.
Then multiple times I call <function>.execute() and catch the result.
Could I inadvertently be creating a lot of LispThreads, causing my system to eventually slow down and lock up?
Thanks! r
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 25 Nov 2014, at 23:41, Robert Goldman rpgoldman@sift.net wrote:
At the expense of following up on my own thread.....
I have Java code that is calling Lisp according to some of the examples I have read.
I make a single Interpreter object, then I look up a function as defined in ABCL.
I store these both on the java object that calls the ABCL function.
Then multiple times I call <function>.execute() and catch the result.
Could I inadvertently be creating a lot of LispThreads, causing my system to eventually slow down and lock up?
Every call to Function.execute() will run in the invoking thread, so unless the invoked call path explicitly spawns a new thread, there should only be as many threads present as you are invoking. LispThread is essentially a wrapper around a JVM thread that maintains a multi-threaded consistent view of the singleton Lisp environment as that JVM thread executes Lisp code.
As for “catch the result”: do you just mean act on the return value, or are you using a Java catch clause?
Any chance you can put the source up publicly for me to have a shot at running it?
Did you understand the RMI thing instead? My wild guess is that you're running your program in a container of some sort (e.g. an application server), or using a framework like Spring that allows to publish services via RMI. Then you might not find any mention of RMI in PRISM's sources.
On Wed, Nov 26, 2014 at 9:16 AM, Mark Evenson evenson@panix.com wrote:
On 25 Nov 2014, at 23:41, Robert Goldman rpgoldman@sift.net wrote:
At the expense of following up on my own thread.....
I have Java code that is calling Lisp according to some of the examples I have read.
I make a single Interpreter object, then I look up a function as defined
in
ABCL.
I store these both on the java object that calls the ABCL function.
Then multiple times I call <function>.execute() and catch the result.
Could I inadvertently be creating a lot of LispThreads, causing my system to eventually slow down and lock up?
Every call to Function.execute() will run in the invoking thread, so unless the invoked call path explicitly spawns a new thread, there should only be as many threads present as you are invoking. LispThread is essentially a wrapper around a JVM thread that maintains a multi-threaded consistent view of the singleton Lisp environment as that JVM thread executes Lisp code.
As for “catch the result”: do you just mean act on the return value, or are you using a Java catch clause?
Any chance you can put the source up publicly for me to have a shot at running it?
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Alessio Stalla wrote:
Did you understand the RMI thing instead? My wild guess is that you're running your program in a container of some sort (e.g. an application server), or using a framework like Spring that allows to publish services via RMI. Then you might not find any mention of RMI in PRISM's sources.
Thanks for your suggestion. I'm not using any sort of container, and PRISM isn't either (to the best of my knowledge -- it's a very big system). I think Mark is probably right and it's the Oracle/Sun jvisualvm profiling stuff that's somehow causing this, but I can't tell.
I'm going to see if I can grok Eclipse well enough to use that to profile: I know my code (heuristic search code) is bogging, probably choking on memory or somehow thrashing. Unfortunately, the jvisualvm just shows all these RMI threads as hot spots, making this a kind of Heisenbug. :-/
On Wed, Nov 26, 2014 at 9:16 AM, Mark Evenson <evenson@panix.com mailto:evenson@panix.com> wrote:
> On 25 Nov 2014, at 23:41, Robert Goldman <rpgoldman@sift.net <mailto:rpgoldman@sift.net>> wrote: > > At the expense of following up on my own thread..... > > I have Java code that is calling Lisp according to some of the examples > I have read. > > I make a single Interpreter object, then I look up a function as defined in > ABCL. > > I store these both on the java object that calls the ABCL function. > > Then multiple times I call <function>.execute() and catch the result. > > Could I inadvertently be creating a lot of LispThreads, causing my system > to eventually slow down and lock up? Every call to Function.execute() will run in the invoking thread, so unless the invoked call path explicitly spawns a new thread, there should only be as many threads present as you are invoking. LispThread is essentially a wrapper around a JVM thread that maintains a multi-threaded consistent view of the singleton Lisp environment as that JVM thread executes Lisp code. As for “catch the result”: do you just mean act on the return value, or are you using a Java catch clause? Any chance you can put the source up publicly for me to have a shot at running it? -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." _______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net <mailto:Armedbear-devel@common-lisp.net> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Mark Evenson wrote:
On 25 Nov 2014, at 23:41, Robert Goldman rpgoldman@sift.net wrote:
At the expense of following up on my own thread.....
I have Java code that is calling Lisp according to some of the examples I have read.
I make a single Interpreter object, then I look up a function as defined in ABCL.
I store these both on the java object that calls the ABCL function.
Then multiple times I call <function>.execute() and catch the result.
Could I inadvertently be creating a lot of LispThreads, causing my system to eventually slow down and lock up?
Every call to Function.execute() will run in the invoking thread, so unless the invoked call path explicitly spawns a new thread, there should only be as many threads present as you are invoking. LispThread is essentially a wrapper around a JVM thread that maintains a multi-threaded consistent view of the singleton Lisp environment as that JVM thread executes Lisp code.
As for “catch the result”: do you just mean act on the return value, or are you using a Java catch clause?
I just mean take the return value and act on it.
Any chance you can put the source up publicly for me to have a shot at running it?
I probably could, but I don't know that you'd thank me. PRISM is already huge, and with an idiosyncratic build process. Then adding ABCL to the mix makes a real gonkulator.
I'll have a quick whack at using Eclipse to profile first, and will report back. If the oddity persists (and isn't just a weirdness of jvisualvm), I'll package up stuff so that you can see it.
thanks! r
On 11/28/14 21:24, Robert Goldman wrote:
Mark Evenson wrote:
[…]
Any chance you can put the source up publicly for me to have a shot at running it?
I probably could, but I don't know that you'd thank me. PRISM is already huge, and with an idiosyncratic build process. Then adding ABCL to the mix makes a real gonkulator.
I'll have a quick whack at using Eclipse to profile first, and will report back. If the oddity persists (and isn't just a weirdness of jvisualvm), I'll package up stuff so that you can see it.
I'm more of a Netbeans fan myself, but looking forward to the result of your efforts.
Mark Evenson wrote:
On 11/28/14 21:24, Robert Goldman wrote:
Mark Evenson wrote:
[…]
Any chance you can put the source up publicly for me to have a shot at running it?
I probably could, but I don't know that you'd thank me. PRISM is already huge, and with an idiosyncratic build process. Then adding ABCL to the mix makes a real gonkulator.
I'll have a quick whack at using Eclipse to profile first, and will report back. If the oddity persists (and isn't just a weirdness of jvisualvm), I'll package up stuff so that you can see it.
I'm more of a Netbeans fan myself, but looking forward to the result of your efforts.
I think this is a false alarm. Looks like the oddity comes from jvisualvm. Sorry about that. Looks like it was a Heisenbug.
I was debugging a search routine where I first wrote the heuristic class in ABCL, then hand-compiled to Java when it was working.
Bug was not ABCL, but rather seems to be in the underlying search routine.
Thanks everyone for the help. I'm a newcomer to the Java platform. ABCL helps with this, but I'm still prone to stupid errors.
R
On 02 Dec 2014, at 16:24, Robert Goldman rpgoldman@sift.net wrote:
[…]
I think this is a false alarm. Looks like the oddity comes from jvisualvm. Sorry about that. Looks like it was a Heisenbug.
I was debugging a search routine where I first wrote the heuristic class in ABCL, then hand-compiled to Java when it was working.
Bug was not ABCL, but rather seems to be in the underlying search routine.
Thanks everyone for the help. I'm a newcomer to the Java platform. ABCL helps with this, but I'm still prone to stupid errors.
I am glad to hear things are working out as I am (mostly) always happy to be a [rubber duck][1] for ABCL usage.
[1]: http://en.wikipedia.org/wiki/Rubber_duck_debugging
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Mark Evenson -
Robert Goldman