RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

Hiroshi H Horii HORII at jp.ibm.com
Mon Oct 10 14:30:47 UTC 2016


Hi Thomas, David, and all,

> I think you intended to modify cmpxchg_pre_membar not 
> cmpxchg_post_membar!

The previous patch will change only behavior of cmpxchg_pre_membar. But 
the patch is not good to be reviewed (it was not obvious) and Martin 
suggested me to use lwsync rather than sync. 
I created a new webrev. This webrev includes all points that David and 
Thomas pointed also.

http://cr.openjdk.java.net/~horii/8154736/webrev.05/

With this change, callers of copy_to_survivor_space can safely touch 
fields of returned obj because OrderAccess::acquire() is called in 
copy_to_survivor_space when CAS fails.

> Changes in shared code must be algorithmically correct on all platforms. 

> Not just "it will work fine today".
> 
> Given all then work being done to add missing barriers, removing them 
> must come with a detailed analysis establishing the safety of doing so. 
> And I am not seeing that here.

The latest codes in the repository are missing some calls of 
OrderAccess::acquire() before touching fileds of new_obj or o->forwardee() 
in PSPromotionManager::copy_and_push_safe_barrier and 
copy_to_survivor_space respectivey. I believe, this webrev correct them, 
also.

Some methods call forwardee(). However, they don't toruch fields of 
forwardee while copying survived objects to a survivor space.
  PSMarkSweepDecorator::compact()
  PSPromotionManager::process_array_chunk()
  PSPromotionManager::claim_or_forward_internal_depth()

Regards,
Hiroshi
-----------------------
Hiroshi Horii, Ph.D.
IBM Research - Tokyo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20161010/c0a068b2/attachment.html>


More information about the hotspot-compiler-dev mailing list