2 Replies Latest reply: Jun 3, 2008 4:07 PM by 807557 RSS

    Handle References

    807557
      Hello everybody,

      i'm quite new and encountered some Problems, that i think i'm surly not the first one to see them.

      So i'm interested what is your approach to solve this kind of Problems.

      1.) If you initialize a new Object you often have to give a reference with it. If you are in a Scope and you want to create an Complex Object, you often pass a reference. For Example: Cipher.getInstance("DSA"); Somehow this creates some encounters and returns a throwBoundaryError. Why this exactly happen... well i'm quite new so i'm just guessing. That it creates a temporary instance in another memoryArea. When working in ImmortalMemory this works quite well. So it is probably creating the temporary instance in the heap?. In the ScopeMemory an initialization of variables is sometimes impossible and cloning has to have a reference back to.

      How do you handle this case?

      2.) The 1 follows another problem. First we would assume we would create a Object (like a Cipher for example) in the ImmortalMemory for the reasons cited point 1. This object would when used create some internal buffer in this memory Area and eventually fill the memoryArea. Is there a manual mechanism to encounter the leak problem?

      Best regards

      Ch. DuChamps

      Edited by: Vispo on May 31, 2008 12:49 PM
        • 1. Re: Handle References
          807557
          Vispo wrote:
          1.) If you initialize a new Object you often have to give a reference with it. If you are in a Scope and you want to create an Complex Object, you often pass a reference. For Example: Cipher.getInstance("DSA"); Somehow this creates some encounters and returns a throwBoundaryError. Why this exactly happen... well i'm quite new so i'm just guessing. That it creates a temporary instance in another memoryArea. When working in ImmortalMemory this works quite well. So it is probably creating the temporary instance in the heap?. In the ScopeMemory an initialization of variables is sometimes impossible and cloning has to have a reference back to.
          The most likely problem is that the method tries to create an object in the scope and keep a reference to it in an existing, non-scope object or in a static field. This is not permitted: a longer-lived memory area can never hold a reference to an object in a short lived area. Place a try/catch in your Runnable used with the scope so that you can print the exception before it tries to propagate out and gets converted to a ThrowBoundaryError.

          If this is library code then the simple fact is that some libraries can not be used from ScopedMemory, and others must be used very carefully. The JDK libraries (other than javax.realtime) are not scope-aware and are not rewritten in a real-time VM to be scope-aware or scope-compatible. Sometimes you can use libraries if you always use them from the same memory area - but in this regard you have to remember that all static initialization occurs in ImmortalMemory, and that static fields can never hold references to objects in scopes. So any library class that creates new objects and stores references in statics, can not be used directly from ScopedMemory.
          2.) The 1 follows another problem. First we would assume we would create a Object (like a Cipher for example) in the ImmortalMemory for the reasons cited point 1. This object would when used create some internal buffer in this memory Area and eventually fill the memoryArea. Is there a manual mechanism to encounter the leak problem?
          If you fill the area with live objects then it isn't a "leak" you've simply exhausted the area. In Java RTS the size of immortal is set as a command-line option.

          However, if your internal buffer fills and you replace it with a larger one and throw the original away (as typical JDK collection objects do) then you do have a leak. The only solution is not allow these objects to grow dynamically in this way - eg pre-size them to the max capacity they will need; or use libraries that don't grow in this way. For example, the Javolution libraries define collection classes that don't leak and which are scope and immortal memory aware.

          Dealing with non-heap memory management is by far the most complex part of working with the RTSJ. Which is why there is so much interest in RTGC.

          Hope this helps.

          BTW if you google for "scoped memory patterns" you should find a couple of papers describing the various library issues you can encounter when using scopes.

          David Holmes
          • 2. Re: Handle References
            807557
            Was exactly what i thought. That i can't use some of the libraries. First i encountered the barrier, that i could initialize everything in the ImmortalMemory but not in the ScopedMemory. After looking into [isorc04.pdf |http://www.cs.purdue.edu/homes/jv/pubs/isorc04.pdf] (i think it's partly your work?). In my opinion a real good read for the memory handling. It was quite obvious that my commands would create some static, non Scope memory aware objects. I had the hope that there is a way to circumvent this but now after reflection, it is wiser to keep it this way. It has it's advantage too.

            Thank you for the javolution.org link. I didn't know about it. I will try to implement some parts of it in the first version of this little program.

            Anyway some Java libraries are interesting to keep the development time low. I rewrote my crypto algorithm with the adaptation of GNU Crypto project. This works as well as the java security libraries. When i have learned more about RTJ. Eventually i will be able to write RTJ compatible library classes. So i will continue to dig into it. I will solve one Problem after another.

            In this respect i greatly appreciated your help, which encourages me to get interested in the Java real-time part. I already was for the Real-time part but wasn't convinced that it would work out with Java. It seems that i will work with it for some months more. Just for getting a feeling.

            Best Regards

            Christian DuChamps