RFR: Proposed jimage refresh for JDK9

[Jim Laskey (Oracle)]

[Have been OOTO]

I have a cunning plan.  However, getting this jimage refresh in play has me really bogged down (there is always one more thing -- curse you Jobs.)

I do plan on moving the bulk of the jimage JVM_ calls to the JDK. The callbacks into the VM will be reduced to a few calls (open, close, read, read_compressed) and will be VM style correct.

Cheers,

— Jim





> On May 26, 2015, at 2:03 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> 
> On 5/26/15 10:25 AM, Alan Bateman wrote:
>> 
>> On 26/05/2015 15:18, Coleen Phillimore wrote:
>>> :
>>> 
>>>> 
>>>> In any case, I don't think the JVM functions are a supported interface so we shouldn't need a CCC.
>>> 
>>> We need CCC to remove the JVM functions so I assume we need one to add them.
>> Okay although JVM_* functions have never been a supported interface (to my knowledge anyway).
>> 
> These are the current rules, which assume that even though unsupported, these interfaces are known to our customers and licensees.
>> 
>>>> 
>>>> Also I think we need to see where this is going longer term, my preference would be to move these JVM_* functions out of the VM and put the jimage support in its own libjimage.so. I realize this requires mmap and other support that might be tied a bit to VM options but I think we should at least explore it.
>>> 
>>> I think this functionality should be in Java.
>> We might be talking different issues here, I assume you need a minimal native implementation to startup.
> 
> Yes.  It seems wasteful to have the JDK code call back to the JVM for this, and then we have new JVM functions to support (and have to file CCC requests if we remove them).
> 
> Thanks,
> Coleen
> 
>> 
>> -Alan
>