RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to current_end

[JC Beyler]

Hi all,

Small pre-amble to this request:
In my work to try to get a heap sampler in OpenJDK (via JEP 331
<https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to reduce
the footprint of my change so that the integration can be easier. I was
told that generally a JEP webrev should be feature complete and go in
at-once. However, with the change touching quite a bit of various code
pieces, I was trying to figure out what could be separated as not "part of
the feature".

I asked around and said that perhaps a solution would be to cut up the
renaming of TLAB's end field that I do in that webrev. Because I'm renaming
a field in TLAB used by various backends for that work, I have to update
every architecture dependent code to reflect it.

I entirely understand that perhaps this is not in the habits and very
potentially might not be the way things are generally done. If so, I
apologize and let me know if you would not want this to go in separately :)

Final note: there is still a chance JEP-331 does not go in. If it does not,
we can leave the new name in place or I'll happily revert it. I can even
create an issue to track this if that makes it easier for all.

End of the pre-amble.


The 33-line change webrev in question is here:
http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/

I fixed all the architectures and JVMCI and ran a few sanity tests to
ensure I had not missed anything.

Thanks for your help and I hope this is not too much trouble,
Jc

Ps: there is a graal change that needs to happen but I was not sure
who/where to ask about it. I was told it could happen in a separate webrev.
Can anyone point me to the right direction? Should it just be
hotspot-compiler-dev?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180409/4a6010b4/attachment.htm>