| Key: |
MACMULTITOUCH-3
|
| Type: |
Bug
|
| Status: |
Closed
|
| Resolution: |
Won't Fix
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
raner
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Time Tracking:
|
|
Original Estimate:
|
1 hour
|
|
|
Remaining Estimate:
|
1 hour
|
|
|
Time Spent:
|
Not Specified
|
|
|
|
|
Environment:
|
Mac OS X 10.5.8, JDK 1.5.0_16
Mac OS X 10.5.8, JDK 1.5.0_16
|
|
The calls to AttachCurrentThread and DetachCurrentThread cause a large number of threads being created and destroyed at a rapid rate. This is an expensive and resource-intensive way of performing callbacks on Mac OS X, and causes a significant increase of the CPU load while the native code is active.
When run in debug mode from Eclipse, the Eclipse UI can hardly keep up with displaying all the threads that are being created and destroyed as soon as activity from the touchpad is recorded. Also during touchpad movements, the CPU load increases to about 50% of the full capacity of my dual-core system.
Alternative implementations could be:
- moving the call to DetachCurrentThread somewhere else (maybe to ..._deregisterListener?), so that subsequent class to AttachCurrentThread effectively become no-ops
- setting aside a specific Java thread that receives the callbacks and statically storing the JNIEnv for that thread
|
|
Description
|
The calls to AttachCurrentThread and DetachCurrentThread cause a large number of threads being created and destroyed at a rapid rate. This is an expensive and resource-intensive way of performing callbacks on Mac OS X, and causes a significant increase of the CPU load while the native code is active.
When run in debug mode from Eclipse, the Eclipse UI can hardly keep up with displaying all the threads that are being created and destroyed as soon as activity from the touchpad is recorded. Also during touchpad movements, the CPU load increases to about 50% of the full capacity of my dual-core system.
Alternative implementations could be:
- moving the call to DetachCurrentThread somewhere else (maybe to ..._deregisterListener?), so that subsequent class to AttachCurrentThread effectively become no-ops
- setting aside a specific Java thread that receives the callbacks and statically storing the JNIEnv for that thread
|
Show » |
Sort Order:
|
AttachCurrentThread/DetachCurrentThread causes high CPU load on Mac OS X
AFAIK because MacOSX is calling the C 'mtcallback' function from its 'own thread' the need to attached (and detach) that native OS thread to the JVM can't be avoided in the callback; all docs and examples of C-> Java callbacks I have seen do this. I am assuming that the threads you see being created are these OS threads, but I have not confirmed this myself.
An alternative approach to invoking Java from C in 'mtcallback' via the JNI API might be to instead communicate via a socket.
Happy to hear your thoughts on the above.