[aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release

[Thomas Schatzl]

Hi all,

On Tue, 2016-12-20 at 16:37 +0000, White, Derek wrote:
> Hi Martin,
> 
> That's a good point, and one that Thomas has been trying to make to
> me think about: Do all allocation paths need to worry about this?
> 
> If the fast-path allocations done by the interpreter and jitted code
> only occur in young gen regions, and the concurrent collectors never
> look at the young gen concurrently, then CPU -specific code probably
> wouldn't have to worry about it. The fixed code in the runtime slow
> paths would handle all of the problem allocations.
> 
> Note that we have a tower of undocumented and untested assumptions
> about some pretty subtle stuff, that exists in code only as the
> absence memory ordering instructions. :-)
> 
> So it seems that CMS violates those constraints by sometimes doing
> TLAB-like allocations out of the old gen (when concurrent sweep in
> progress?).
> 
> I think 

  I tend to disagree after studying the CMS allocation code.
Allocations in the old gen should always end up in the slow-
path/runtime. Feel free to verify - maybe I overlooked something.

In GenCollectorPolicy::mem_allocate_work, the first part is about
allocation in young gen only (line 600, collectorPolicy.cpp). In the
retry under the Heap_lock the first_only flag may be set to false under
some conditions.
However, the called GenCollectedHeap::attempt_allocation() then
actually checks (after failing to allocate in young) whether it should
allocate in old (Generation::should_allocate()). Which ultimately
returns false, because Generation::supports_tlab_allocation() will
return false for the old gen. Then in genCollectorPolicy.cpp:622, we
end up return NULL (allocation failure) for TLABs to let the caller
retry with allocation of an individual object.

Thanks,
  Thomas