NetBeans in Java Real-Time
NetBeans is a very convenient environment for the developer, usually frightening off with its inhibition, because cumbersome and written in Java. Well, let's hope that one day everything will work out, but for now let's see how Real-Time Java can fix this situation.
The Java Real-Time System is distributed (http://java.sun.com/javase/technologies/realtime/index.jsp) under a tight license with the ability to use a limited time: version 2.1 - only a year after installation. Version 2.2 is also available on the site with a 90-day limit.
JavaRTS for full operation requires a Real-Time system, and is available for download only for Solaris and Linux ( real-time kernel patches ).
What is the difference between real-time and regular Java?
- Real-time threads, scheduling and synchronization
The concept of 2 threads appears in RTSJ: real-time and no-heap real-time (which cannot be interrupted by the garbage collector). And also 28 priority levels for them.
- New memory management schemes
- Nanosecond accuracy of time and timers
- Direct access to physical memory (while maintaining security =))
However, for applications written without using the Java Real-Time API, one of the features specific to Java is the work of the garbage collector. It is performed at a time when it does not bother anyone and is constantly interrupted by re-planning processes.
So, let's go ...
Test object: NetBeans 6.5.1
JavaRTS 2.1 ArchLinux Everything is ready, we launch our "difficult" IDE
bash-3.2$ javarts -version
Java Real-Time System HotSpot(TM) Client VM warning: unable to lock pages into memory
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16_Java-RTS-2.1_fcs-b11_RTSJ-1.0.2)
Java Real-Time System HotSpot(TM) Client VM (build 1.5.0_16-b11, mixed mode)
bash-3.2$ uname -a
Linux hyperion 2.6.29-rt #1 SMP PREEMPT RT Wed Jun 3 17:02:08 MSD 2009 i686 Intel(R) Core(TM) Duo CPU T2450 @ 2.00GHz GenuineIntel GNU/Linux
bash-3.2$ ./netbeans --jdkhome /usr/share/JavaRTS/jrts2.1/
NetBeans booted unexpectedly quickly, although it was predictably in no hurry to initialize the modules.
Usually slowly and with the hum of the hard drive, the opening, side panels flew out, only for a moment braking the mouse. Finally, you do not have time to yawn until heavy menus appear, and the tabs open almost instantly.
Well, while the increase in speed can not but rejoice. Let's try something abruptly. I always didn’t like messing with updates and plugins just because of a long opening window for managing them: Tools -> Plugins ... And usually a long initialization of the list of plugins takes about the time specified in the progress bar - about 5-7 seconds.
The next hard thing: Tools-> Options ... Everything freezes, the menu appears pretty soon, but mouse control returns only after a few seconds.
The memory usage has been jumping from 90 to 130 MB all the time (according to the monitor of the “Java Profiler” plugin), although with jdk1.6.0_12 the limit is usually around 70 MB, but here, it is likely that the use of different versions of Java has a big impact (JavaRTS 2.1 compiled based on jdk1.5.0_16).