[vtkusers] java memory

[Sebastien Jourdain]

Hi Mark,

unfortunately that precise code is not freely available and I'm quite
busy to build Java code sample that illustrate a way of dealing with
concurrency and memory management. But it make me think that I should
try to write a source article around that with code. The only thing
for me is to find the time now... ;-)

I'll see what I can do. (but I have to deal with a paper deadline)

Seb

On Mon, Apr 4, 2011 at 1:26 PM, Mark Roden <mmroden at gmail.com> wrote:
> 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
>>
>