On 12/4/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 12/3/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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
