Could the JIT be started before JVMTI agents are loaded?

[Tom Rodriguez]

On Jun 25, 2009, at 10:03 AM, Volker Simonis wrote:

> Thanks for you advice!
>
> We were already thinking to start the compilers before JVMTI has
> posted the VM_INIT
> event but then discard all the compiled methods AFTER the agents have
> been initialized.
>
> We still need to investigate however if it would be enough to just
> recompile the methods after the agents have been initialized or if a
> complete re-initialization of the compiler would be necessary.

You shouldn't have to reinitialize the compilers.  They are fairly  
stateless, except for the stubs and none of them have any JVMTI  
dependencies.  The only thing you have to worry about is whether  
existing generated code was generated appropriately for any features  
that got enabled later.  It's reasonably easy to invalidate all the  
existing nmethods if some feature is needed that wasn't enabled  
previously.  The compiler currently don't record anything about which  
JVMTI features they were compiled to support so you only choice is to  
throw out everything.  If we recorded more info then you could throw  
out only thing which needed to be regenerated.

tom

>
> Thanks,
> Volker
>
> On 6/25/09, Daniel D. Daugherty <Daniel.Daugherty at sun.com> wrote:
>> Alan Bateman wrote:
>>
>>> Daniel D. Daugherty wrote:
>>>
>>>> The compiler is initialized after JVMTI has posted the VM_INIT
>>>> event intentionally. The compiler may have to initialize  
>>>> differently
>>>> depending on the capabilities that were enabled by the JVMTI agent.
>>>>
>>>> Dan
>>>>
>>> We should be in the live phase at this point, do you mean  
>>> capabilities
>> enabled in the onload phase?
>>>
>>
>> I generically mean things done by the VM_INIT event handler
>> in the agent's code. Could be more capabilities, could be
>> other "things".
>>
>> The VM_INIT event marks a specific point in time during VM
>> bringup. Starting the compiler before VM_INIT would not be
>> right because that would change expectations. It might even
>> be a spec violation, but I didn't crack open the spec this
>> AM. Sorry, working on JavaFX stuff at the moment... :-)
>>
>> Dan
>>
>>