[vtkusers] java memory

[Mark Roden]

HI Sebastien,

Is that multithreaded code you've written freely available? I have the
same issue Jon's having, in that my multithreaded code is extremely
unstable.  I'm wondering if there's some implicit paradigm that I'm
just not following when using my code, or I don't understand
pipelining properly.  If I could see model code of a complicated,
multi-threaded app (rather than the simple example apps), I think that
would help me out greatly.  Especially if you set up some kind of
class hierarchy or design pattern to handle this memory issue.

Thanks,
Mark

On Mon, Apr 4, 2011 at 10:11 AM, Sebastien Jourdain
<sebastien.jourdain at kitware.com> wrote:
> Hi Mark
>
>>> With Qt you have to be very careful as well. The only difference is
>>> that you won't have to deal with in-between object to delete. But you
>>> will definitely have the multi-threading issue to manage when you
>>> delete vtk components.
>>>
>>
>> How so?  From what you're describing, in order to use the Java
>> wrapping, all vtk calls have to be synced.
>
> I did not said that. I've said that the garbage collector of VTK
> should not run if other threads are working/deleting VTK objects that
> are used by object that are getting deleted. That is the only thing
> that I said. If you know you are building disjoined pipeline, you will
> never run into issue, but once they get connected, you need to make
> sure those objects should be accessed by a single thread.
>
> I've wrote Java code that was highly multi-threaded without any issue.
> But once the Garbage collector is running you must insure that no
> other thread may run into some currency access of the objects
> involved. Java is exactly doing that with its garbage collector, all
> other threads get stopped while its gc is running.
>
>> I can't know which calls
>> are allocating memory and which aren't (ie, 'GetScalars' is allocating
>> memory, but there's no explicit use of 'new'), so any time I call a
>> VTK object in Java, I could be allocating memory.  So, if I do
>> anything with VTK not on the EDT, then I'll end up with instabilities
>> if the EDT invokes the garbage collection.  If I don't invoke garbage
>> collection explicitly, I get leaks, and those leaks will quickly eat
>> through my memory if I have a, say, 512x512x128 volume of shorts with
>> 8 same-size char masks on top of that.
>>
>> But, if I'm in Qt/C++, then won't the allocations and deletions of
>> individual objects be distinct from one another?  I mean, if I have an
>> autosave thread, and the user deletes a mask while autosave is
>> happening, those sets of memory would be distinct from one another in
>> C++, and I should be fine (at least as regards to this problem),
>> because I don't have a single global memory allocation/deletion
>> location, right?
>
> Right, (and no if not disjoined pipeline) you will be able to free
> subset of memory without any concurrency issue which is not the case
> with the Garbage collector that know all the VTK objects used by your
> system across all your threads.
>
> I've said no if not disjoined pipeline but in most case this
> concurrency might not be an issue although there is no guaranty on
> that.
>
>> Or is my understanding of how VTK memory works incorrect?
>
> I think it is pretty accurate. It really depend on what the user is
> doing and how the working time and GC time could be managed. That's
> precisely why there is not a single easy solution, except if all the
> VTK calls are done inside the EDT. But this is not what we want with
> today's hardware that has several core which are waiting idle.
>
> Seb
>