> > Steve, if the spokes were in Java but the hub in C, would we then lose > > all of the aggressive inlining benefits that Java-in-Java solution can > > provide? > > I don't know. These are really interesting questions and ones I think > we need to hear lots of informed opinion on. My experience with mixing > C & Java inside the VM is limited to the interface to the MM. The > inlining issue is key there because of the fine grain at which those > interactions occur. Scheduling, compilation and classloading are very > much coarser grained, so those issues are much less critical there...
To me the biggest challenge in mixing Java and C in a VM is the heap management issue. I can see several approaches, none of which are particularly palatable to me: a) C code uses its own heap (malloc), and regards the Java heap as read-only, and locks out the GC while it reads Java data. b) Use conservative GC for vm-internal data c) C code disables GC, and guarantees only to leave valid java objects on the Java heap. For example, suppose the classloader is written in Java, and leaves bytecode objects on the Java heap. Then you have an opt compiler written in C, which needs to access them. Using (a), you disable GC, malloc some heap for a copy of the bytecode, then re-enable GC. Then the compiler runs, produces some machine code, disables GC and copies it back to the Java heap. Then cleans up its own intermediate data structures ... It sounds like unnecessay complexity to me. Robin
