< prev index next >

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp

Print this page
rev 58411 : 8241081: Shenandoah: Do not modify update-watermark concurrently

*** 259,269 **** uint64_t _seqnum_last_alloc_gc; volatile size_t _live_data; volatile size_t _critical_pins; ! HeapWord* volatile _update_watermark; // Claim some space at the end to protect next region DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, 0); public: --- 259,269 ---- uint64_t _seqnum_last_alloc_gc; volatile size_t _live_data; volatile size_t _critical_pins; ! HeapWord* _update_watermark; // Claim some space at the end to protect next region DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, 0); public:
*** 429,445 **** uint64_t seqnum_last_alloc_gc() const { return _seqnum_last_alloc_gc; } HeapWord* get_update_watermark() const { assert(bottom() <= _update_watermark && _update_watermark <= top(), "within bounds"); ! return Atomic::load_acquire(&_update_watermark); } void set_update_watermark(HeapWord* w) { assert(bottom() <= w && w <= top(), "within bounds"); ! Atomic::release_store(&_update_watermark, w); } private: void do_commit(); void do_uncommit(); --- 429,451 ---- uint64_t seqnum_last_alloc_gc() const { return _seqnum_last_alloc_gc; } HeapWord* get_update_watermark() const { + // Updates to the update-watermark only happen at safepoints or, when pushing + // back the watermark for evacuation regions, under the Shenandoah heap-lock. + // Consequently, we should access the field under the same lock. However, since + // those updates are only monotonically increasing, possibly reading a stale value + // is only conservative - we would not miss to update any fields. assert(bottom() <= _update_watermark && _update_watermark <= top(), "within bounds"); ! return _update_watermark; } void set_update_watermark(HeapWord* w) { + _heap->assert_heaplock_or_safepoint(); assert(bottom() <= w && w <= top(), "within bounds"); ! _update_watermark = w; } private: void do_commit(); void do_uncommit();
< prev index next >