Hey, interesting discussions. Senaka, Harmony GC doesn't have much JNI related stuff actually. The JNI code you saw was actually for GC helper (written in Java). Uh, then what's GC helper? That's something about to write small GC routines in special Java so that those frequently accessed routines can be inlined into application jitted code. It's completely Java specific and Harmony specific (though the rule should be general to all VM implementations). Please ignore the code related to GC helper for Parrot. They are located under: gc_gen/javasrc gc_gen/resource gc_gen/src/jni
You can exclude jni/ dir for build, and guard any code that refers to code under jni/ with #USE_JAVA_HELPER . Thanks, xiaofeng On Thu, Apr 3, 2008 at 4:43 AM, Senaka Fernando <[EMAIL PROTECTED]> wrote: > Hi Alexei, > > Well, it was just a matter of getting rid of instances of two functions > called inside the JNI layer. As we would not be looking into Java porting, > these are un-wanted as I see. Perhaps we might be able to reconstruct a > barrier layer based on the existing one. However, this depends on the extent > to which the existing one blends into our expectation. > > Of course, the porting to Parrot will make it possible to dissect code into > portions as independent and dependent. This should give us a better picture > on how the Java bridge can be handled, and especially information regarding > ways to reduce coupling. > > Regarding the next-year GSoC project. I think Google wouldn't mind that. > :)... > > Regards, > Senaka > > On Thu, Apr 3, 2008 at 2:02 AM, Alexei Fedotov <[EMAIL PROTECTED]> > wrote: > > > > > Senaka, > > > > It's great you faced this dependency. Do you remember that Xiao Feng > > suggested porting GC which does not need barriers? I believe JNI > > specific parts of this file are to be wasted at this moment. > > > > When you get GC working with Parrot you will have another chance to > > think how to address JNI dependency. Probably one should introduce > > another layer of barrier descriptions. This might be your next year > > GSoC project. > > > > Thanks. > > > > On Wed, Apr 2, 2008 at 9:50 PM, Senaka Fernando <[EMAIL PROTECTED]> > > wrote: > > > Hi all, > > > > > > gc_gen/src/common/gc_for_barrier.h is tightly coupled with JNI parts. > > The > > > reason behind is the reference to jni/java_support.h. This issue > > affects the > > > independent building of the gc_gen after removing the Java components. > > Thus, > > > it is necessary that these go inside a #ifdef block. I would greatly > > > appreciate your opinion. > > > > > > Regards, > > > Senaka > > > > > > > > > > > -- > > With best regards, > > Alexei > > > -- http://xiao-feng.blogspot.com
