Antwort: Re: [MAPSERVER-USERS] thread safety

[umn-ms at hydrotec.de]

Hi Rich

I saw, that you made a thread on java/threading/memory-leaks "on your 
own".
Although I spend some time on the same issues in the last years I can 
hardly 
give new input.

Don't know wether you saw these:
1. http://www.nabble.com/forum/ViewPost.jtp?post=5707320&framed=y 
   We worked around threading-problems with Java-synchronizing.
   By doing so, the application becomes stable in stress-tests, but 
   looses the ability to use many CPUs.
   (On the other hand: 
http://www.nabble.com/forum/ViewPost.jtp?post=15410399&framed=y
    shows, that the mapserver-locks prevent using many CPU's in any case.)
2. You cited the post about the delete-problem. 
   (http://www.nabble.com/forum/ViewPost.jtp?post=1548675&framed=y)
   This issue was adressed in Mapserver 5.0:
   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-24
   So the garbage-collector shouldn't crash the jvm any more.
   (My personal opinion is to use delete anyway, since freeing C-memory
    in the garbage-collector-thread sounds dangerous to me. But as far
    as I know, there are no more documented problems.)
3. I also spent time in watching memory-leaks inside Mapscript/java and 
abandoned 
   valgrind-approach. Seemed to be to complex, since much memory-handling 
of the JVM is 
   documented. My approaches:
   Variant 1: In cases, where I had a guess what to look for, I wrote a 
small C-program, which 
     called the suspect functions and analysed the behaviour of this small 
program.
     (Successfully used in http://trac.osgeo.org/mapserver/ticket/1662.) 
     Didn't use valgrind but memwatch (
http://www.linkdata.se/sourcecode.html). But this
     is purely a matter of taste.
     Disadvantage: Doesn't help, if you have no guess.
   Variant 2: Watching memory-usage using top from outside during 
stress-tests. With
     some awk-sed-batch-unix-stuff it resulted in pictures like this:
     
http://trac.osgeo.org/mapserver/attachment/ticket/1662/before-after.zip
     Disadvantage: Black box

Sorry. That's hardly helpfull. But I'm interested in your progress.
Benedikt Rothe

mapserver-users-bounces at lists.osgeo.org schrieb am 20.02.2008 02:26:04:

> 
> Any advice about tracking down memory leaks that might exist in java
> mapscript?
> 
> For the context of why I'm trying to do this, see the following thread:
> 
>   http://www.nabble.com/thread-safety-to15514019.html
> 
> I installed the debian sarge backport of valgrind 
(valgrind-3.2.0-Debian),
> and
> tried invoking java prefaced with:
> 
>   valgrind --leak-check=full --smc-check=all -v
> 
> No leaks were reported, but I don't think it really checked where I 
wanted
> it
> to check.  libmapscript.so is loaded with the following:
> 
>          System.loadLibrary("mapscript");
> 
> And from the output it doesn't look like valgrind is actually 
instrumenting
> that library, and I can't figure out how to tell it to explicitly 
instrument
> a
> dynamically loaded library.
> 
> Yet the valgrind FAQ:
> 
>   http://valgrind.org/docs/manual/faq.html#faq.java
> 
> does indicate that this might at least be possible:
> 
> --- begin ---
> in theory Valgrind can run any Java program just fine, even those that 
use
> JNI and are partially implemented in other languages like C and C++.  In
> practice, Java implementations tend to do nasty things that most 
programs
> do not, and Valgrind sometimes falls over these corner cases. 
> --- end ---
> 
> Sorry if this is more appropriately a valgrind question and not a 
mapserver
> question, but I saw valgrind mentioned in a few places:
> 
>   HISTORY.TXT
>   http://trac.osgeo.org/mapserver/ticket/2412
> 
> so I thought that maybe someone here might have experience as it relates 
to
> this specific case.
> 
> - Rich
> 
> -- 
> View this message in context: http://www.nabble.com/detecting-
> memory-leaks-in-java-mapscript-tp15580371p15580371.html
> Sent from the Mapserver - User mailing list archive at Nabble.com.
> 
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20080220/49c43517/attachment.htm>