2 Replies Latest reply: Mar 31, 2009 2:47 AM by 843810 RSS

    JVMTI agent to load a different .class file format

    843810
      I meet some difficulties about JVMTI and bytecode transform.

      I'm using JVMTI to load some different formats of .class file.
      It begins with magic number 0xdeadbabe instead of original Java's
      0xcafebabe and some different following byte chunks.

      Now, I use a callback to handle JVMTI_EVENT_CLASS_FILE_LOAD_HOOK event
      and transform received bytes content into original Java bytecode
      format.

      At first, this method works with Hello World and some toy examples.
      However, when it works with a real game server, something wrong
      happens: The jrockit JVM reports a class named "ItemManager" with an
      invalid magic number and stop to load. But when I use the same agent
      to run ItemManager directly, no such an error happens.: JVM only
      complains about no main method.

      To make things worse, I see from log the "ItemManager.class" is loaded
      not from my callback of JVMTI_EVENT_CLASS_FILE_LOAD_HOOK at all. It
      comes from somewhere else. so the 0xdeadbabe magic number and
      different format will certainly not be correctly loaded :-(

      Is there other way JVM load .class that bypasses the
      JVMTI_EVENT_CLASS_FILE_LOAD_HOOK callbacks, or the use of reflection
      or AspectJ will also cause the problem?

      Please give me some suggestion and hint. Thanks a lot :-)
        • 1. Re: JVMTI agent to load a different .class file format
          843810
          zhangyuan wrote:
          I meet some difficulties about JVMTI and bytecode transform.

          I'm using JVMTI to load some different formats of .class file.
          It begins with magic number 0xdeadbabe instead of original Java's
          0xcafebabe and some different following byte chunks.
          Why do you want to change the magi number? What is the reason to
          change this?

          >
          At first, this method works with Hello World and some toy examples.
          However, when it works with a real game server, something wrong
          happens: The jrockit JVM reports a class named "ItemManager" with an
          Have you tried the Sun JVM? Try it and let us know the results.
          • 2. Re: JVMTI agent to load a different .class file format
            843810
            zhangyuan wrote:
            I meet some difficulties about JVMTI and bytecode transform.

            I'm using JVMTI to load some different formats of .class file.
            It begins with magic number 0xdeadbabe instead of original Java's
            0xcafebabe and some different following byte chunks.

            Now, I use a callback to handle JVMTI_EVENT_CLASS_FILE_LOAD_HOOK event
            and transform received bytes content into original Java bytecode
            format.

            At first, this method works with Hello World and some toy examples.
            However, when it works with a real game server, something wrong
            happens: The jrockit JVM reports a class named "ItemManager" with an
            invalid magic number and stop to load. But when I use the same agent
            to run ItemManager directly, no such an error happens.: JVM only
            complains about no main method.

            To make things worse, I see from log the "ItemManager.class" is loaded
            not from my callback of JVMTI_EVENT_CLASS_FILE_LOAD_HOOK at all. It
            comes from somewhere else. so the 0xdeadbabe magic number and
            different format will certainly not be correctly loaded :-(
            Can you determine how the class `ItemManager' was loaded? i.e. where is
            `somewhere else'?

            >
            Is there other way JVM load .class that bypasses the
            JVMTI_EVENT_CLASS_FILE_LOAD_HOOK callbacks, or the use of reflection
            or AspectJ will also cause the problem?

            Please give me some suggestion and hint. Thanks a lot :-)
            If the format difference is only the magic number and the following bytes, maybe
            you don't need to use a solution like jvmti to do the transformation.