[9] RFR(L) 8166413: Integrate VM part of AOT changes

Christian Thalinger cthalinger at twitter.com
Thu Oct 27 22:02:52 UTC 2016


> On Oct 27, 2016, at 11:44 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> It is very important to integrate with CDS in the future. We’re going to save tons of time if we could pre-link with the class archive. There would be substantially less class resolution and no indirection to get a klass. Same thing goes for heap serialization - direct pointers to strings and possibly other oops resulting from class initialization would be very beneficial.

I’m not disagreeing with any of this.

> This all points in the the direction of an image format the is not an ELF. It would be just be much easier to do.

John and I discussed this before we decided to go with standard formats.  The biggest issue with the current CDS archive is that it’s not relocatable.  That means if the address you want to map at is not available you’re out of luck.  So, the proprietary CDS format needs to become relocatable; pretty much make it a DSO.  And then you’re just reinventing the wheel.  Also, every operating system had decades to tune loading and linking their format while you have to do it yourself.

> 
> igor
> 
>> On Oct 27, 2016, at 1:18 PM, Christian Thalinger <cthalinger at twitter.com <mailto:cthalinger at twitter.com>> wrote:
>> 
>>> 
>>> On Oct 27, 2016, at 9:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>> 
>>> On 10/27/16 11:00 AM, Christian Thalinger wrote:
>>>> 
>>>>> On Oct 27, 2016, at 4:14 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>>> 
>>>>> Thank you, Andrew,
>>>>> 
>>>>> There is no official port of Graal for AArch64 yet. But the work seems started based on your mails on graal mailing list ;)
>>>>> 
>>>>> There are several hardcoded x86 parts in JAOTC have to be fixed. For example:
>>>>> 
>>>>> lines 76-82:
>>>>> 
>>>>> http://cr.openjdk.java.net/~kvn/aot/jaotc.webrev/src/jdk.aot/share/classes/com.oracle.graal.aot/src/com/oracle/graal/aot/CodeSectionProcessor.java.html <http://cr.openjdk.java.net/~kvn/aot/jaotc.webrev/src/jdk.aot/share/classes/com.oracle.graal.aot/src/com/oracle/graal/aot/CodeSectionProcessor.java.html>
>>>>> 
>>>>> lines 392-400:
>>>>> 
>>>>> http://cr.openjdk.java.net/~kvn/aot/jaotc.webrev/src/jdk.aot/share/classes/com.oracle.graal.aot/src/com/oracle/graal/aot/CompiledMethodInfo.java.html
>>>>> 
>>>>> And jaotc ELF interface code.
>>>> 
>>>> Btw. are we still planning to replace the ELF requirement with a Java solution?  If yes, is there an RFE for that?
>>> 
>>> Filed https://bugs.openjdk.java.net/browse/JDK-8168858 <https://bugs.openjdk.java.net/browse/JDK-8168858> <https://bugs.openjdk.java.net/browse/JDK-8168858 <https://bugs.openjdk.java.net/browse/JDK-8168858>>
>>> 
>>> It is not clear what container format we should use or may be simple integrate with CDS. We start discussing it because we can't use ELF on all other platforms.
>> 
>> In my opinion (and John’s, IIRC) moving towards a CDS solution is the wrong direction.  CDS has too many restrictions to work reliably for compiled code.  I would much rather see CDS moving more towards DSOs.
>> 
>> SubstrateVM is using some kind of Java library that is able to write DSOs for different operating systems.  Maybe we can open source that library and start integrating it.	
>> 
>>> 
>>> Vladimir
>>> 
>>>> 
>>>>> 
>>>>> Hotspot changes are not simple but platform specific mostly.
>>>>> 
>>>>> Regards,
>>>>> Vladimir
>>>>> 
>>>>> On 10/27/16 2:09 AM, Andrew Haley wrote:
>>>>>> On 27/10/16 02:15, Vladimir Kozlov wrote:
>>>>>>> Please, review Hotspot VM part of AOT changes.
>>>>>>> 
>>>>>>> Only Linux/x64 platform is supported. 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
>>>>>> 
>>>>>> Of course I'll port this to AArch64 asap.
>>>>>> 
>>>>>> Andrew.



More information about the hotspot-dev mailing list