Introduction What should we know about pda 2
Yüklə 264,5 Kb.
|
- Bu səhifədəki naviqasiya:
- 2.What should we know about PDA
- 3.What should we know about Java
- 3.2.Some conceptions related with Java
- 3.3.1 Definition of the Java Virtual Machine
- 3.3.2.The styles of the Java Virtual Machine
- 3.4. Compare Java with the Java platform
- 4.Java for PDA 4.1.The significance of Java language to PDA
- 4.1.1.Ease of development and maintenance
- 4.1.3.Integration of Java code and native code
- 4.1.4.Developer focus and skills
- 4.1.5.Choosing a platform: the middleware choice
- 4.1.6.Efficient application execution
- 4.2.The merits of Java language to PDA
- 4.3.The Compilation Technologies for Java to PDA
- 5.How do Java, JVM, and Hardware work together well
- 5.1About Java bytecodes
- 5.2. About v irtual parts
- 5.3.About t hreads and shared data
- 5.4.About o bject and class locks
- 5.5.About m onitors
- 5.6.The other tasks of Java Virtual Machine to Java and hardware
- 6.Issues and Tradeoffs of Java to PDA
| 1.Introduction 2 2.What should we know about PDA 2 2.1.Definition of PDA 2 2.2.One example for PDA 2
3.1. Definition of Java 4 3.2.Some conceptions related with Java 4 3.3.Definition and component of the Java Virtual Machine 4 3.3.1 Definition of the Java Virtual Machine 4 3.3.2.The styles of the Java Virtual Machine 5 3.4. Compare Java with the Java platform 5
4.1.The significance of Java language to PDA 5 4.1.1.Ease of development and maintenance 5 4.1.2.Reuse of code 6 4.1.3.Integration of Java code and native code 6 4.1.4.Developer focus and skills 6 4.1.5.Choosing a platform: the middleware choice 6 4.1.6.Efficient application execution 7 4.2.The merits of Java language to PDA 7 4.3.The Compilation Technologies for Java to PDA 8 5.How do Java, JVM, and Hardware work together well 9 5.1About Java bytecodes 9 5.2. About virtual parts 10 5.3.About threads and shared data 10 5.4.About object and class locks 11 5.5.About monitors 11 5.6.The other tasks of Java Virtual Machine to Java and hardware 12
6.1.Footprint 13 6.2.Performance 13 6.3.Memory Management 14 6.4.Determinism 15 6.5.Tools 16 7.Conclusion 17 Reference 17 1.IntroductionToday, the world of intelligent devices is changing dramatically. The computerized devices around us are getting smarter, they're increasingly connected and interdependent, and they're becoming vastly more numerous. The PDA (Personal Digital Assistant), just one of them, is also getting stronger and more intelligent. Moreover, all this is happening at an ever-increasing rate. In this article, I will introduce the general definitions for the Java, Java components and PDA. I will also expound the significance and technology of Java for PDA. Here, I do not only talk about the Java language but also the extended Java, such as J2ME, J2EE and Java platform for PDA, especially the JVM (Java Virtual Machine). This article also comes down to the relations between the Java and JVM, and between JVM and PDAs’ hardware. 2.What should we know about PDA2.1.Definition of PDAPDA Short for personal digital assistant, a handheld device that combines computing, telephone/fax, and networking features. A typical PDA can function as a cellular phone; fax sender, and personal organizer. Unlike portable computers, most PDAs are pen-based, using a stylus rather than a keyboard for input. This means that they also incorporate handwriting recognition features. Some PDAs can also react to voice input by using voice recognition technologies. The field of PDA was pioneered by Apple Computer, which introduced the Newton MessagePad in 1993. Shortly thereafter, several other manufacturers offered similar products. To date, PDAs have had only modest success in the marketplace, due to their high price tags and limited applications. However, many experts believe that PDAs will eventually become common gadgets. 2.2.One example for PDAI show one latest smart PDA: Sharp's Zaurus SL-A300 (Figure 1) 
Figure 1: Sharp's Zaurus SL-A300 Here is a summary of the features and specifications of the SL-A300 Zaurus PDA: Hardware:
Software:
3.What should we know about JavaTo java, I think, every developer and programmer maybe think that it is just one programming language. But this viewpoint is not all-sided and correct. 3.1. Definition of JavaJava is one programming language developed for the Web developed by Sun Microsystems. It implements a strong security model, which prevents compiled Java programs from illicitly accessing resources on the system where they execute or on the network. Popular World Wide Web browsers, as well as some World Wide Web servers and other systems implement Java interpreters. 3.2.Some conceptions related with Java
3.3.Definition and component of the Java Virtual MachineFrom above I have listed some conceptions related with Java. But I have not referred to the Java Virtual Machine (JVM) which is one of the most important components of Java. In the following part I provide an introduction to the definition and component of the Java Virtual Machine. 3.3.1 Definition of the Java Virtual MachineJava Virtual Machine (JVM) is a virtual computer, typically implemented in software on top of a "real" hardware platform and operating system, which runs compiled Java programs. The JVM is "virtual" because it is generally implemented in software on top of a "real" hardware platform and operating system. All Java programs are compiled for the JVM. Therefore, the JVM must be implemented on a particular platform before compiled Java programs will run on that platform. We should thank to the JVM, programs written in Java don't have to be rewritten to run on different computers. 3.3.2.The styles of the Java Virtual MachineGenerally the Java Virtual Machine includes two styles. One is Personal Java Virtual Machine, the other is Embedded Java Virtual Machine. Here are the definitions of them:
3.4. Compare Java with the Java platformIt's important to distinguish between the Java language and the Java platform. The Java language is an object-oriented programming language with syntax similar to C. The Java platform offers a run-time environment, which includes a Java Virtual Machine (JVM) to execute Java programs compiled into architecture-neutral byte codes. It also includes a library of standard Java classes that are available to all Java programs running on the platform. 4.Java for PDA4.1.The significance of Java language to PDAJava offers the domain of PDA’s embedded systems clear advantages over C language or assembler. The most significant are ease of development and maintenance, reuse of code, and easy integration of native code and Java code. 4.1.1.Ease of development and maintenanceOver the entire life of a project, the Java environment enhances ease of development and maintenance. When the target system is based on a virtual machine, code can be easier to instrument, debug, analyze, hot-replace, and maintain. Connected devices can be far more complex than previous kinds of embedded systems. Manual techniques for upgrading may be no longer effective over the project lifecycle. Instead, the connectivity of devices provides the ability to manage components remotely, allowing development teams to add product features, resolve problems, and maintain and upgrade the software in the device after the product ships. Java makes true cross development possible. Program function is developed on workstations, unit tested and prepared for integration. Thus, even without access to prototype hardware, developers can proceed with function development. After prototype hardware is available, developers can share it through network attachments, creating a virtual lab accessible to team members within a company or among partner companies. The Java program execution environment also reduces issues relating to memory management, allowing automated "garbage collection" techniques to be used to cleanup after released memory segments. 4.1.2.Reuse of codeDue to the specialized requirements of embedded systems and the corresponding use of varied, specialized hardware, embedded software developers have traditionally used quite rudimentary methods of development, sometimes starting from scratch on each new project. Now, as embedded techniques mature and the systems themselves become larger and more sophisticated, there is increased interest in reusing components or full applications from product to product. This reuse makes it possible to invest in development once and extend the payback across multiple projects. The Java environment lets the owner of a component adapt it to many projects and platforms, often at lower cost, even when customers require different targets or when technology has introduced new hardware (CPUs, devices) and software, including variants of Linux. 4.1.3.Integration of Java code and native codeThe use of native code has significant implications in terms of portability of applications and the ability to reuse code. A well-engineered interface between the Java application, virtual machine and underlying hardware brings the best of all worlds to embedded compatibility. Native code, while not portable, may be the best solution for many functions and device interfaces. Adding standard communication, post-development component management, new user interfaces, and security features would be quite expensive and time consuming in C, C++ or assembler. The Java base libraries provide these things and more, which can speed development. 4.1.4.Developer focus and skillsMany developers are now being educated on Java application development. IBM has, for example, several thousands of programmers who create Java applications. With this popular language and deployment environment uniformly available in major educational institutions, the number of Java developers is growing. The next generation of embedded project developers will need to deal effectively with the complexity and power of connected network attached devices. Since both Linux and Java implement access to TCP/IP communication component stacks, much of the work to enable communications support has been completed, and done in a well-understood and standard manner. 4.1.5.Choosing a platform: the middleware choiceThere are numerous choices for middleware, most available as individual components such as protocol stacks, graphics development tools and managers, and special OS services such as high availability and real-time extensions. Using any one of these individually is not too difficult, but as the number and variety increase there is inevitable impact on developer productivity and delays during integration, test and debug caused by the added complexity in the stack. Initially designed to address these issues in the desktop and server market, Java has begun to find wider acceptance as the application environment for embedded projects. Providers of Java technology have already done this integration for several standardized facilities, including communications, security, and component management. The object-oriented nature inherent in Java application design allows all of these disparate middleware services to be dealt with in an efficient and well-organized way. Other middleware environments offer the same kind of abstraction from the details of the underlying implementation, but none with the broad industry support that Java enjoys today. Finally, it's possible to extend Linux to provide the control developers need to ensure deterministic real-time program execution and behavior. There are several approaches to implementing this. Monetarist provides extensions to standard Linux platform features rather than modify them. For example, to support real-time program execution, Hard Hat Linux made new APIs available for controlling memory management, thread scheduling, and process execution. 4.1.6.Efficient application executionThanks to the establishment of standard Java class library configurations it's more than possible to manage application size. In fact, studies have shown that applications that occupy over 500KB can actually be more compact when deployed as Java byte-codes. This is because byte-codes are more compact than many hardware machine instruction sets. The ability to reuse well-known routines in the class libraries combined with the smaller byte-code instructions, more than make up for the memory footprint of the virtual machine and libraries. 4.2.The merits of Java language to PDAJava language technology's merits line up nicely with the today's needs in PDA’s embedded systems: Object oriented -- Designed for object-oriented programming from the start, the Java language is cleaner, simpler and easier to learn than C++. Object orientation helps developers to partition programming tasks and create reusable software components, maximizing investment in the original code and decreasing both time-to-market and development costs. Portability and APIs -- The Java platform extends the concept of portability further by providing a virtual machine environment that runs any Java program without recompilation, regardless of the underlying processor and operating system. Java platform APIs provide a full-featured library with hundreds of classes for manipulating data and performing networking, display, and I/O tasks. Platform portability eases the task of building and testing a complete application on a desktop PC and then deploying the same object code on a target system. Memory management -- Memory management in C and C++ is error-prone and difficult to debug, with memory "leaks" manifesting themselves only under conditions that are difficult to reproduce. The Java run-time environment avoids many of these problems by determining when objects are no longer in use and automatically reclaiming memory, a process known as garbage collection. Garbage collection reduces the bookkeeping responsibilities of application developers and eases the evolution, reuse and integration of independently developed software components. Threading support -- The Java language has a built-in notion of multithreading. A critical section of code can be marked synchronized, ensuring that any thread executing the marked code obtains an exclusive lock on a synchronized object. If another thread has the lock, the new thread waits until first thread's exit of the marked section. Networking support -- Writing network-aware programs in the Java language is as easy as reading and writing files. The same InputStream and OutputStream classes used to access files are also used to send and receive data over network connections. A simple Web server is implemented in a few lines of Java code and open-source third-party libraries are available to implement full-featured clients and servers. Dynamic class loading -- The Java run-time environment enables a unique extensibility through dynamic class loading. Base-level applications can be customized and enhanced later because the JVM allows new programs represented as Java classes to be loaded into an application while it is running via disk, flash, or serial/network connections. 4.3.The Compilation Technologies for Java to PDANaturally we should use the Java compiler and compilation technologies when we use Java programming language to develop the PDAs. To meet the performance requirements of many PDAs, compilation technology is required. There are several different compilation methods depending on the requirements: Ahead-of-Time (AoT) -- An ahead-of-time compiler is very similar to a standard C compiler in functionality. It takes Java code and converts it to machine code. The compiler may compile everything, including class libraries. Some ahead-of-time compilers allow you to perform dependency analysis on your code to determine which classes/methods to compile. The resulting executable is referenced during runtime using the Java class path. The problem with compiling everything ahead-of-time for embedded systems is that the size of the executable can be very large. Another issue is that if you want to deploy code on several different hardware/operating system architectures you need to compile the code for each. Also, if you want to change the classes loaded you need to recompile. Just-in-Time (JIT) -- A just-in-time compiler will take byte codes that are being loaded into the system and compile them. There is a start-up cost associated with this methodology as well as a footprint requirement. The advantages of this solution over the AoT compilers is that it utilizes machine independent Java byte codes. Dynamic Compilation -- This method looks at the running system and determines what pieces of code are most frequently executing. The dynamic compiler then compiles the "hot" areas of code in order to speed up system performance. The advantages of dynamic compilation is that the amount of memory consumed is configurable - and the ability to dynamically change classes is maintained. An issue with Dynamic Compilation is that it is an unbounded process and therefore can't be used when meeting timing constraints is critical. 5.How do Java, JVM, and Hardware work together wellThere are three level components in the PDAs’ Embedded system. The first level is User-Level which includes all of the applications. And now lots of applications in PDAs written in Java. More and more developers and programmer prefer Java language to C language. We have referred to the reasons for that above. The second level is Application Support&Middleware-Level which includes all kinds of class libraries, virtual machine etc.. To the class libraries, the Java is very similar to C or C++ language which has a lot of abundant class libraries. In this level, the Java Virtual Machine is like a hinge between the User-Level (Java applications) and System-Level (OS and hardware). The System-Level is the third level and the Bottom-Level which includes OS (operate system), device drivers and hardware. Among these three levels, they have the closed relations. 
Figure 2: Component relationships The JVM plays a central role in making Java portable. It provides a layer of abstraction between the compiled Java program and the underlying hardware platform and operating system. The JVM is central to Java's portability because compiled Java programs run on the JVM, independent of whatever may be underneath a particular JVM implementation. And the JVM was designed to be small so that it can fit in as many places as possible -- places like PDAs, TV sets and personal computers. The JVM is mean because it of its ambition. "Ubiquity!" is its battle cry. It wants to be everywhere, and its success is indicated by the extent to which programs written in Java will run everywhere. And the Java Virtual Machine can be the hinge between the Java and hardware because of: Java bytecodes, virtual parts, threads and shared data, object and class locks, and monitors etc.. 5.1About Java bytecodesJava programs are compiled into a form called Java bytecodes. The JVM executes Java bytecodes, so Java bytecodes can be thought of as the machine language of the JVM. The Java compiler reads Java language source (.java) files, translates the source into Java bytecodes and places the bytecodes into class (.class) files. The compiler generates one class file per class in the source. 
To the JVM, a stream of bytecodes is a sequence of instructions. Each instruction consists of a one-byte opcode and zero or more operands. The opcode tells the JVM what action to take. If the JVM requires more information to perform the action than just the opcode, the required information immediately follows the opcode as operands. A mnemonic is defined for each bytecode instruction. The mnemonics can be thought of as an assembly language for the JVM. For example, there is an instruction that will cause the JVM to push a zero onto the stack. The mnemonic for this instruction is iconst_0, and its bytecode value is 60 hexes. This instruction takes no operands. Another instruction causes program execution to unconditionally jump forward or backward in memory. This instruction requires one operand, a 16-bit signed offset from the current memory location. By adding the offset to the current memory location, the JVM can determine the memory location to jump to. The mnemonic for this instruction is goto, and its bytecode value is a7 hex. 
5.2. About virtual partsThe "virtual hardware" of the Java Virtual Machine can be divided into four basic parts: the registers, the stack, the garbage-collected heap, and the method area. These parts are abstract, just like the machine they compose, but they must exist in some form in every JVM implementation. The size of an address in the JVM is 32 bits. The JVM can, therefore, address up to 4 gigabytes (2 to the power of 32) of memory, with each memory location containing one byte. Each register in the JVM stores one 32-bit address. The stack, the garbage-collected heap, and the method area reside somewhere within the 4 gigabytes of addressable memory. The exact location of these memory areas is a decision of the implementer of each particular JVM. A word in the Java Virtual Machine is 32 bits. The JVM has a small number of primitive data types: byte (8 bits), short (16 bits), int (32 bits), long (64 bits), float (32 bits), double (64 bits), and char (16 bits). With the exception of char, which is an unsigned Unicode character, all the numeric types are signed. These types conveniently map to the types available to the Java programmer. One other primitive type is the object handle, which is a 32-bit address that refers to an object on the heap. The method area, because it contains bytecodes, is aligned on byte boundaries. The stack and garbage-collected heap are aligned on word (32-bit) boundaries. 5.3.About threads and shared dataOne of the strengths of the Java programming language is its support for multithreading at the language level. Much of this support centers on coordinating access to data shared among multiple threads. Inside the Java virtual machine, each thread is awarded a Java stack, which contains data no other thread can access, including the local variables, parameters, and return values of each method the thread has invoked. The data on the stack is limited to primitive types and object references. In the JVM, it is not possible to place the image of an actual object on the stack. All objects reside on the heap. There is only one heap inside the JVM, and all threads share it. The heap contains nothing but objects. There is no way to place a solitary primitive type or object reference on the heap -- these things must be part of an object. Arrays reside on the heap, including arrays of primitive types, but in Java, arrays are objects too. Besides the Java stack and the heap, the other place data may reside in the JVM is the method area, which contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads. 5.4.About object and class locksAs described above, two memory areas in the Java virtual machine contain data shared by all threads. These are:
If multiple threads need to use the same objects or class variables concurrently, their access to the data must be properly managed. Otherwise, the program will have unpredictable behavior. To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can "possess" at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the JVM for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread. Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it. 5.5.About monitorsThe JVM uses locks in conjunction with monitors. A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code. Each monitor is associated with an object reference. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object. 5.6.The other tasks of Java Virtual Machine to Java and hardwareBesides these reasons what we have talked about above the Java Virtual Machine has many other tasks:
Here we can find the tasks of the JVM are quite complex, including tasks that are normally associated with compilers or operating systems and hardware. In particular, these complex requirements make a hardware implementation difficult. However, evidence suggests that hardware JVM would be 5 times faster than the fastest software JVM. And all the Java instructions occur within a method. The JVM specification says that each method must have its own stack frame. A stack frame has three sections:
The JVM is a stack-based architecture, having no internal registers for use by Java programs. All instructions use the operand stack as the source of their operands. The frame data is implementation dependent, since the stack frame design is also specific to each JVM implementation. My Java processor stores several internal pointers in the frame data (such as the return address for the calling method). Before a method is invoked, the method's arguments are pushed onto the operand stack. Since these arguments map to local variables in the new method, it makes sense to overlap the stack frames for the two methods, as shown below. This saves copying the method arguments between the stack frames. 
Figure 3: Two methods of stack frames. 6.Issues and Tradeoffs of Java to PDADespite they have so many merits to PDA, Java present PDA’s embedded system developers with a number of issues and tradeoffs: footprint, performance, memory management, determinism, tools. 6.1.FootprintThe Java platform, and any needed application classes will further increase ROM requirements. An embedded JVM may take up to 256 KB, while standard class libraries often require another 1 MB or more of additional ROM. The java.awt graphics libraries, for instance, can add 1 to 2 MB more of classes. A common way to reduce non-volatile storage needs in Embedded OS is to use a compressed initial RAM disk image that automatically expands into RAM at boot time. For example, a 1.44 MB boot floppy with a 512 KB compressed, network-capable kernel and a 512 KB compressed RAM disk image containing a JVM and the lang, io, net, and util libraries leaves about 400 KB for application classes. RAM requirements depend on the application, of course, but an off-the-shelf Embedded OS distribution won't run very well in less than 8 MB. Embedded OS vendors are working to reduce both ROM and RAM requirements. Java RAM requirements largely depend on your performance choices, but if you use static linking tools to make Java byte codes executable from ROM, you can reduce RAM usage. Without static linking, classes must be linked and loaded into RAM at execution time. 6.2.PerformanceEarly Sun releases had a slow byte code interpreter compared to C or C++. Despite significant speed improvements, a Java interpreter is still 10 to 20 times slower than C or C++. To address this performance gap, some vendors have developed Just-in-Time (JIT) compilers (e.g., NewMonics' QuickPERC JIT) that compile Java byte codes into native code for the target processor on the fly as they are loaded into memory. JIT compilation boosts performance, but the compilation time may be too costly, especially if the code doesn't contain loops or only runs once. An Adaptive JIT compiler, such as Insignia Solutions', monitors execution and only compiles code that runs frequently. RAM footprint is higher with JIT compilation than with interpreted code because the native instructions are placed in RAM and are less compact than Java byte codes (native code is 4 to 8 times larger). NewMonics' QuickPERC AOT and HP's TurboChai offer Ahead-of-Time (AOT) compilation, which generates native code that is statically linked with the runtime JVM. This method avoids runtime compilation at the expense of ROM footprint. An AOT-only solution (no Interpreter, no JIT), often called a Java-to-native compiler, still requires a runtime library and is functionally equivalent to an AOT compiler that links the code it generates with a JVM. The table below summarizes the relative speed, ROM footprint and RAM footprint tradeoffs of various performance features available from embedded Java vendors. 
Figure 4: Compare the Performance. By moving from interpreted to compiled code, JIT and AOT improve performance by as much as ten or more times. Adaptive JIT is faster than conventional JIT because it doesn't compile all classes, while AOT provides the highest speed by avoiding runtime compilation entirely. Assuming the JVM and Java classes are stored in ROM, the JIT and adaptive JIT compiler options increase ROM footprint by the size of the runtime compiler itself with the adaptive JIT being more complex and therefore larger. An AOT compiler uses much more ROM to store the compiled native code. If you use a static linking tool (like the NewMonics ROMizer), the RAM footprint requirement for interpreted code is relatively low. Conventional JIT compilers use the most RAM because all classes are compiled into RAM, while adaptive JIT compilers use less RAM by only compiling frequently used byte codes. AOT-compiled code uses very little RAM. 6.3.Memory ManagementAlthough the Sun virtual machine specification defines the functional requirements of the JVM, it leaves operational details, such as memory management, to the implementer. The choice of memory management algorithm can significantly affect the behavior of the Java platform. For example, a garbage collector that does not address memory fragmentation depends on expansion of the memory heap to accommodate an allocation request that is too large for any available memory segments. Once memory has fragmented enough and the heap has reached maximum size, an out of memory error will occur. In embedded systems where memory is limited, ignoring fragmentation is unacceptable. How a garbage collector finds active objects in memory can also make a big difference. The mark and sweep algorithm used by most collectors starts from a set of known "root" pointers found in registers and variable stacks and traces them. It locates and marks the objects they reference as in-use, then traces pointers in those objects, and so on, until all active objects have been traced and marked. The remaining unmarked objects are "swept" into the free memory pool (see Figure 4). 
Figure 5: Mark and Sweep Algorithm. Problems arise based on how the collector treats variables. Conservative collectors don't always know which variables and fields are pointers and which are primitive types (i.e., integers), so it treats uncertain values as pointers. While this is a common shortcut, it has a serious drawback: if a non-pointer contains a value that points to an inactive memory object, the object and the objects it references will not be collected. Essentially, it causes a memory leak. This is particularly bad because the leak is data dependent and may not occur until a variable, such as an encoded date, hits a magic number. Applications that worked fine yesterday may get an out of memory exception today. In memory-constrained environments, a precise defragmenting garbage collector is the only reliable choice. A precise collector knows which variables and fields contain pointers and which contain primitive types, so it collects all unused objects. A defragmenting collector coalesces unused memory segments to allow subsequent large allocations to succeed. With a precise defragmenting collector, memory utilization can be tested and predicted reliably. (The NewMonics PERC collector is one example of a precise defragmenting collector.) 6.4.DeterminismDeterminism may be described as a real-time performance issue, but many applications that aren't considered "real-time" still have a timeliness requirement. OS can affect real-time determinism if a driver or the kernel disables interrupts while it waits for an event to occur. Embedded system developers are working on this issue, some by careful characterization of the kernel and critical drivers and others by providing a real-time environment inside OS itself. Java determinism issues relate to execution time and garbage collection. If the application's execution time needs to be predictable, the JVM must provide constant-time memory allocation and Java method invocation. Constant-time memory allocation requires maintenance of multiple size-ordered free lists rather than "walking" a free list to locate a memory segment that is large enough. An adaptive JIT compiler doesn't allow constant-time method invocation due to the unpredictability of runtime compilation. Alternatively, performing JIT compilation at class load time assures predictability. The garbage collector is another factor in Java determinism. If the mark and sweep algorithm is implemented in its most basic form, the collector cannot relinquish access to the memory heap until it has completed a full mark and sweep pass. If it stops midway through a pass, a Java thread might allocate a new object or modify a pointer, making it impossible for the collector to know if it can safely sweep an unmarked object into the free pool. The time required to complete a mark-and-sweep pass depends on memory usage, but it can delay scheduling of a periodic thread from tens of milliseconds to several seconds, based on the memory activity of other threads (see Figure 6). 
Figure 6: Scheduling Latency. Figure 6 depicts a scheduling latency test run on a common desktop JVM. The test has one Java thread allocating a large linked list in memory and then releasing it, iteratively, while a second thread checks the current time, sleeps for 100 milliseconds, and then checks the time again. The difference between actual and expected sleep time is plotted on a logarithmic scale. A deterministic Java implementation would show a flat line, indicating no variance from the expected sleep time. As you can see, the sleeping thread is often delayed by twice the expected time, typical of a classic stop and wait collector. An incremental garbage collector performs its task in short increments and suspends when a high-priority Java thread needs to run, thus accomplishing the collection process without scheduling latency. Developers need to ask detailed questions when vendors talk about their collectors. Some claim they have an incremental collector, but in fact an "increment" is an entire mark and sweep pass. A concurrent collector runs in a separate process or thread from the JVM, but that may still mean that other Java threads must stop and wait while it finishes a collection pass. Others may say they have a background collector that doesn't affect real-time tasks, but they require that real-time tasks be written in C and executed outside of the Java run-time environment. A truly incremental garbage collector should provide deterministic behavior for Java programs, nothing less. 6.5.ToolsOn the Java tools side, a Java IDE, which includes a Java-to-byte-code compiler and a Java source-code debugger that allows remote debugging, is essential. Commercial Java IDEs are available from many sources, but avoid tools that only debug your code on the host machine or only with a specific JVM. A JVM and debugger supporting the Java Debug Wire Protocol (JDWP) standard provide remote debugging over a network or serial connection to your target system The JVM vendor should provide tools that link and package the JVM and classes for storage and execution from ROM or flash memory. These tools statically link the packaged Java classes so their byte codes are executable from ROM. Alternatively, if a file system is available, some or all of the classes can be stored separately, usually in a ZIP or JAR archive format file. Many embedded Java vendors provide tools to reduce footprint requirements by eliminating unused classes and methods from classes. These "tree shakers" scan code execution paths and "shake out" unused fields and methods. However, they prevent subsequent dynamic loading of new application classes if they depend on classes or methods previously eliminated. If you want to use a tree shaker, look for one that lets you specify the core classes that should be left intact. Lastly, embedded Java vendors may supply an AOT compiler for generating native code from Java source or class files to improve performance. The footprint tradeoffs are important to consider, so make sure you have the option of AOT-compiling selected classes for optimized performance and allowing other classes to be interpreted or JIT compiled. 7.ConclusionThanks to the emergence of professional support organizations that have focused on the problems experienced by embedded developers, a wide array of connected device platforms can now support execution of Java applications. When matched with the power and flexibility of the Java environment, project managers and developers have available a combination that enables them to successfully design and develop the next generation of embedded systems applications, delivering high reliability and availability. So as one programming language, I think, Java will be used for PDA or the other wearable devices more and more generally. Reference[1] C2ctravel.net. Introduction of PDA. http://www.c2ctravel.net/pda.htm, 2002-10-30. [2] El-Kharashi, M.W. and ElGuibaly, F. Java Microprocessors: Computer Architecture Implications. PACRIM 1997. [3] Sun Microsystems. The Java Chip Processor: Redefining the Processor Market. Sun Microsystems, November 1997. [4] Sun Microsystems. picoJava-I: Java Processor Core. Sun Microsystems Data Sheet, December 1997. [5] Sun Microsystems. picoJava-II: Java Processor Core. Sun Microsystems data sheet, April 1998. [6] Wayner, P. How to Soup up Java (Part II): Nine Recipes for Fast, Easy Java. BYTE, May 1998. [7] Rick Lehrbaum Device Profile: Sharp's Zaurus SL-A300 Personal Mobile Tool http://www.Linuxdevices.com/articles/AT5915008901.html, 2002-10-18. [8] Searchwebservices.techtarget.com Introduction of J2EE http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci283984,00.html, 2003-03-04. [9] http://java.sun.com/ Yüklə 264,5 Kb. Dostları ilə paylaş:
|