deferred updates? (was Re: value of dense prefix address used?)

[Srinivas Ramakrishna]

Hi Peter, John, Jon -- Thanks!

How about in the very short term, as Peter suggested, and because it is
relatively simple, do the deferred
updates in parallel by all the worker threads claiming the deferred objects
in a "strided" fashion,
and for the longer term try and eliminate the phase, merging it into the
compaction phase by leaving
enough information in the summary table to deal with each fragment by
itself and having an
appropriate interval-aware oop-updater. Or do you feel, John, that the
latter is not that hard and
one might as well do that rather than the intermediate parallelization
(which would be thrown away
once the separate phase is done away with). Thinking a bit more about it,
it does appear
as though the latter may be the way to go. Would it be possible for you to
file a CR so we
have a "handle" by which to refer to this issue, and so this does not fall
between the cracks.
I am happy to help in any way I can, just let me know.

thanks!
-- ramki

On Fri, Mar 2, 2012 at 10:31 AM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:

>
>
> On 3/1/2012 6:06 PM, John Coomes wrote:
>
>> ...
>>
>>  On a related note (see changed the subject line), addressed mainly to
>>> John
>>> Coomes (i think, and may be Jon Masa?),
>>> why do we not update the pointers inside partial objects at the end of a
>>> destination compaction region at the time
>>> that we copy the object, rather than deferring that work for later? Can
>>> something be done about this?
>>>
>> I honestly don't recall why.  It may be as simple as that it will help
>> a little bit, but likely not too much, because the tail of the object
>> that extends onto subsequent regions still has to be deferred.
>> Certainly something can be done, but see below.
>>
>
> It was implemented with the deferred update because that was safe and
> simple.  I battled with
> updating objects split over regions and until I ran out of time.  I
> believe the policy is "if this
> object extends into a region to the left, defer the update".   With a
> little more work the policy
> could be "if the klass word is in a region to the left, defer the update".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120302/31f35c6f/attachment-0001.html