[Armedbear-devel] ABCL and RMI

Robert Goldman rpgoldman at sift.net
Fri Nov 28 20:20:32 UTC 2014


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 at panix.com
> <mailto:evenson at panix.com>> wrote:
> 
> 
>     > On 25 Nov 2014, at 23:41, Robert Goldman <rpgoldman at sift.net
>     <mailto:rpgoldman at 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 at common-lisp.net <mailto:Armedbear-devel at common-lisp.net>
>     http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
> 
> 


-- 
Robert P. Goldman
Staff Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

319 1st Ave N., Suite 400
Minneapolis, MN 55401

Voice:    (612) 326-3934
Email:    rpgoldman at SIFT.net



More information about the armedbear-devel mailing list