Regarding to the fix for JDK-8048556

[李三红(三红)]

Hey folks,

This is San Hong, from Alipay.

We have a fix patch for Bug JDK-8048556  (we signed OCA with Oracle as
Alibaba group) and want to contribute it to OpenJDK.   I would ask here if
there is any interest and anyone can sponsor for this contribution?  Many
thanks in advance.

(I am cc¡¯ing Ben, because  I just mentioned our work when Ben visited China
in May, also welcome your inputs on this)

 

More background information: 

we develop and deploy AlipayJDK which is  based on OpenJDK at Alipay.  We
run the stress performance test for our online systems and found that this
bug really put the performance impact on the rt(response time) of our
system, that¡¯s why we have had to fix it in our JDK7.    

 

The basic idea of fixing is similar with the comments did by Tony in [1],
which needs the right gc counts, but we implemented it in a different way,
as we found it will require a lot of changes if we update the collect()
method on CollectedHeap to accept GC counts.   Instead, the pattern we used
is as follows: 

 

-        Remember the VM operation before initiating the gc£¬the example
code we implemented in VM_GenCollectFullConcurrent::doit()  in
vmCMSOperations.cpp:

 

  if (_gc_count_before == gch->total_collections()) {

    // The "full" of do_full_collection call below "forces"

    // a collection; the second arg, 0, below ensures that

    // only the young gen is collected. XXX In the future,

    // we'll probably need to have something in this interface

    // to say do this only if we are sure we will not bail

    // out to a full collection in this attempt, but that's

    // for the future.

    assert(SafepointSynchronize::is_at_safepoint(),

      "We can only be executing this arm of if at a safepoint");

GCCauseSetter gccs(gch, _gc_cause);

 

#ifdef ALIPAY_JDK

    VMOperationSetter vmop(gch, this);   // VMOperationSetter did the
similar thing with GCCauseSetter, which is used to record which vm operation
is used for current gc.

#endif

 

    gch->do_full_collection(gch->must_clear_all_soft_refs(),

                            0 /* collect only youngest gen */);

  } 

 

-        If the vm gc operation gets interrupted by GCLocker, we will save
it in GC_locker::check_active_before_gc() in gcLocker.cpp

 

#ifdef ALIPAY_JDK

bool GC_locker::check_active_before_gc(VM_GC_Operation * op) {

#else

bool GC_locker::check_active_before_gc() {

#endif

  assert(SafepointSynchronize::is_at_safepoint(), "only read at safepoint");

  if (is_active() && !_needs_gc) {

    verify_critical_count();

    

#ifdef ALIPAY_JDK

    assert(op != NULL, "VM_GC_Operation::doit must invoke
VMOperationSetter!");

    _interrupted_gc_op = op->clone_for_gclocker();

#endif

    

-        Finally, we invoke the saved vm gc operation in
GC_locker::jni_unlock(JavaThread* thread)  instead of calling to
Universe::heap()->collect(GCCause::_gc_locker);

 

#ifdef ALIPAY_JDK

        assert(_interrupted_gc_op != NULL, "VM_GC_Operation must implement
the clone_for_gclocker!");

        VM_GC_Operation* op =
const_cast<VM_GC_Operation*>(_interrupted_gc_op);

        VMThread::execute(op);

        delete _interrupted_gc_op;

        _interrupted_gc_op = NULL;

#else

        Universe::heap()->collect(GCCause::_gc_locker);

#endif            

 

The rationale here is:  the GCLocker is always trying to compensate the gc
operation which has been interrupted while it is active.

(the original implementation is doing the compensation blindly by calling
Universe::heap()->collect for all cases)

 

Your thoughts?   Looking forward to your replay and suggestion!

BTW ¨C this patch passed our local FVT, SVT test suits on linux-xa64
platform, our team can port it to jdk9 as patch for review and also follow
up the tests for other platforms if necessary:)

 

[1]
https://bugs.openjdk.java.net/browse/JDK-8048556?page=com.atlassian.jira.plu
gin.system.issuetabpanels:comment-tabpanel

 

Thanks!

San Hong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150717/f6566baa/attachment.htm>