I am a newbie to Java and I have this app developed by someone else which is having some issues.
This Java app works well on windows xp 32 bit, but there is a delay while running on 64 bit windows 2008 R2 server. I have asked the customer to make sure that they are running the 32 bit version of JRE. I have checked the traces for the application and the application has an issue while calling a synchronized block always. This synchronized block adds the data into a queue from which it is picked up by some other process. I have checked the traces if some other process is using the block but it isn’t. The only confusing part is that the same app runs perfectly on windows xp 32 bit.
After googling I came to know that there are threading issues in win64
Help me with this.
This isn't exactly an answer, but it might be of some help and it's more than a comment:
Most likely your 64 bit machine has more cores than the 32 machine, making it more likely that two or more threads really will run at the same time and any synchronization problems that never, or rarely, arise on the 32 will quickly pop up on the 64. Also, newer machines tend to execute more instructions at once than older machines. Both types reorder them as they do so. (Also, compilers often reorder the code.) So the 64's are a bit worse to start with, and when you throw in the more extensive, real multithreading the problems multiply.
(This can work the other way: the many-core machines tend to run threads in a predictable order, where a single core machine can wait many minutes to run something you expected would be executed immediately.)
I've usually found the best way to fix bugs is to stare at the code and make sure everything is precisely right. (This works better if you know when something is precisely right.) Failing that, you need logging messages that only print out when they're useful (it's hard to sort through a billion of them). You seem to have no trouble reproducing your problems (which almost makes me think it may not be a multithreading problem at all), which should make it a bit easier to figure out.
Related
This might be a really stupid question, but I don't really find answers online (Not that I can understand at least), I only found some benchmarks results like these with specific benchmark software.
Let me give a bit of context: I am currently developing a java multithread program on a Ubuntu machine, I have a Windows 10 machine in the Office for test purposes, and the program is supposed to run in a Windows 7 machine connected to a production line.
I am not interested in Ubuntu performance in this case, as the customer wants to use it on a Windows machine. When I test the software on the Windows 10 machine, it just "feels like" it runs faster than on the Windows 7 PC, I must say that I don't have total access to the Windows 7 machine, so I can't take the time to test it, also, as far as I know, the machines have the exact same hardware components and run the same Java version (Always the last update of Java 8).
Does this make sense? Can updating windows from Windows 7 to Windows 10 make a Java program run better? (by optimizing threads maybe?). This questions is based on pure speculation and no actual data at all, so I am sorry if it makes no sense.
Thank you all for your patience.
Yes, the order of thread execution is not guaranteed by the JVM which can be influenced by the other processes handled by an OS.
YES OS will have effect on threads performance as the Java threads execute on the threads of the JVM and JVM indeed will be allocated threads from OS on to which it runs, As JVM can not interact with the processor's thread directly.
So the multi-threaded program's performance will be effected by underlying OS which allocates threads to the respective JVM.
A few months ago I created a Java application which calculates chess ratings. I only ever tested it on my computer, but the program worked as expected.
I only just found out that on certain operating systems, the program doesn't work as it should. I've included a picture of the incorrect output on Windows 7 whereas this is what I get on Windows 8. (The player's rating should decrease since he scored only 1.5/5 against lower rated opposition). It seems that the program does not allow the player's rating to decrease.
Can anyone point me in the right direction as to why the program is behaving differently between these two versions of Windows? I was unable to find any explanation here on SO or anywhere else.
I think the most plausible explanation is that the Windows 7 version has a different argument there in the field 2: 2068 whereas Windows 8 has 2048.
Firstly, here are a couple of things that will NOT be the cause.
Arithmetic does not behave differently between Java on Windows 7 and 8. If you are running the same (single-threaded) algorithm with the same inputs, then the outputs should be the same.
Arithmetic does not change on 32-bit versus 64-bit JVMs.
So what could it be? Assuming that it is the same JAR, then it is likely that the algorithm doesn't change. So here are a couple of possibilities.
It could be a result of different inputs. Without looking at the algorithm, we can't exclude the possibility that there is something about it that makes it sensitive to the inputs in an unexpected way.
If there was a race condition in your code, you could find that that some aspect of your program doesn't work properly on some Java platforms ... due to differences in CPU speed, memory architecture and / or thread scheduling.
That's about as precise an answer as you could possibly get ... without looking at your code. So I think you are going to have to debug this yourself.
Get access to some Windows 7 machine that exhibits the problem.
Run the application with a debugger attached to see if the problem recurs under those conditions. If it does, then debug in the normal way to figure out why the algorithm is not working.
If attaching a debugger (and setting breakpoints) changes the way the program behaves (i.e. it makes the problem "go away") then you have evidence that points to a race condition of some kind.
For future Googlers, the problem wasn't with Java; it was a problem with newlines in a text file from which my program was reading data. For some reason, the "\n" character separating values in my text file was not showing up in Windows 7 but worked fine in Windows 8. Very strange but glad that it's fixed!
I have tried three IDEs, all of which I'm fairly sure require Java to run, and all of them start up very very slow (30 seconds to 1 minute) on the first launch of the day. After that, they all start up lightening fast.
The three programs are: Aptana Studio 3, Eclipse, and PHP Webstorm.
Based on upon my web searches, I have modified the AptanaStudio3.ini using some of the suggestions on how to speed it up and they all work ... for every start up after the first launch, that is, but the first launch of the day remains painfully and inexplicably slow.
I have searched SO and I did not see any questions speaking to this issue. If anyone finds an answer here, thank you very much but I could not.
My only conclusion is that this issue is related to how Java runs on Windows 8 since all three software programs are adversely affected. Is this a known bug in Java on Windows 8? I have no idea what to think but I would be greatly appreciative if someone can offer help.
OBSERVATION: from my testing, it seems that if I start up my laptop and then launch Eclipse or Aptana within the first say the first 10 minutes of booting, it launches quicker (still slow but not as bad) then if I were to wait for about an hour and then launch my IDE. Not sure what this indicates.
Thanks
Though you can tune the Eclipse (or Aptana) .ini file and do things like disable class verification and boot using the JVM DLL, this has more to do with OS and hardware disk caching than the JVM. Boot each of the IDEs from a Ramdisk and you'll see that they boot equally as quickly from RAM the first time as they do from 'disk' the second time.
Source: I've spent a lot of time trying to solve this problem already. :)
It might be worth checking your antivirus scanner behaviour - I have precisely this problem.
In spite of SSD & reasonably quick i5 on win8 ultimate, the first boot time for eclipse is measured in many minutes (can be over 10), with subsequent restarts being done in a matter of tens of seconds. The whole PC can do a full restart in about half a minute, so its unlikely to be a raw I/O issue.
From looking at the cpu hogs & digging from there, it appears that the a/v (macafee) is doing an on-access scan for all the eclipse components & plugins after every boot & I suspect this is where much of the time is being taken.
I'll post an update when I've persauded someone to exclude eclipse & jvm from the on-access scan...
Since Aptana Studio is based upon Eclipse there is no big difference to be expected.
This is not a known Bug for Java on Windows 8, since I experienced it at least already in Windows 7. AFAIK it has to do with starting the JVM for the first time.
Of course you could throw a lot of memory at it or tweak the .ini of the IDE. The JVM-startupprocess wouldn't really be affected and it would still be slow. What is neglectable for a server is a problem on the desktop. For details take a look at http://en.wikipedia.org/wiki/Java_performance#Startup%5Ftime
I have some issues with my PC and don't know what else to check or look for.
If the tags or description are off, feel free to edit/comment.
Basically the question is: Do you know of any tool that I could run during reproduction of the test, which logs frequently and might provide a hint on what's going on?
If anyone already has a clue of what could cause the problem, that would be great as well.
So here's the problem:
I have a running JBoss 4.2.3.GA server application which provides some EJBs with remote interfaces. Those EJBs write or read stuff to/from the database but that doesn't seem to matter since I also had methods that just did a System.out.println(...) and nothing more.
Now I run a test client from the console which basically just "remotely" calls one of those EJB methods in a loop (to take some timings etc.).
So far nothing too unorthodox should be done, it's basically just a bunch of remote EJB calls.
However, during the execution of the loop the computer freezes completely (keyboard doesn't respond as well, e.g. num-lock key) - the only thing that changes is the blinking cursor. :)
Unfortunately I didn't manage to find a reason for this and since I often do my tests from eclipse I'd like to not have that happen too often (workspace crashes etc.)
Here's what I tried so far:
Numerous hardware tests including Lenovo PC Doctor (it's a Lenovo PC) - all succeeded, so i seems like there's no hardware problem
Use different JDK versions: 1.5.0, 1.6.0, 1.7.0 - all crashed
JRockit JVM (Java 6) - crashed as well
make Java cause 100% CPU load (10 thread running constantly on 4 cores) - succeeded/no error
allocate as much memory as the JVM would allow me - succeeded
run the tests on other computers - succeeded, except one that has the same hardware and similar software setup
Windows logs don't provide a hint (except "system was not shut down correctly" ... well that helps :) )
After all these tests I assume it might be a problem with the system configuration (drivers etc.) but I don't know how to track that (and I can't just use brute force due to the massive time requirements).
So, did anyone experience similar problems?
Do you know of any tool that I might use to log what the system does and preferably get a log right before the crash?
Thanks in advance,
Thomas
I asked this question a few weeks ago, but I'm still having the problem and I have some new hints. The original question is here:
Java Random Slowdowns on Mac OS
Basically, I have a java application that splits a job into independent pieces and runs them in separate threads. The threads have no synchronization or shared memory items. The only resources they do share are data files on the hard disk, with each thread having an open file channel.
Most of the time it runs very fast, but occasionally it will run very slow for no apparent reason. If I attach a CPU profiler to it, then it will start running quickly again. If I take a CPU snapshot, it says its spending most of its time in "self time" in a function that doesn't do anything except check a few (unshared unsynchronized) booleans. I don't know how this could be accurate because 1, it makes no sense, and 2, attaching the profiler seems to knock the threads out of whatever mode they're in and fix the problem. Also, regardless of whether it runs fast or slow, it always finishes and gives the same output, and it never dips in total cpu usage (in this case ~1500%), implying that the threads aren't getting blocked.
I have tried different garbage collectors, different sizings the parts of the memory space, writing data output to non-raid drives, and putting all data output in threads separate the main worker threads.
Does anyone have any idea what kind of problem this could be? Could it be the operating system (OS X 10.6.2) ? I have not been able to duplicate it on a windows machine, but I don't have one with a similar hardware configuration.
It's probably a bit late to reply, but I could observe similar slowdowns using Random in Threads, related to a volatile variable used within java.util.Random - see How can assigning a variable result in a serious performance drop while the execution order is (nearly) untouched? for details. If the answer I got is correct (and it sounds pretty reasonable to me), the slowdown might be related to the in-memory-addresses of the volatile variables used within Random (Have a look at the answer of user 'irreputable' to my question, which explains the problem much better than I do here).
In case you're creating the Random-instances within the run-method of your Threads, you could simply try to turn them into object-variables and initialize them within the constructor of your Thread: This would most likely ensure that the volatile fields of your Random instances will end up in 'different areas' in RAM, which do not have to get synchronized between the processor cores.
How do you know it's running slow? How do you know that it runs quicker when CPU profiler is active? If you do the entire run under the profiler does it ever run slow? If you restrict the number of threads to one does it ever run slow?
Actually this is an interesting problem, im curious to know whats the problem.
First, in your previous question, you are saying you split the job between "multiple" processors. Are they physically multiple, like in multiple machines? or a multi core CPU?
Second, im not sure if Snow Leopard has something to do with it, but we know that SL introduced few new features in term of multi-processor machines. So there might be some problem with the VM on the new OS. Try to use another Java version, i know SL uses Java 6 by default. Try to use Java 5.
Third, did you try to make the Thread pool a little smaller, you are talking about 100 threads running at same time. Try to make them 20 or 40 for example. See if it makes difference.
Finally, i would be interested in seeing how you implemented the multi-threading solution. Small parts of the code will be good