[vtkusers] java memory

[Sebastien Jourdain]

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