RFR/advice: 8054292 : Code comments leak in fastdebug builds

[David Chase]

Correction — we do NOT copy strings out, we instead copy the pointer,
hence the need to zero the strings in the CodeBuffer after a copy-out
if we reclaim non-zeroes strings in the destructor.

> You added _code.free_strings() in C1 but you missed the same case in C2 when compilation is bailed out and strings are not copied to nmethod.

> In scratch_emit_size() you should free strings instead of setting NULL since they are not copied at that place.

I think I will modify the code to do the reclamation in the destructor, because otherwise
I’ll lose track of all the places where the strings go uncopied (and if I don’t, the next guy
will).  There’s many more failure paths than success paths, so it is easier to track success
and zero the pointer after copying, and I can be pretty sure that I have executed the
success paths (but not the failure paths).

Or are you saying that safest is simply to deep-copy always  and always free strings
in the destructor and never set them NULL?

> CodeBuffer::free_strings() should set _Strings to NULL after freeing them.

A side-effect of free_strings is that _Strings.isNull becomes true.
I’ll comment this.

> Indention is wrong in new code - should be 2 spaces.

Will fix.

> And no spaces around arrow:  "cb -> “.

Fixed.

I’ll come around with another webrev after another round of testing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140814/280ff327/signature.asc>