RFR: Proposed jimage refresh for JDK9

[Karen Kinnear]

Folks,

We have concerns with the current jimage design relative to the JVM interfaces. We need to investigate alternative approaches here,
including a libjimage.so analogous to libzip.so that would be called directly from both the JDK and the jvm. Some have suggested having most of the logic
be in java. We are concerned about checking in JVM_* interfaces that will should go away soon and concerned about licensees and other java vendors
adopting them making them harder to remove the longer they are there.

Jim has explained that it is critical to get these changes in quickly so that the IDEs can get the updated jrtfs APIs, and that it is a huge amount
of work to decouple the API changes from the jimage changes or to make the requested jimage interface changes.

Assuming it is critical for these changes to go into JDK9 immediately rather than fixing the design issues first -
We propose adding the JVM_* interfaces as deprecated when they go in.
We would like commitment from Jim and those setting priorities for the jimage work that the changed design and JVM_* interfaces will be in the next
set of changes coming from his team.

If this is a problem due to priorities or staffing, can you please talk to us about that now?

thanks,
Karen

On May 27, 2015, at 8:49 AM, Jim Laskey (Oracle) wrote:

> [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
>> 
>