 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Lin DeNoyer
Guest
|
 Posted: Sun Aug 21, 2005 1:57 pm Post subject: Avoiding copying an array in JNI |
 |
|
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
|
|
| Back to top |
|
 |
Patricia Shanahan
Guest
|
| Posted: Sun Aug 21, 2005 2:08 pm Post subject: Re: Avoiding copying an array in JNI |
|
|
Lin DeNoyer wrote:
| Quote: | 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
|
|
| Back to top |
|
|
Lin DeNoyer
Guest
|
| Posted: Sun Aug 21, 2005 3:33 pm Post subject: Re: Avoiding copying an array in JNI |
|
|
In article <FV%Ne.9794$RS.3673 (AT) newsread3 (DOT) news.pas.earthlink.net>, [email]pats (AT) acm (DOT) org[/email]
says...
| Quote: | 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
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
