I am aware that Hotspot JDK7 has both Java Mission Control and flight recording bundled with it. But, as per my application requirement, I am bound to use Hotspot JDK6. I could monitor the Hotspot6 JVM performance using JMC. But flight recording is disabled for Hotspot6 JVM. Is there any other tool equivalent to it for Hotspot6?
Nothing equivalent, but you can try jconsole or jvisualvm (in the bin directory).
Related
I built a game in j2me and I have memory leak because from time to time I get out of memory exception, now I want to spot where this leak is coming from and I heard you can do it with sun's wireless tool kit. Can someone explain me exactly what is this wireless tool kit, how I install it and how to use it in-order to find memory leaks ? Thanks in advance !
After you download wtk,Go to \bin\utilsw.exe.Under Utilities you will see "Memory monitor".Here you can graphically view app memory/RAM usage.
I do not know oracle sdk 3.4, but in wtk2 memory monitor was only partially useful for finding memory leaks, because it only shows how many (and which) objects are live, but not where they are referenced from. So it takes a review of corresponding piece of code.
Memory leaks are easier to find with a java profiler. You need to get one that suits you (I prefer YourKit, but it is commercial product with a trial period), modify emulator's command line in order to allow the profiler to connect (that should be covered by profiler's documentation, it is basically about adding -agentlib or -Xrun... option) to it, and do actual profiling (every profiler comes with a guide of how to do it).
We are looking into implementing an in-memory utility which can recover the system in case of disk/filesystem lockup. This utility has to detect the lockup and take corrective action like rebooting or just shutting down interface.
The server platform is Gentoo Linux 2.4
Any suggestions on - any existing utility or which scripting method will work best (expect, native C++)?
you'll want S.M.A.R.T. monitoring tools (smartmontools)
http://en.wikipedia.org/wiki/S.M.A.R.T.
Note that not all statistics correlate with impending drive failure, and sometimes (for some brands and models) you may need to pass in special flags or you will get garbage. See the wikipedia article for which attributes really indicate danger.
The command is smartctl. You may need to be sudo. smartctl --all will give a summary of all drives, spinning them up very briefly to check their health.
What type of errors are you looking for?
smartmontools and smartd which ship with most distros should be able to help you. They work at a low level with the disk.
SMART on Wikipedia
smartmontools
My Java program is in working order when i use it under Windows(Eclipse and Bluej). I compress it to a Jar and send it to my red hat and bang. nothing works. It breaks on the weirdest things, such as text field set text will not show, JPasswordfield just disappeared, Java AWT ROBOT dies too... the list goes on, first i thought it must be my Linux JRE is out of date, but i installed latest JRE then the JDK with no improvement at all. I have a feeling that i miss understood the Java cross plat ability. I also tried to remove all of my functions and guts to see what is breaking but it seems every second thing is breaking, other than the some of the major GUI components and most of the back end stuff. basically any thing that uses some thing fancy will blowup in my face, such as making a text field in to a password field...
This is my first time posting ;) please be nice to the newbie!
Thanks!!!
SOLVED!!!
Yay. Problem solved!!! It was because my Java path isn't set, so my GCC/GCJ jumped in instead of my oracle java, even tho i used java -jar xxx.jar. so I put in the java directory path from of my java -jar xxx.jar and worked like a charm. unless you set the path, you have have to do this manually
/usr/java/jdk1.6.0_21/jre/bin/java -jar xxxxx.jar
java -version to check if your real java is running or if it s still GCJ
Linux users often run java programs with gcj instead of java. Check that you use a correct executable.
Check that you are using Sun's (Oracle's) JRE on your Linux machine and not some 3rd party Java implementation such as gcj or the likes.
In my experience, Java applications are quite portable as long as you stick to the same JVM/runtime vendor on every target SO, but Java implementations from different vendors might behave different from each other.
Yes. The class and jar formats are intentionally crossplatform.
Are you absolutely certain that your jar file was copied correctly to your Linux machine? If you used ftp, it is crucial to use binary instead of ascii transfer.
Is your application dependent upon any external libraries that you also need to have available on your Linux machine?
Java says: "Write once, run anywhere".
Swing should be fully portable. Try using the metal look and feel, which is widely supported. I have my doubts about java.awt.Robot though and wouldn't be suprised if this was the source of your problems.
Are you using KDE? Which theme? I had an issue yesterday that the theme "Cleanlooks" has a lot of bugs rendering widgets. Try "Oxygen".
If you can, try the code on a different Linux box (maybe it has a hardware defect). Run "memtest" (should be an option in the boot loader or on your rescue CD).
I have a Swing app which I distributed via Java Web Start that I haven't updated since 2004 which I know still works fine on Mac OS X, Windows, and Linux. I ran it just the other day because somebody emailed me a question about it. It was originally written on Windows but has never shown any problems on other operating systems or even in much much later versions of Java.
The JVM presents a very level playing field across a wide variety of platforms and the Java API is well implemented to work the same and offer the same functionality. My bet is that you will find this problem is something entirely unrelated to your Java code. In addition to the suggestion to try your app on another machine running the same OS, be sure to try other people's Java apps running on the one which is giving problems. Try my own HotSheet: http://www.johnmunsch.com/projects/HotSheet/ or a game like Legerdemain: http://roguelikefiction.com/?page_id=6 to see if those will work.
On linux it might be crucial to use the Sun JDK/JRE and not the openjdk, which is an implementation of the official sun java jdk. So it could be that, though not sure at all.
Java is very transportable. Chances are your VM is different. Although the Open Source VMs are getting very good, I recommend trying with Sun's VM--I've never had a problem with it running any code.
Also, if you are using any libraries with machine language components, those will have to be different (I've noticed this with some graphics libraries that call through to the platform's 3d subsystem)
But Java itself WILL port easily to any system that has the same libraries and a good VM Very Well--I do it all the time and have been doing so for ten years and literally have never had a problem. This is running client/server systems where the clients and server were on different platforms, PC/Mac & Unix and even embedded systems--stuff just ports.
Now, applets running in different browsers, or visually trying to match fonts on machines that don't contain the same font--Nothing will help you there.
I need to produce an embedded ARM design that has requirements to do many things that embedded Linux would do. However the design is cost sensitive and does not need huge amounts of horse power. Mostly will be talking to serial interfaces. Ideally I would like to use one of the low end ARMs. What is the lowest configuration of an ARM that you have successfully used embedded Linux on.
Edit:
The application needs a file system on some kind of flash device and the ability to run applications for processing the data. Some of the applications might be written by others than myself. I also need to ability to load new applications or update old apps using the serial ports to accept the apps.
When I have looked at other embedded OSes they seem to be more of a real time threading solution than having the ability to run applications. I am open to what ever will get the job done.
I think you need to weigh your cost options here.
ARM + linux is an option but you will be paying a very high operating overhead for such a simple (from your description) set of features. You can't just look at the cost of the ARM chip but must also consider external RAM which will very likely be required as well as flash to get enough space available to run the kernel + apps.
NOTE: you may be able to avoid the external requirements with a very minimal kernel and simple apps combined with a uC with large internal resources.
A second option is a much simpler microcontroller with a light weight OS. This will cut your hardware costs on the CPU and you can likely run something like this without external RAM or flash (dependent on application RAM and program space requirement)
third option: I don't actually see anything in your requirements that demands any OS at all be used. Basic file systems are very simple, for instance there are even FAT drivers out there for 8 bit PIC's. Interfacing to an SD card only requires a SPI port and minimal external circuitry.
The application bit could be simple or complex. I've built systems around PIC18 microcontollers that run a web server and allow program updates via a simple upload screen, it just stores the new program into an EEPROM or flash, reboots into a bootloader and copies the new program into internal program memory. You could likely design a way to do this without the reboot via a cooperative multitasking type of architecture. Any way you go the programmers writing the apps are going to need to have knowledge of the architecture and access to libraries / driver you write. Your best bet to simplify this is to provide as simple an API as possible and to try to automate the build process for them.
The third option will be the "cheapest" in terms of hardware as there will be very little overhead in the processing of your applications allowing you to get away with minimal processing power and memory. It likely will require some more programming/software architecting on your part but won't require nearly the research you will need to undertake to get linux up and running in addition to learning to write the needed device drivers under a linux paradigm.
As always you have to include the software development costs in the build cost of the device. If you plan to build 10,000+ of these your likely better off keeping hardware costs down and putting more man power into designing a software solution that allows that hardware to meet the design goals. If your building 10 of them, your better off spending an extra $15-20 on hardware if it can cut down on your software development costs. For example an ARM with MMU with full linux kernel support and available device drivers.
I kind of feel that your selecting the worst of both worlds at the moment, your paying extra to get a uC you can run linux on but by doing so your also selecting a part that will likely be the most complex to get linux up and running on, especially having not worked with linux on embedded platforms before.
I've had success even on ARM7TDMI, so I don't think you're going to have any trouble. If you have a low-requirements system, you could use any kind of lightweight real-time executive and have a lot better experience than you would getting Linux to work.
I've used a TS-7200 for about five years to run a web server and mail server, using Debian GNU Linux. It is 200 MHz and has 32 MB of RAM, and is quite adequate for these tasks. It has serial port built in. It's based on a ARM920T.
This would be overkill for your job; I mention it so you have another data point.
For several years I've been using a gumstix to do prototyping and testing and I've had good results with it. I don't know if the processor they are using (Intel PXA255 on my board) is considered low-cost, but the entire Verdex line seems pretty cheap to me for an adaptable device.
ucLinux is designed specifically for resource constrained targets, but perhaps more importantly for targets without an MMU.
However you have to have a good reason to use Linux on such a system rather than a small real-time executive. Out-of-the-box networking, readily available drivers and protocol stacks for complex hardware and support for existing POSIX legacy or open source code are a few perhaps. However if you don't need that, Linux is still large, and you may be squandering resources for no real benefit. In most cases you will still need off-chip SDRAM and Flash if you choose Linux of any flavour.
I would not regard serial I/O as 'complex hardware', so unless you are running a complex, but standard protocol, your brief description does not appear to warrant the use of Linux IMO
My DLINK DIR-320 router runs Linux inside.
And I know some handymen, flashing it with Optware and connecting USB-hub, HDDs, USB-flash, and much more.
It's low-cost ready for use "platform". (If you don't need mass production). But maybe more powerful than you need.
Additionally, it can be configured wirelessly via web-interface even through your pda :)
We implemented a server application available on Windows only. Now we like to port it to Linux, HP-UX and AIX, too. This application provides internal statistics through performance counters into the Windows Performance Monitor.
To be more precise: The application is a data base, and we like to provide information like number of connected users or number of requests executed to the administrator. So these are "new" information, proprietary to our application. But we like to make them available in the same environment where the operating system delivers information like the CPU, etc. The goal is to make them easily readable for the administrator.
What is the appropriate and commonly used performance monitor under Linux, HP-UX and AIX?
I would say: that depends on which performance you want to monitor. Used CPU time? Free RAM? Disk IO? Number of beers in your freezer...
But regardless of this you can look at any files below /proc. I'm not sure for HP, but at least Linux and AIX should have that tree (if it's not deactivated at kernel compile time).
Management is where most OSes depart from one another. For this reason there are not many tools that are common between all the OSes.
Additionally, Unix tools follow the single process single responsibility idiom where one tool gets cpu info, another gets memory etc.
The only tool i have seen in the Unix world that gets all this info in one place is top. Almost all sys admins are familiar with this tool and works on all the flavors of OSes you are interested in. It also has the additional advantage of being open source. You could simply extend this tool to expose the counters you are interested in and ship it along with your application.
Another way to do this might be to expose your counters through SNMP and leave it to some third party SNMP tool like HP open view that can collect and present a consistent view along with other management info. This might be a more enterprisy solution, which might appeal to the marketing folks.
I would also say its a good idea to write a standalone console tool that admins can use from their custom home grown scripts (there are many firsm out there with super human admins / over paid it staff that does this).
All together would be a healthy solution for your requirement i think.
The most standard unix tools for such data are the *stat (iostat, vmstat, netstat) tools and sar. On Linux you'll find all this information in /proc, but most Unixes don't have /proc nicely filled with what you are looking for. The mentioned tools are quite standardized and can be used to gather the data you need.