RFR (S) 8031818: Experimental VM flag for enforcing safe object construction

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Jan 22 11:07:29 PST 2014


Aleksey,

Question first: can you wait about 2 weeks when we merge ppc64 changes?

I was not clear. The enum is not important. What I want is instead of unreadable code like next:

    if (wrote_final() ||
        (AlwaysSafeConstructors && wrote_fields() &&
         method()->name() == ciSymbol::object_initializer_name())
        PPC64_ONLY(|| (wrote_volatile() && method()->is_initializer()))) {

to have

   if (need_membar_on_exit()) {

and

   bool Parse::need_membar_on_exit() {
     return wrote_final() || method()->is_initializer() &&
                             (AlwaysSafeConstructors && wrote_fields()
                              PPC64_ONLY( || wrote_volatile() ));
   }

with comments of cause.

Thanks,
Vladimir

On 1/22/14 1:19 AM, Aleksey Shipilev wrote:
> Thanks, Vladimir!
>
> On 01/22/2014 12:07 PM, Vladimir Kozlov wrote:
>> On 1/21/14 9:10 PM, Vladimir Kozlov wrote:
>>> May be we should use bitset enums to record types of stores to fields.
>
> And the benefit is? I come from the notion Parse is a throw-away
> instance anyhow, do we actually care for additional transient byte of
> footprint per compilation?
>
>>> Next changes touch the same C2 code:
>>>
>>> http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/c6d7e7406136
>>>
>>> It uses method()->is_initializer() instead of (method()->name() ==
>>> ciSymbol::object_initializer_name()).
>
> Copied from C1 code, and I agree "method()->is_initializer()" seems more
> readable, although it also matches the static initializers. Unless there
> is a readability concern, I'd rather leave it as is to match C1 behavior.
>
>>> The main problem that new flag check will be executed always. It will
>>> not be optimized by C++.
>>
>> On other hand we already have experimental flags (for example,
>> AggressiveUnboxing) so it is not big deal.
>
> That's what I'm thinking as well.
>
> -Aleksey.
>


More information about the hotspot-compiler-dev mailing list