On Thu, Apr 3, 2008 at 6:16 AM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> 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 . Yes, that was what I was actually looking for, will add the patch within the day. I'm building the source in the src directory and have excluded src/jni. Thus, there were 3 errors. This define should sort it out for good. Regards, Senaka > > > 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 >
