[9] RFR(M): 8054292 : code comments leak in fastdebug builds

Vladimir Kozlov vladimir.kozlov at oracle.com
Sat Aug 23 01:08:10 UTC 2014


On 8/22/14 5:43 PM, David Chase wrote:
>
> On 2014-08-22, at 6:47 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> There is some missmatch of use #ifdef ASSERT and #ifndef PRODUCT.
>> Please, build 'optimized' JVM in addition to 'product' and 'debug’.
>
> Optimized VM is running my matrix-multiplication experiments happily, will also do jtreg, didn’t JPRT also do that for me?
> I can certainly do jtreg with the optimized build.

Okay.

>
>> Seems _defunct field should be DEBUG only since it is checked only in assert. It could be NOT_PRODUCT bu in that case set_null_and_invalidate() should clean both fields under #ifndef PRODUCT.
>> isNull() will return 'true' in NOT_PRODUCT (optimized VM) when assign() may set _strings.
>
> John also wants it to be spelled is_null, and I just overlooked it and use JavaConventions.
> I was planning to have all the probe methods do as little as possible in PRODUCT.
> I agree, _defunct should also be DEBUG (is that the same as ASSERT?) only.

Yes:

#ifdef ASSERT
#define DEBUG_ONLY(code) code

>
>> An other thing  I don't like in current code is the same name of _strings fields in both CodeStrings and CodeBuffer. It is difficult to follow which one is accessed in a code.
>
> Do you recommend that I fix that, then?  I also did not like this, but thought it was house style.

It is not "house style".

> I propose to call the CodeStrings-typed field of CodeBuffer “_codestrings”.

Agree.

>>> One client of CodeBuffers allocates them without running their constructor,
>>> which interfered with enabling the full set of assertions that we might like.
>>
>> It would be nice to fix it - call constructor in that place. Where it is? You can try to do what we do in growableArray:
>> new(&_strings) CodeStrings().
>
> I’m trying to recreate that failure; it may be Linux-specific (it failed on Linux, but did not fail for me on Mac just now, this seems peculiar and even more unsettling).
>

Thanks,
Vladimir


More information about the hotspot-compiler-dev mailing list