RFR: jsr166 jdk integration 2018-02

[Martin Buchholz]

On Thu, Feb 8, 2018 at 10:39 PM, David Holmes <david.holmes at oracle.com>
wrote:

>
> Well at least it's only an issue if there does exist a finalize() method
> that could interfere with the executing method. I have to assume that
> somehow the VM is clever enough that if 'this' is in a register and we will
> later access a field at this+offset, that the GC will not free the memory
> used by 'this'.
>

I expect the opposite, that the VM may see an opportunity to prefetch that
other field.  Maybe it needed to read an adjacent field, and was able to
read both fields with a single instruction.  Maybe escape analysis allowed
it to infer that the object could never be accessed by another thread that
might write to the field.

Even more extreme - in the case of
 newSingleThreadExecutor().execute(someTask);
the VM can do enough analysis to conclude the executor will never be used
after invoking super.execute, so the VM can "optimize" by constructing the
executor, immediately finalizing it, and only then calling the body of
execute.