harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: gc_gen/src/common/gc_for_barrier.h tightly coupled with JNI parts
Date Thu, 03 Apr 2008 00:46:10 GMT
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 <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
View raw message