harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [DRLVM][GC] (HARMONY-2398) patch for GCv5 alloc helper inlining
Date Tue, 05 Dec 2006 18:33:21 GMT
Weldon,
   If the same tests fail without the patch, you could put them in the
exclude list on your dev box and then retry tests with the patch.
JoinlongInt eg., is a known problem. I think the fix( I hope ) is in
2204 which BTW is assigned to you :-)

Rana


On 12/5/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
> On 12/4/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > The new patch is submitted.
> >
> > Weldon, would you please help to commit it? Thanks,
>
>
> build and build test pass on Linux but fail on win32.  The problem is
> tests
> that really have nothing to do with gcv5.  testGetenv and test_Joinlongint
>
> are failing.  I will post a message asking if it is OK to commit any
> changes.  Somewhere I recall reading that no changes should be committed
> if
> build test is failing.
>
> -xiaofeng
> >
> > On 12/5/06, Xiao-Feng Li < xiaofeng.li@gmail.com> wrote:
> > > On 12/4/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > > On 12/3/06, Xiao-Feng Li < xiaofeng.li@gmail.com> wrote:
> > > > >
> > > > > Hi, patch for GCv5 alloc inlining was submitted. This patch has
> also
> > > > > some other improvement in parallel collection.
> > > > >
> > > > > Dear committer, please help to commit it at your early
> convenience.
> > > > >
> > > > > Mikhail, after the patch is committed, would you please have a
> look
> > if
> > > > > the inlining can work well with GCv5 allocation?  Thanks.
> > > > >
> > > > > I don't use two TLS values for the fast path allocation; instead,
> > only
> > > > > one TLS value is used for GC, and it is a pointer to the GC thread
> > > > > local infomation. The code is the same logic as  gc_alloc_fast(
> > )  in
> > > > > file gc_gen/thread/mutator_alloc.cpp and gc_thread.h. (Except that
>
> > the
> > > > > Java code has no large object threshold check, that is only one
> > > > > constant comparison anyway.)
> > > > >
> > > >
> > > > Xiao-Feng,
> > > > I checked the helper's part of the diff.
> > > > I have a question about TLS usage in your code.
> > > >
> > > > You said that you use only one TLS slot to keep the pointer to
> > > > GC_thread_info.
> > > > In this case Java code of the helper is incorrect:
> > > >
> > > >         Address TLS_BASE = VMHelper.getTlsBaseAddress();
> > > >
> > > Oh, my mistake. I should modify the statement below:
> > >
> > > >         Address allocator = TLS_BASE.plus(TLS_GC_OFFSET);
> > >
> > > to be:
> > >            Address allocator_addr = TLS_BASE.plus(TLS_GC_OFFSET);
> > >            Address allocator = allocator_addr.loadAddress();
> > >
> > > Right? I will submit another patch. Thanks for pointing it out. :-)
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > >
> > > >         Address free_addr = allocator.plus(0);
> > > >         Address free = free_addr.loadAddress();
> > > >
> > > > I can fix it by myself after your patch is applied, of you can
> > resubmit the
> > > > patch.
> > > > --
> > > > Mikhail Fursov
> > > >
> > > >
> > >
> >
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>

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