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 Wed, 02 Apr 2008 20:43:18 GMT
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
>

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