[mapguide-users] Memory Leak in Java

[Riccardo Pucci]

Hi Benoit
Your hint is helpful: I tried with a smaller buffer (1024) and the leak is
greatly reduced so the dimension of buffer is somehow involved. Still the
leak remain. There is some memory allocated by c++ that is not freed. That
memory is off of the java heap, so it cannot be directly managed by garbage
collection.
Riccardo

Il giorno mer 18 dic 2019 alle ore 21:50 Benoit Begin <bbegin at geomapgis.ca>
ha scritto:

> Hi,
>
> I'm no Java expert, but I feel it could be a similar issue that you may
> face
> with .NET and Large Heap Objects. With the size of the byte array you are
> creating, 1024x1024, you might be overruning the size of the level 1
> generation for the Garbage Collector and end up putting your data in a
> later
> generation that doesn't get collected very often.
>
> So when I do things in .NET with MgReaders that can get sizeable, I do set
> a
> hard cap at 4096 bytes being read per iterations and they don't end up on
> the LOH. Looking at your code, you potentially create 4 1MB large objects
> every round. So those likely end up somewhere in your memory stack that the
> JVM garbage collector doesn't clean up very quickly.
>
> I did some quick Google searches about it and it seems a fairly common
> topic
> when it comes to Java and object generation. I think it might be worth it
> to
> do a quick search to optimize on that front.
>
> Hopefully someone more knowledgeable about Java can chime in, but I feel it
> might be a worthwhile area to look into while waiting for a reply!
>
> Regards,
>
> Benoit
>
>
>
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html
> _______________________________________________
> mapguide-users mailing list
> mapguide-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapguide-users



-- 
Riccardo Pucci
Geoweb Italia S.r.l.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20191219/2ccf54a0/attachment.html>