harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy" <pavel.reb...@gmail.com>
Subject Re: Make GC_CC working
Date Tue, 11 Dec 2007 11:20:51 GMT
Thank you, Xiao Feng! I think it help us to avoid several problems on
shutdown.

On 11/12/2007, Ilya Berezhniuk <ilya.berezhniuk@gmail.com> wrote:
>
> Thanks a lot, Xiao Feng!
>
> 2007/12/11, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> > I've committed H5247.
> >
> > On Dec 10, 2007 10:21 PM, Ilya Berezhniuk <ilya.berezhniuk@gmail.com>
> wrote:
> > > Xiao Feng, thanks for committing HARMONY-5262.
> > >
> > > But HARMONY-5262 is insufficient to enable GC_CC; tests are often hang
> > > in shutdown.
> > > HARMONY-5247 is also required.
> > >
> > > Who will commit it?
> > >
> > >
> > > Thanks,
> > > Ilya.
> > >
> > > 2007/12/10, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> > >
> > > > I think a reasonable plan for GC_CC is to keep it from regressing
> for
> > > > certain sets of tests such as smoke, kernel, regression. There will
> be
> > > > no further improvement for it. When there is another well-supported
> GC
> > > > in future, say GC_NEW, then we can decide if we still want to keep
> > > > GC_CC.
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > On Dec 10, 2007 9:09 PM, Alexey Petrenko <
> alexey.a.petrenko@gmail.com> wrote:
> > > > > What are our future plans about GC_CC? Do we plan to continue
> support it?
> > > > >
> > > > > SY, Alexey
> > > > >
> > > > > 2007/12/9, Ilya Berezhniuk <ilya.berezhniuk@gmail.com>:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Now we have GC_CC inoperable on most platforms - it works on
> > > > > > Windows/x86/release only.
> > > > > >
> > > > > > I've checked M3 build, GC_CC works fine (although hangs from
> time to time).
> > > > > >
> > > > > >
> > > > > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to
> fix most
> > > > > > of current GC_CC problems.
> > > > > >
> > > > > > The problems are the following:
> > > > > >
> > > > > > 1) After r583223 threading commit GC_CC does not work in debug
> mode
> > > > > > because of multiple assertions.
> > > > > >
> > > > > > 2) After r587472 commit (symbols exporting policy) GC_CC was
> broken on
> > > > > > Linux because several symbols required by GC_CC were not added
> to EXP
> > > > > > files.
> > > > > >
> > > > > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > > > > incorrectly on x86_64 because of changed object layout for 64bit
> > > > > > platforms.
> > > > > >
> > > > > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the
> problem
> > > > > > for GC_GEN, but for GC_CC the problem still exists because of
> > > > > > different GC/Finalizer threads behavior.
> > > > > >
> > > > > >
> > > > > > HARMONY-5247 patch finally fixes the problem with shutdown
> deadlock on
> > > > > > ThreadGroup.lock monitor.
> > > > > >
> > > > > >
> > > > > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > > > > >
> > > > > > With both these patches all 'build test' tests are passed on
> > > > > > Windows/Linux x86 and on Linux/x86_64 in both debug and release
> modes.
> > > > > >
> > > > > > On 4-core Windows/x86_64 I've got 4 intermittent failures on
> debug
> > > > > > build (see details in HARMONY-5262), but these failures are
not
> > > > > > reproducible on release build, and they also do not appear on
> 2-core
> > > > > > machine.
> > > > > > Looks like these failures are caused by some remaining threading
> > > > > > problems in GC_CC.
> > > > > >
> > > > > > Since HARMONY-5262 affects only GC_CC, all tests are passed
with
> > > > > > GC_GEN on all 4 tested platforms.
> > > > > >
> > > > > >
> > > > > > I think it's valuable to make GC_CC working, if we are planning
> to
> > > > > > include it into M4 builds.
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Ilya.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
> --
>
> Ilya
>



-- 
Best regards,
Pavel Rebriy

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