4 Replies Latest reply on Nov 23, 2011 10:18 PM by EJP

    How to avoid readClassDesc overhead


      This is my first post to this forum. I'm an Oracle employee -- a developer on the Berkeley DB Java Edition and Oracle NoSQL Database teams. I have a question about serialization performance using RMI.

      We've been doing CPU profiling of the client side of an Oracle NoSQL Database app. Our RMI remote method looks something like this:
      Response doClientOperation(Request req)
      The Request and Response objects are both fairly large object graphs, and are Externalizable. Our writeExternal/readExternal methods perform custom serialization and never call writeObject or readObject.

      We're trying to maximize request processing performance, as you can probably guess.

      It turns out that around 6.5% of the client CPU time is used by a single method call, during deserialization of the Response object: ObjectInputStream.readClassDesc. Even though Response is Externalizable, readClassDesc is called as a result of RMI's call to ObjectInputStream.readObject.

      The striking thing is that the cost of readClassDesc overshadows the cost of readExternal, in spite of the object graph being fairly large.

      I was wondering if there is any known trick for avoiding the readClassDesc call, or speeding it up. For example, if there were a way of subclassing ObjectInputStream, perhaps I could do this myself, but I don't see a factory or any other means of subclassing.

      If there is a solution, or future plans for a solution, or even a statement that no solution is planned, I would appreciate knowing that. Sorry if this has already been asked. I couldn't find an answer by searching the forum, but perhaps I missed it.

      Mark Hayes
        • 1. Re: How to avoid readClassDesc overhead
          You're asking in the wrong place. This is a user to user forum. Try the Java developers ... in your company.

          However I have to state that, despite having written a book on it, I wouldn't use RMI at all for this. It's a convenience API, not a down-to-the-silicon performance ball-burner, and it inherits Serialization so you are two levels removed from the actual problem. RMI's conspicuous lack of an SPI, which was widely commented on last century (and ignored by Sun, hence the famous JSR 56/58 debacle), means there is nothing you can do about either.

          You could try RMI/IIOP without too much disturbance of your codebase, but I'm pretty sure you really need a wire protocol of your own, implemented with nothing more complex than DataOutputStream and BufferedOutputStream.

          Author java.rmi
          • 2. Re: How to avoid readClassDesc overhead
            Hello Esmond,

            The OTN forums for Berkeley DB, to which I contribute as a BDB developer, are not just user-to-user. The BDB developers monitor the forums and answer questions. Are you sure this forum is only user-to-user?

            I am aware that the RMI developers work at Oracle. But I would prefer to ask a question about the RMI public API in a public forum so that non-Oracle users can benefit from the discussion. I often ask Oracle internal users of BDB to post to our forum, for the same reason.

            • 3. Re: How to avoid readClassDesc overhead
              You do get the odd Oracle developer around here, but on the whole if you want to attract their attention, this isn't a particularly good place to do that.

              There's a site where you can go (bugs.sun.com) to report bugs and RFEs (of which your post is the latter). It's a bit rickety, but it seems to be up most of the time. Based on things which I've seen languishing without action for years there, I would guess that your suggestion isn't going to go anywhere there, either, but you never know.
              • 4. Re: How to avoid readClassDesc overhead
                Are you sure this forum is only user-to-user?
                Yes. The last time I saw an RMI developer here was about ten years ago. If you're asking questions like 'If there is a solution, or future plans for a solution, or even a statement that no solution is planned' you're definitely in the wrong place.

                If you want to discuss RMI usage and ancient history on the other hand, I am here ;-)