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