On the EagerInitialization VM flag

[Krystal Mok]

Hi David,

Thanks for the reply, David.

When turned on, EagerInitialization is only applied to those classes that
doesn't have a <clinit>()V, which is the case for quite some classes and
interfaces. If implemented correctly, it's supposed to be semantically
safe, because executing a non-existing initializer shouldn't cause side
effects visible from the Java level (but doing linking and verification at
the wrong time is potentially problematic, though).

I wasn't intending to purpose removing the flag and its implementation, but
I'd agree if someone did make such proposal.

- Kris


On Thu, Dec 19, 2013 at 4:26 PM, David Holmes <david.holmes at oracle.com>wrote:

> On 14/12/2013 7:56 AM, Krystal Mok wrote:
>
>> Which is of course true, but not what I really cared about.
>> I'm just curious of the history of what that flag tried to do, and then
>> why didn't it work. Any pointers or hints would be appriciated.
>>
>
> Given its age it is hard to say why it wasn't removed at the time 4292939
> indicated. What it does is force class initialization at class loading
> time. This might have been seen as useful at some point but it violates the
> Java language semantics regarding when class initialization can occur
> (eager loading is allowed, eager initialization is not).
>
> Given eager initialization is likely to break the carefully crafted class
> initialization sequence I don't really see its utility - hence the proposal
> to remove it.
>
> David
>
>  Thanks,
>> Kris
>>
>> On Friday, December 13, 2013, Christian Thalinger wrote:
>>
>>     Well, it’s a develop flag so it cannot be used in the product anyway.
>>
>>     On Dec 13, 2013, at 11:27 AM, Krystal Mok <rednaxelafx at gmail.com
>>     <javascript:_e({}, 'cvml', 'rednaxelafx at gmail.com');>> wrote:
>>
>>      Hi all,
>>>
>>>     Does anybody still remember the history behind the
>>>     -XX:+EagerInitialization flag? It'd be great if someone still
>>>     knows what the flag was for, and why it was to be removed.
>>>
>>>     I saw this bug: https://bugs.openjdk.java.net/browse/JDK-4292939
>>>     which stated that this flag was going away in "the next build",
>>>     but now it's still in the code.
>>>
>>>     Thanks,
>>>     Kris
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20131219/a902bf96/attachment.html