Home > Archive > Java Help > August 2005 > Avoiding copying an array in JNI
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Avoiding copying an array in JNI
|
|
| Lin DeNoyer 2005-08-21, 6:58 pm |
| 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
| |
| Patricia Shanahan 2005-08-21, 6:58 pm |
| 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
| |
| Lin DeNoyer 2005-08-21, 6:58 pm |
| In article <FV%Ne.9794$RS.3673@newsread3.news.pas.earthlink.net>, pats@acm.org
says...
>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
Thank you for that suggestion. I am a rank amateur at all this, and so I will
now go away and learn about threads.
Lin
|
|
|
|
|