[PATCH] enhancement to ParallelScavenge Full GC

[Mikael Gerdin]

Hi,

On 2015-12-14 17:49, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2015-12-14 at 23:57 +0800, ray alex wrote:
>> Thanks, Thomas!
>>
>> I will refine my code carefully according to your suggestions as soon
>> as possible.
>
> Thanks.
>>
>> Since I'm new in contributing to OpenJDK, actually I'm not sure how to
>> upload when my new code is ready?
>>   Just upload an attach of diffs as I did, or some other ways?
>
> The best way as long as we have no confirmation about the OCA signing,
> is to attach a patch (or a webrev, see
> http://openjdk.java.net/contribute/) and send it to this list. Later it
> will be more convenient to send me a patch that I will convert into a
> webrev and put on cr.openjdk.java.net.
>
> As soon as you have two contributions, you can upload patches yourselves
> onto your own account on cr.openjdk.java.net.
>>
>> Besides, I'm currently processing my signed OCA for the committer
>> rights,
>> I'm not sure how long it will take, does it matter?
>
> The OCA is only for us to be able to accept your patch in Hotspot. The
> various levels of contributor status are a different matter, and signify
> your level of expertise within the community.
>
> See also http://openjdk.java.net/contribute/ for more information.
>
>> As for the VM Thread, it does a serial adjust_roots() within the
>> current thread (VM thread) during
>> PSParallelCompact::invoke_no_policy().
>>   I think psCompactionManager.cpp:117 and the surrounding comments
>> confirm the use of VMThread in full GC.
>> Do you agree with my above understanding of the use of VMThread?
>>
> You are right :(
>
> There are multiple options to provide an additional per-thread context:
>
> - passing around some context. Looks like lots of work.

I actually think this is the correct way to go.
In my mind you would only have to change 
ParCompactionMangager::update_contents to pass on the 
ParCompactionManager* through oopDesc::pc_update_contents to 
*Klass::oop_pc_update_contents
It's similar to how the marking phase passes around the current worker's 
compaction manager.

Then the AdjustPointerClosure needs to become a per-ParCompactionManager 
thing and then it's all set :)

/Mikael


> - change the code so that even that serial portion is performed by some
> GCTaskThread (which actually sounds best to me)
> - Another would be to add a field to both GCTaskThread and VMThread, and
> via a virtual method in Thread get the necessary values.
> - make VMThread a WorkerThread (that has an id that can be used to query
> an extra data structure for this cache)
> - others
>
> Let's see if other people have a better idea.
>
> Thanks,
>    Thomas
>
>
>