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
>
>