On the EagerInitialization VM flag

[Krystal Mok]

Hi David,

Comments inline below:

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

> On 20/12/2013 12:18 AM, Krystal Mok wrote:
>
>> 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).
>>
>
> Oops! My brain insisted this:
>
>    // abort if the the class has a class initializer
>     if (this->class_initializer() != NULL) return;
>
> was there to skip if there wasn't a class initializer! So everything I
> said was wrong.
>
> This would better be called EagerLinking as it has nothing to do with
> class initialization in the <clinit> sense.
>
> It is still valid as EagerInitialization, because in the end the class's
status will be set to "initialized", so that on first actual use of this
class it'll be magically "initialized" already and doesn't have to do all
the checking and stuff.

Thanks,
Kris


> I believe both loading and linking (and thus verification) can be
> performed eagerly.
>
> David
> -----
>
>  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
>> <mailto: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 <mailto:rednaxelafx at gmail.com>
>>
>>              <javascript:_e({}, 'cvml', 'rednaxelafx at gmail.com
>>         <mailto: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
>>
>>             <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/976409b6/attachment-0001.html