[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.phillim...@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 >
