harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <senaka...@gmail.com>
Subject Re: gc_gen/src/common/gc_for_barrier.h tightly coupled with JNI parts
Date Thu, 03 Apr 2008 04:58:23 GMT
On Thu, Apr 3, 2008 at 6:16 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> 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 <senakafdo@gmail.com>
> 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 <
> alexei.fedotov@gmail.com>
> >  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 <senakafdo@gmail.com>
> >  > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message