RVM
  1. RVM
  2. RVM-382

Integration of Jikes RVM and JNODE

    Details

    • Type: Task Task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1000
    • Component/s: Infrastructure
    • Labels:
      None
    • Number of attachments :
      0

      Description

      I was lucky enough to meet many of the JNODE developers at FOSDEM '08 and there was a massive shared interest in integrating the Jikes RVM with JNODE. I've tried this a number of times, but we're in the best shape ever to make it happen. There are 2 main problems:

      1) license issues - JNODE is GPLv2 we're CPL
      2) package names

      We currently tackle issue 1 by explicit directory names... It would be good to know if we can do similar for JNODE? I don't see a problem unless we try to mix source from both projects in a single file, which I think we can work around.

      Package names are some what more tricky and we discussed how we should progress things.

      I hope that we can build an integrated JNODE and Jikes RVM runtime structure. I believe such a structure would have packages as follows:

      org.vmmagic - vmmagic unchanged
      org.mmtk - mmtk unchanged
      org.jikesrvm.compilers/adaptive/osr - Jikes RVM compiler system unchanged
      org.jikesrvm.jni - JNI interface that isn't of use to JNODE
      org.vm.scheduler - unified Jikes RVM and JNODE scheduler
      org.vm.runtime - unified runtime support
      org.jnode - JNODE filesystems, device drivers, etc. largely unchanged

      Obviously I've not covered everything with this list, so if people can add to this JIRA I'd appreciate it. Thanks.

        Issue Links

          Activity

          Hide
          Andrew John Hughes added a comment -

          +1

          Who doesn't hate license issues, except lawyers?

          Show
          Andrew John Hughes added a comment - +1 Who doesn't hate license issues, except lawyers?
          Hide
          Tanmoy Deb added a comment -

          hello,
          Ian,
          Thanks for welcoming this matter in our viewpoint. You know someone is trying to invoke some new killer features in JikesRVM in coming sessions and not only for Java Runtime in near future.

          I hope that will open a new door for programmers and developers also in very coming sessions if this works.
          So, always [+1] on this matter or topic.
          Thanks,
          Tanmoy Deb.

          Show
          Tanmoy Deb added a comment - hello, Ian, Thanks for welcoming this matter in our viewpoint. You know someone is trying to invoke some new killer features in JikesRVM in coming sessions and not only for Java Runtime in near future. I hope that will open a new door for programmers and developers also in very coming sessions if this works. So, always [+1] on this matter or topic. Thanks, Tanmoy Deb.
          Hide
          LiGen added a comment -

          Hi Ian, RVM Members and JNode Members,
          Sorry for late.
          First, I should say thanks to RVM and JNode members, I have learn much from you, especially from Ian. Thank you.

          I and my team members are developing a new research Java OS named JUnicorn, which is a single-address-space micro-kernel OS and the process isolated by our new soft-isolated model. JUnicorn is based on RVM, especially RVM's object model and baseline/opt compiler. Right now, JUnicorn can be run on simics successfully, a few services have not implemented completely yet, like file system service which depend on simulation by simics magic instuction. But it will be completed soon.

          During the developing JUnicorn, we have meet the same problem about how to make our system and JikesRVM share code. Our solution is that we directly modify RVM compiler to support multiple JTOC and modify the implement of sysCall/Magic etc, most of these codes are redirected to use JUnicorn's services. We use cn.edu.nudt.junicorn name space to write our os code, which like Mem and IO resource managers, scheduler and other services, then we expand RVM's ant build script to build them, and last use our kernel image builder to combine them into a ELF which can booted by grub. During the development, we try to modify RVM's code as less as we can(except MMTk), this can make us keep updating with RVM. We know that it's not easy to build a consummate dynamic compiler for us.

          JNode is a great Java OS and develop really fast. I think if we can make a interface between RVM and java OS, JNode and JUnicorn will get benefit from it. It's a not mature idea that we can define the interface which like the interface between MMTk and RVM. I have no clear thought now, but I think should define the interface about exception and magic(need scalable) and sysCall, yield points, GC map, more anoniation directed compiled methods, and JNI methods etc.

          LiGen
          National University of Defense Technology, ChangSha, China

          Show
          LiGen added a comment - Hi Ian, RVM Members and JNode Members, Sorry for late. First, I should say thanks to RVM and JNode members, I have learn much from you, especially from Ian. Thank you. I and my team members are developing a new research Java OS named JUnicorn, which is a single-address-space micro-kernel OS and the process isolated by our new soft-isolated model. JUnicorn is based on RVM, especially RVM's object model and baseline/opt compiler. Right now, JUnicorn can be run on simics successfully, a few services have not implemented completely yet, like file system service which depend on simulation by simics magic instuction. But it will be completed soon. During the developing JUnicorn, we have meet the same problem about how to make our system and JikesRVM share code. Our solution is that we directly modify RVM compiler to support multiple JTOC and modify the implement of sysCall/Magic etc, most of these codes are redirected to use JUnicorn's services. We use cn.edu.nudt.junicorn name space to write our os code, which like Mem and IO resource managers, scheduler and other services, then we expand RVM's ant build script to build them, and last use our kernel image builder to combine them into a ELF which can booted by grub. During the development, we try to modify RVM's code as less as we can(except MMTk), this can make us keep updating with RVM. We know that it's not easy to build a consummate dynamic compiler for us. JNode is a great Java OS and develop really fast. I think if we can make a interface between RVM and java OS, JNode and JUnicorn will get benefit from it. It's a not mature idea that we can define the interface which like the interface between MMTk and RVM. I have no clear thought now, but I think should define the interface about exception and magic(need scalable) and sysCall, yield points, GC map, more anoniation directed compiled methods, and JNI methods etc. LiGen National University of Defense Technology, ChangSha, China
          Hide
          Ian Rogers added a comment -

          Thanks LiGen,
          JUnicorn sounds very exciting. I think that modularity is a common theme in this and RVM-405. If you could provide information on where we can improve the modularity it would be useful. As this problem is in two of the Google SoC projects this information can help guide those projects if successful students apply. Perhaps information on how JUnicorn approaches isolates would be useful (and a start) ?

          Show
          Ian Rogers added a comment - Thanks LiGen, JUnicorn sounds very exciting. I think that modularity is a common theme in this and RVM-405 . If you could provide information on where we can improve the modularity it would be useful. As this problem is in two of the Google SoC projects this information can help guide those projects if successful students apply. Perhaps information on how JUnicorn approaches isolates would be useful (and a start) ?
          Hide
          Ian Rogers added a comment -

          The JTOC implementation of JNode and the JikesRVM differ because of JNode's isolate support.

          Show
          Ian Rogers added a comment - The JTOC implementation of JNode and the JikesRVM differ because of JNode's isolate support.

            People

            • Assignee:
              Unassigned
              Reporter:
              Ian Rogers
            • Votes:
              7 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: