I made a raycasting engine and it has some slowdowns. I never had to do profiling before, only step by step debug. I used JProfiler and from what i can understand the problem seem to be waiting/blocked threads. I dont know why this happens. If anyone could take a look at the code and give me some hints i would really appreciate. The code is in english but some comments are still in french (translation in progress). I've tried to make the code as explicit as possible but if there is something you are unsure of ill explain. Im not very familiar with how threads work but i believe everything related to them is in the "control" package. There are a lot of classes so instead of posting the code here ive put everything on github:
https://github.com/Thormind/Raycasting-engine.git
Here is an image of the threads profiling. Outside of that everything else (memory, cpu) seems fine.
Go to the call tree view, record CPU data and set the thread status selector to "Blocking", than you see in which call stacks the blocking occurs.
Detailed analysis of blocking situations is available in the "Monitors & Locks" view section.
Related
I have copy-pasted together MainActivity class for a simple Android application, which uses BluetoothAdapter, TextToSpeech, and also Runnable status checker, running periodically. For the latter, I have "implemented TextToSpeech.OnInitListener".
The code is probably too large to post here, so I will try to formulate the question in general form and then explain why.
How one is supposed to understand where "thread forks" happen in the Java code where everything looks like method invocations? Are there any conventions (for Android libraries specifically, of maybe it's Java-wide) to distinguish simple call from a call, which forks it's own thread? Or is the RTFM the only way to find where forking is happening?
And the actual problem is that Bluetooth LE scanning (?) sometimes duplicates, producing double (or triple, sometimes more) log entries one after another. I guess, I have a mistake somewhere in onStop, onResume, onDestroy, etc hooks (though I was trying to follow state transitions as on the diagram in the docs), but it is hard to find out why some threads/tasks survive and duplicate.
I am "programming" in Java only occasionally, so I have very little idea how concurrency could be debugged. But may be folks with experience can share general hints/advices/guidelines, useful in much more cases than mine.
Recently, my attention was drawn by some of the Recycle Bin applications on the play store, and I thought it would be nice to put some of those methods into practice to make other useful applications for people out there, but it seems not quite simple.
According to this Stackoverflow post, it is impossible!
But if you look closely, applications like GT Trash and Dumpster are working like a charm without any root permissions!
What we exactly want to achieve is overriding the android system File.delete() so the deleted file is moved to our desire location before the user permanently delete it. We tried the Andrey Petrov post witch shows a solution for a similar situation but it is not providing enough details.
We appreciate any help from those who where successful finding out the magic behind these apps.
First of all, sorry for the little broad question. Just want to get some general idea of direction.
Right now I have a big project almost completed. It has over 5 classes and under complicated designs and initially non-GUI, and I want to add a GUI interface to it. the GUI was supposed to fetch information when it runs and displays the running information. I reads about Swings and SwingWorker but it seems not plausible to put entire original program under Background thread. Right now I'm think putting GUI as a separated class but I don't know what's the best way to make connections. Any help is appreciated.
You can't simply "put" a GUI on any existing program, but you can possibly give a program a GUI user interface if the program was well constructed in a very modular fashion such that its UI is well separated from its logic code, for example if it was constructed in an M-V-C (model-view-control) fasion.
As always, the devil is in the details, none of which I can discuss at the moment given the limited information that we possess about your current project and needs. If you need further help, you will need to give us more information and code.
This question already has answers here:
Run external program from Java, read output, allow interruption
(5 answers)
Closed 9 years ago.
I have been trying to work on this issue I had by searching thoroughly so as to find out what to do. However, none of the results I've found (at least until now) had suited my requests.
The fact is, I've got an executable JAR I've done. This jar starts an .EXE.
Now, the thing is, the EXE will keep on running the whole time, and I want to get whatever has been written in the console so as to write it on a JTextBox as soon as that is read.
Would you mind giving me an example of that? I would like to do it on my own, but my head doesn't seem to find out how.
Thank you very much.
EDIT: what I'm trying to do is a GUI for a gaming server
EDIT 2: for those saying its duplicate... wish it was... tried what the others explained but didn't work, so that's the reason I asked here..
EDIT 3: as I have been looking forward to find what the problem was, I will tell you that what I've done does not have any errors. However, I guess, it may be caused to the fact that the server (written in C++/C) may not output in a 'normal' way. May that be the reason? I hope so. Otherwise, I might be doing something really wrong.
Please notice I use InputStream in order to be able to read.. but well.
Basically, you need to start by running the process in some kind of background thread so there is no risk that it will block the Event Dispatching Thread.
Then you need to read the processes InputStream. As the input is read, you need to push these updates to the UI in such away so as not to violate the single thread rules of Swing. That is, you should ensure that all updates are made within the context of the Event Dispatching Thread.
Check out Concurrency in Swing for more details.
In this, I would recommend using something like SwingWorker. It allows you to monitor the process from a background thread, but has easy to use functionality to sync the updates back to the EDT.
Take a look at Printing a Java InputStream from a Process for an example
I'm working with a legacy Java app that is new to me so one way to figure out how it works and find things easier, I have thought would be to be able to get the full stack trace after I perform actions, so as to be able to see which classes are being used based on a particular UI action. I had thought this was possible in the debugger but it seems that it only works if I insert a breakpoint and in this case part of the purpose of this is so that I don't have to know what's being called to be able to insert the breakpoint first (as this would help tell me that).
I apologize if this is a basic question, I have searched on this but I'm not finding the correct answer.
This doesn't directly answer your question, but maybe it will solve your problem better. Take a look at BTrace. It lets you instrument a running Java app and insert some basic code of your own. You could, for instance, have it write out entire method call chains to help you find your way through the app. It's somewhat similar to AspectJ, but with an entirely different purpose and requiring no change in the project source:
"BTrace is a safe, dynamic tracing tool for Java. BTrace works by dynamically (bytecode) instrumenting classes of a running Java program. BTrace inserts tracing actions into the classes of a running Java program and hotswaps the traced program classes."
A few suggestions:
Some profilers will allow you to walk from any particular method up (and sometimes down) to see what's calling and being called. I've found this surprising informative about flow, even in apps I thought I knew well.
For understanding the mainline flow, I don't think there's a better substitute for working interactively with a debugger. It will lead you into learning other important things. Not what you wanted to hear, I know. This presumes that you can rapidly restart the app when you miss a key off-ramp.
Reverse-designing large legacy apps is the one place where I use UML fairly regularly. There's too much to keep in my head to form a good big picture. If you have a UML tool that will do reverse-engineering, load it up with the app, then probably prune down hard on the classes you don't care about, because they are trivial or obvious. Arrange the diagrams in a way that helps you understand. I've used Together, Magic Draw, and Visual Paradigm in this way. Together worked the best - but it was a decade ago.
When you are in the debugger perspective, you will see a view showing the launched processes. In that view you can tell it to pause all threads of a process. Once stopped, you will be able to browse through threads to see what they are all doing. To try to catch what a particular action is doing, you would have to start the action and then quickly pause all threads.
You could always run the application with the VM arg of -verbose:class. You could then watch the console output and see what classes the VM is loading when you perform a particular action. This could possibly give you a starting place for where to place breakpoints. This won't always work depending on the scenario, but may be helpful.
Another trick you can use is to figure what classes you know that have to be involved in the code path you are trying to trap. For instance, you mentioned that it's a Java EE web app and therefore the action is likely some kind of a servlet interaction (at some level). I don't have the API in front of me, but you can place a breakpoint on the method in the response object where the output stream is retrieved. Once that breaks, you will know the code that's trying to service the request.
You can always see where a method is called by clicking "Open Call Hierarchy" from eclipse (left click on the selected method or CTRL+ALT+H ). Also, you always can inspect where a method/class is defined by clicking "Open Declaration" (left click on the selected method/class or F3).