RFR: JDK-8061259: ParNew promotion failed is serialized on a lock

Jungwoo Ha jwha at google.com
Wed Oct 29 22:51:54 UTC 2014


I've looked a bit at the webrev. A couple of comments:
> Why do you use OrderAccess methods for writing and reading the
> _has_promo_failed flag in has_promo_failed() and set_promot_failed() ?

I think that has no effect on x86, but I assumed that processors with weak
memory model may want ordering of set/reset/has call.

Can we write out the full word "promotion" instead of just "promo" in the
> variables and methods?


Can we change the name of the flag from UseCMSFastPromotionFailure to
> CMSFastPromotionFailure? Most CMS flags start with CMS and I don't think we
> need the "Use" prefix.


What do you think about making the flag true by default? At least for JDK
> 9. If we decide to backport to JDK 8 or 7 it might be a good idea to keep
> the default value as false.

Let me know if there is anything for me to do to backport to JDK8 and 7.

Did you find the information provided by _fast_promo_failure_hitcount
> useful for debugging? If it not too useful I would consider removing it
> since it is cluttering up the code a bit.

I removed it.
It was useful to for development, but I think it is no longer needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20141029/722cef51/attachment.htm>

More information about the hotspot-gc-dev mailing list