Inhalt
Topic=.Java2C.Changes.
.
Topic=.Java2C.Changes..
Topic=.Java2C.Changes..
.
Topic=.Java2C.Changes...
The following features are implemented yet and first-time tested with the examples:
Implementation of new Type(args)
in all expressions, implementation of garbage collection in C.
Garbage collection in CRuntimeJavalike implemented and tested.
while(){...} do{...}while()
and switch(){case:...default: }
-statements
condition ? exprTrue : exprFalse
static members: either simple constants (implemented with define...) or static definition outside the struct-class in C
Topic=.Java2C.Changes...
at ex. Math.abs(): Math should be recognized as class, the Java2C recognized it as unknown reference, an error occurs. Therefore all standard types should be stored in ident lists.
for(;;)..
is not implemented yet (TODO)
Topic=.Java2C.Changes...
The Position-contol-example is completed with a set value generator. A new target position can be setted, it is stored using a new-construction in Java to test the implementation of new and garbage collection in C.
A test environment for garbage collection is created.
Topic=.Java2C.Features.
Why C and not C++?
C is nearer to machine code as C++ and therefore better appropriate, if the execution code should be known. It is frequently in embedded control.
C is supported for all embedded controller, C++ not in any case.
In C the functionality of inheritance and dynamic calls (interface concept) is implementable. Because the translator produces the necessary code, it should not be manually written, the necessitative extensive complex statements don't be a problem.
In the table below the features of the Java2C translator and the CRuntimeJavalike are visualized.
Java-feature |
Implementation in C |
Remarks | ||
|
|
ready, basic feature! | ||
|
|
Prio2, inheritance concept is interestedly but not essentially for embedded control. But it is no large expenditure of implementation. | ||
|
|
Prio2, The inheritance concept is interestedly but not essentially for embedded control. It is solved as a matter of principle. An interface is represented by a ObjectJc* reference and a Jtbl-struct (jump table). Enhanced references are necessary to store a index of the jump table position of interface in the jump table of the implementation class. | ||
|
|
Prio2, It's the same like interface concept, but more simple because a enhanced reference is not need. | ||
|
|
ready. The using of dynamic memory is supported both in the construction phase in embedded real-time software and really dynamically at run time. A garbage collector is implemented. | ||
|
|
ready. If the reference at class level is final and assigned at class level with the same Class, it is a fix instance. Therefore a embedded struct is realized in C. It is a important basic feature because in C embedded struct are an opportune implementation for nested data. | ||
|
|
ready. In the runtime phase in embedded real-time software no extensively using of dynamic memory should be done. But for special requests like events or temporary Strings, dynamic instances are necessary. To support such, a BlockHeap concept with equals blocks is slated. The dynamic objects should have a limited size. It may be opportune in embedded control. | ||
|
|
Prio1. The try-catch-throw concept is essentially in Java, found in C++ and a convenient and necessary feature in C. The implementation of throw in C is done using the longjmp-concept, known since 1970 and available for all processors. For C++ environments also the try/throw of C++ is useable. See german description at http://www.vishia.org/Jc/html/Exception_Jc.html. | ||
java.lang.String, java.lang.StringBuilder |
StringJc, StringBufferJc |
Prio1. Strings are necessary in embedded control to assembly error messages or such ones. The basic features of java.lang.Stringbuilder should be implemented. | ||
java.lang.String, java.lang.Thread |
ThreadJc, RunnableJc |
Prio1. Multithreading is a basicly necessitative feature of embedded control. Not all features, especially not ThreadGroup etc. are supported. | ||
java.util.List, LinkedList, ArrayList, TreeMap, Container |
ListJc, LinkedListJc, ArrayListJc |
Prio2. This features are interestedly and supports the reason to work with java. C don't know a good concept of container. All this features are implemented in C level in CRuntimeJavalike. It should be work together with the Garbage-Collector - BlockHeap- concept, because the Nodes of Lists are managed with them. | ||
java.awt, javax.swing |
nothing |
not supported. If graphical features should be used with Java style, the using of Virtual Machines for Java for embedded controller should be considered. There are some offers, like Jamaica-VM. It is possible to connect C routines with Java at the same processor using JNI or localhost-InterProcessComm or at a second processor. It is a good decision using embedded control in connection with PC based software. | ||
java.net.Socket |
InterProcessComm |
Prio2. The InterProcessComm is a concept using Socket communication or other communication ways like serial or DualPortRam, above the java.net.Socket-classes. The InterProcessComm may be the basic concept to connect processors with several programming concepts. | ||
java.io |
TODO |
Prio2. All accesses to the file system are a basic feature in C since anno 1970, but the translation from Java source should be elaborated. As a workarround, use directly C routines to access files and console. |
You find a german documentation and discussion above this topic at http://www.vishia.org/Java2C. If you have questions or notes, please mail to hartmut.schorrig@vishia.de.
Topic=.Java2C.BlockHeapConcept.
In hard realtime long-running systems the using of dynamic allocated memory isn't allowed often. The reason is the hazard of appearance of memory leaks. Memory is allocated and freed to any times in any allocated sizes. An algorithm to sort the allocated areas can't be run because it need non interrupted CPU time to work.
But in more complexly algorithms a usage of dynamic memory is desirable. Using Java it is more suggesting to do so. At example:
The assembling of a textual output with some informations need a buffer. In C the using of sprintf
is a decision. But the buffer should be supplied or existing.
Events in a statemachine- or event driven system often needs dynamic allocated memory for itself or for there data.
In C or C++ without using dynamic memory a self-made memory management for special cases is implemented often. But this implementations are user specific though it is a system requirement. It is an effort in the users software.
Another topic regarding Java-usage is the garbage collector. A typical C or C++ implementation uses malloc or new and the opposite call of free or delete. But if data are interchanged between modules, one module allocated the memory spaces and another module or more as one another module use it. Which module should delete it?
The answer for Java-like programming with hard realtime long running systems is the BlockHeap-Concept. It combines both requirements, the prevention of memory leaks and the garbage collection.
A base idea is, that a dynamically required memory is not a large memory. All main data should be instantiated statically. Dynamically required data are only small pieces of data: A buffer for textual assembling, a buffer for new event data, or such ones.
Topic=.Java2C.BlockHeapConcept..
Therefore the BlockHeap works with blocks with equal size. If any dynamically memory is required, a whole block is supplied. It is not so effective in memory using, but the kilobytes of available memory are not the first problem. In fine tuning there are supported two block sizes: also small blocks inside a normal block, and third a blocksize for nodes of LinkedList, TreeMap etc.
There are more as one BlockHeap management, with independent using of Blocks. A outreaching usage of blocks from one module should not block the other functionality.
Topic=.Java2C.BlockHeapConcept..
The garbage collector is a basic concept in Java and it should be worked also in C-translated parts. All references to blocks of a BlockHeap are noted as backward references in the appropriate Block of the BlockHeap.
The references may be came from outside, it is from static allocated memory, or from other blocks. If a reference comes from outside, the block is in use at all cases. If another block of a BlockHeap references the block, the reference comes from inside a dynamically allocated treated by GC memory location. Therefore it is possible that a reference is found, but the reference comes from a not referenced block. The garbage collector should be tested all blocks of such an cluster. If no outside references are found, all blocks reference it together, but there are not in use.
To prevent thread timing effects the garbage collector is aborted in its work if a block is reused with a new or other reference while it is testing. The GC should be start again the test for this cluster and should be forgot the found now assessment. But if the same block is tested again, and a fast algorithm switches the references between blocks of cluster, the GC is aborted again and again and it doesn't step forward. Thats why the aborted GC doesn't start with test of the same (aborted) block in the next step. It starts with the next block in BlockHeap.
To notate the back references, there are subroutines to do it, named setBackRefJc() and clearBackRefJc(). This routines have to be called if a reference to dynamically memory is stored and removed. The reference itself is an enhanced reference, including a index value of the back-ref array. The setting of back-refs needs a few instruction time, but not much one.
Topic=.Java2C.BlockHeapConcept...
Enhanced references with the necessity of call setBackRefJc() are not used
for local (stack-) -variables and method arguments,
for classes there are not slated for using in dynamically memory, that classes should be marked with @staticInstance
in the description of class.
If a reference to a block is only stored in a stack variable without back-reference, it should not be considered by garbage collector to prevent a free of this block while using. Therefore the first simple using of a block is marked with a bit. If the first back-ref is stored, the block is marked to consider by GC. If no back-reference is stored, the block may be only used locally in a thread. But after its using it should be freed. Therefore on end of the statement block, in which the block is allocated, a call of activateGarbageCollectorAccess_BlockHeapJc()
is done to commit it to the GC. After this block either the reference is stored with notation of back-ref, if it is used later again or in another thread, or it is not used furthermore.
Topic=.Java2C.BlockHeapConcept...
If an concept of garbage collection is used, it don't care which, some special operations should be done. Using C++, automatic generated destructors or overloaded operators can be used. But in C it should be programmed manually. Therefore the automatic code generation from Java to C helps to do this things. The Java2C translator produces the right code without any slips.