harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xiao-Feng Li <xiaofeng...@gmail.com>
Subject Re: [GSoC] time to close
Date Thu, 20 Aug 2009 08:50:39 GMT
Simon, the summary looks good.

Still, would you like to write a brief doc on  how to turn on your
work and test it? Have you any special test cases developed for the
project?

Thanks,
xiaofeng

On Mon, Aug 17, 2009 at 10:47 PM, Simon Zhou<simon.harmony@gmail.com> wrote:
> Hi Xiaofeng,
>
> I would like to give a brief summary of Concurrent GC weak reference
> supporting project
>
>
>
> 1, Goal
>
>  The main goal of this project is to make the Harmony Concurrent GC process
> weak/soft/phantom reference and finalizable objects properly. Weak reference
> is in java spec and a important feature supported by java languages,
> programmers can use them to give hint to JVM to manage their applications'
> memory.
>
>
>
> 2, Design and implementation
>
> There are 2 major difference between weak references processing in
> STW/Generational GC and that of Concurrent GC.
>
>
>
> First,
>
> we must intercept all the reference.get() invokes to remember the referent
> whose reference is 'leaked out'.
>
>
>
> Second,
>
> the weak/soft reference processing may change the referent's reachability,
> and does not change other part of the object referencing graph. So we can do
> this job concurrently after marking is finished.
>
> On the other hand, phantom reference processing should be after finalizable
> objects processing, while the later one will change the object referencing
> graph. So we should do this job in a STW phase.
>
>
>
> For the first issue, it is necessary before we can move forward to next
> steps., I use 2 different technicals to catch the get() method, one is JNI
> implementation, which is straightforward and easy to implement, but has big
> overhead because of the frequent JNI calls. this implementation can be
> treated like a stepping-stone. The other one is a VMMagic version, which is
> just like the write barrier implementation in current Concurrent GC. By
> modify some passes of JIT, the dynamic compiler will generate a native call
> to the barrier function when compiling java reference.get() method. this
> version of barrier has a low overhead. now, it is default.
>
> For the second issue, which is the main part of this project. I uploaded a
> doc to HARMONY-6258, it describe some details of implementation and I think
> the diagram can explain better.
>
>
>
> 3, Result
>
> All the functionalities and thoughts mentioned in the proposal has been
> implemented, and I have submitted the code patch to HARMONY-6258.
>
> Until now, I mainly used specJbb to evaluate the result, which uses
> weak/soft/phantom reference and finalizable object when creating each of its
> working houses. Besides I use dacapo to do some short-time-run test. I used
> to dump the object info of get() barrier and reference processing phase.
> They work well and correct, and the dump information is just as expected.
>
> As we know, the evaluation of weak reference processing should include the
> enqueue operations. but until now, I have not found a long-time-run (because
> it is a concurrent GC) benchmark which focus on automatically
> and strictly examining when the referent should be dead (it is somehow
> depend on different implementations) and if dead references are all execute
> the weak reference enqueue operations properly. I do have planned to write
> such a test suite and use it to evaluate my project, but it is
> an elaborate work and is not ready yet. Sorry for this, I know it is
> important, and I will finish it before any other improvements.
>
>
>
> 4, Future work and Further ideas
>
> After the implementation of this project, I am thinking of
> some improvement I can do in the future.
>
> A,Benchmark or test suite which focus on weak/soft reference processing
> (heap usages), checking the enqueue operations, finalizing and phantom
> reference.
>
>
>
> B,Now, weak reference processing is done by the last concurrent marking
> thread. When the weak references are only a very small part of the heap,
> this works fine, but when there are lots of weak references to be processed
> in the concurrent phase, the last marker's workload is heavy. To improve the
> load balance, we need a parallel, concurrent weak reference processing phase
> just after the concurrent marking.
>
>
>
> C,I am thinking of if it is possible to implement the resurrect phase of
> finalizable objects processing in a concurrent phase. This may need a more
> complicated write barrier which will only be 'turning on' in resurrect phase
> and a some tracing work for the dirty objects.
>
> Thanks for your great mentoring!
>
> Thanks
> Simon
> 2009/8/17 Xiao-Feng Li <xiaofeng.li@gmail.com>
>>
>> Simon, today is for final "pencil down" and starting the GSoC project
>> evaluation.
>>
>> I've read your doc in Harmony-6258, and reviewed the patch. They look
>> good to me.
>>
>> One thing I want to know is, how you tested your work? what tests did
>> you use to demonstrate your work is correct?
>>
>> Would you please write a doc on the steps to build and test your code?
>> (and upload the test cases you developed?)
>>
>> Thanks,
>> xiaofeng
>>
>> On Mon, Aug 10, 2009 at 8:47 PM, Xiao-Feng Li<xiaofeng.li@gmail.com>
>> wrote:
>> > Simon, thanks.
>> >
>> > I will review your patch and doc. If they are ok, I guess we can call
>> > it a successful project. But the end goal is to commit the code
>> > successfully. :)
>> >
>> > Thanks,
>> > xiaofeng
>> >
>> > On Mon, Aug 10, 2009 at 12:50 PM, Simon Zhou<simon.harmony@gmail.com>
>> > wrote:
>> >> Hi Xiaofeng,
>> >>
>> >>   I have submitted a new patch for Concurrent Weak Reference project.
>> >>   Now, Concurrent Weak Reference for mostly concurrent algorithm is
>> >> ready.
>> >>   Concurrent Weak Reference for STAB algorithm is almost ready, but a
>> >> bug
>> >> only when using concurrent mark & concurrent sweep running after dozens
>> >> of
>> >> GC iterations, I am checking this bug to find the root cause.
>> >>   besides these, I am planning to write a simple doc for the
>> >> implementation
>> >> of concurrent weak reference and will submit with the patch.
>> >>   Is there any other documentations I need provide for concluding this
>> >> project? Thanks!
>> >>
>> >> Thanks
>> >> Simon
>> >> 2009/8/5 Xiao-Feng Li <xiaofeng.li@gmail.com>
>> >>>
>> >>> Simon, thanks for the update.
>> >>>
>> >>> Thanks,
>> >>> xiaofeng
>> >>>
>> >>> On Wed, Aug 5, 2009 at 3:03 PM, Simon Zhou<simon.harmony@gmail.com>
>> >>> wrote:
>> >>> > Hi Xiaofeng,
>> >>> >
>> >>> >   Now, I have completed the WeakReference Processing (get barrier,
>> >>> > weakref,
>> >>> > softref, finalizable, phantomref) for mostly concurrent algorithm.
>> >>> >   For STAB algorithms' implementation is still in debugging (get
>> >>> > barrier,
>> >>> > weakref, softref is OK).
>> >>> >   So I will send a patch included mostly concurrent algorithm
>> >>> > implementation
>> >>> > first.
>> >>> >
>> >>> > Thanks
>> >>> > Simon
>> >>> >
>> >>> > 2009/8/5 Xiao-Feng Li <xiaofeng.li@gmail.com>
>> >>> >>
>> >>> >> Hi, Simon, it is time to conclude your project soon. It is
probably
>> >>> >> good for you to let the community know your current status.
>> >>> >>
>> >>> >> Thanks,
>> >>> >> xiaofeng
>> >>> >>
>> >>> >> --
>> >>> >> http://people.apache.org/~xli
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > From : Simon.Zhou@PPI, Fudan University
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> http://people.apache.org/~xli
>> >>
>> >>
>> >>
>> >> --
>> >> From : Simon.Zhou@PPI, Fudan University
>> >>
>> >
>> >
>> >
>> > --
>> > http://people.apache.org/~xli
>> >
>>
>>
>>
>> --
>> http://people.apache.org/~xli
>
>
>
> --
> From : Simon.Zhou@PPI, Fudan University
>



-- 
http://people.apache.org/~xli

Mime
View raw message