I have been doing the thread register verification patches for better Loom debugging, and one of the failures it caught is calling `eden_allocate` with garbage thread register. That method actually shortcuts:
```
void BarrierSetAssembler::eden_allocate(MacroAssembler* masm,
Register thread, Register obj,
Register var_size_in_bytes,
int con_size_in_bytes,
Register t1,
Label& slow_case) {
...
if (!Universe::heap()->supports_inline_contig_alloc()) {
__ jmp(slow_case);
```
...and does not use the thread. But it is still confusing. Other ports gate the calls to `eden_allocate` with `allow_shared_alloc`, x86 should do the same.
(This thing would be cleaner when/if we remove the support for contiguous inline allocs altogether, seeJDK-8290706).
```
void BarrierSetAssembler::eden_allocate(MacroAssembler* masm,
Register thread, Register obj,
Register var_size_in_bytes,
int con_size_in_bytes,
Register t1,
Label& slow_case) {
...
if (!Universe::heap()->supports_inline_contig_alloc()) {
__ jmp(slow_case);
```
...and does not use the thread. But it is still confusing. Other ports gate the calls to `eden_allocate` with `allow_shared_alloc`, x86 should do the same.
(This thing would be cleaner when/if we remove the support for contiguous inline allocs altogether, see