Re: Avoiding copying an array in JNI

Lin DeNoyer wrote:
I am building an interface to a C dll (also compiled as an so library in linux). This is my problem:

The operation performed by the dll/so file takes about 2 minutes to execute. In the past, when accessing this dll from C/C++/Matlab etc. code, I have always
(a) allocated the memory block needed for the operations (1-100 MBytes),
(b) put the call to the dll in a loop, telling it exactly what time slice it is allowed to have for processing - asking it to return after that time slice, so as not to lock up the user interface of the calling program. (c) The memory block keeps track of where it is in the processing - and so it essentially runs in to background until done.
(d) The calling program keeps calling the dll until the dll says it is 100% done.
(e) At 100% done, the result is removed from the memory block, and the memory block freed.

The problem I am running into with JNI is that I am supposed to make a copy of every array sent into the dll - else disaster - or so the book says. But this copy (twice - once on the way into the dll and again on the way out) - with accompanying allocation of a new (big) block of memory - makes the processing impossible. REALLY IMPOSSIBLE! We are talking about waiting hours - maybe even overnight - for something that can be done in a few minutes.

So here is my question: How can I allocate the big memory block in a way that will avoid it being moved, so that I don't have to do the standard copy for each JNI call into the dll?

LKD



Is there any possibility of running the computation in a separate
thread, at lower priority than the event handling thread, and any
threads the event handler depends on?

That way, preserving the computation's state when the GUI needs the
processor would be the operating system's problem, not yours. It would
be done much more efficiently, by leaving the data in memory.

Moreover, the OS would only run the GUI when it has something to do,
such as handling a user action. The computation would not be interrupted
unnecessarily just in case the GUI needs to do something.

Patricia
.

Relevant Pages

  • Avoiding copying an array in JNI
    ... put the call to the dll in a loop, telling it exactly what time slice it is ... as not to lock up the user interface of the calling program. ... The memory block keeps track of where it is in the processing - and so it ... The calling program keeps calling the dll until the dll says it is 100% ...
    (comp.lang.java.help)
  • Re: Using TLSAlloc to read data into a DLL
    ... store that data in a memory block that is untouched until the DLL is ... TLS stands for thread-local storage, and is used to store per-thread ... you don't appear to need TLS. ...
    (microsoft.public.vc.language)
  • DrawImage out-of-memory caused by OpenFileDialog?
    ... out-of-memory errors are intermittent in DrawImage and various other graphics classes. ... I'd guess that a related Win32 DLL has been rebased to a location which is unlikely to conflict with other DLLs, saving precious CPU time by avoiding relocations when the DLL is loaded, and preventing images from being operated on after that. ... A tentative workaround seems to be to allocate enough memory in one block to start with, then let the OpenFileDialog DLL get loaded, then free the memory block and hope that it will be reusable for graphics where needed. ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: Call unmanaged DLL (VS7.0) from VS6.0
    ... Also, if you read about how COM works, you will see why pure interfaces are compiler-independent. ... However, the classes that are used inside this Dll are pretty much COM-like, which means that all calls are made via virtual methods. ... Maybe I can ask the third party for the right size of the object, and use placement new with a memory block large enough. ... Besides, the used STL classes won't have increased in size for more than let's say factor two, so it should be safe enough to allocate a memory block twice the size of what VS6.0 would use. ...
    (microsoft.public.vc.language)
  • Re: "new byte[132]" alignment on 16 bytes
    ... Byte arrays are allocated on the managed heap and this ... And pass this Buffer to a unmanaged C++ function that executes Assembler SSE ... The SSE instructon set assumes that the starting physical memory block is ...
    (microsoft.public.dotnet.languages.csharp)
Loading