[Nestedvm] Ponderings...

[Thorbjørn Ravn Andersen]

Thorbjørn Ravn Andersen skrev:
> Charles Oliver Nutter skrev:
>
>>>> * adding a function-calling API based on Wayne Meissner's jaffl
>>>> library. He already has a start on this at his github project under
>>>> github.com/wmeissner
>>>>
>>>>       
>>> I am unfamiliar with jaffl, and it appears that all related content 
>>> has been
>>> removed from the kenai website.
>>>
>>> Is this doing the same as JNA or is it a completely different approach?
>>>     
>>
>> Yes, it's basically the same sort of thing as JNA, but an improved
>> design with better performance characteristics. You can find the base
>> jaffl project and the jaffl-nestedvm project on Wayne's github account
>> at http://github.com/wmeissne
>>   
> The paint still appears to be wet.  Is there running code yet?
>
>
>>>> * providing a prepared VitrualBox VM with the toolchain preinstalled.
>>>> This may be available very soon.
>>>>
>>>>       
>>> This sounds like very a good idea.  Personally I use vmware, but I 
>>> believe
>>> there has arisen a standardized distribution format for this.  
>>> Perhaps such
>>> a thing?
>>>     
>>
>> I'm not sure, but I know it's not going to be a VMWare image, since I
>> don't think VMWare images run on anything else. Currently the plan is
>> just straight-up VirtualBox.
>>
>>   
> It appears to be the "Open Virtualization Format" - 
> http://www.vmware.com/appliances/getting-started/learn/ovf.html - 
> which was added in VirtualBox 2.2
>
> http://www.infoworld.com/d/virtualization/sun-launches-virtualbox-22-and-adds-ovf-support-921 
>
>
> Perhaps that is just as easy?  Were you the person to make the image?
>
>
>
>>>> * building the toolchain for MIPS directly, so it can be run on
>>>> NestedVM directly. This will take some time and hackery for sure.
>>>>
>>>>
>>>>       
>>> Self-hosting?  I don't think so.  It will require the complete unix
>>> environment to be up and running, and I also believe I've read that 
>>> there is
>>> an issue with how large a program can be translated and run inside a 
>>> JVM.
>>>  I'm not certain though.
>>>     
>>
>> I think Wayne mentioned that using NIO instead of a real array could
>> increase the size of the memory image, which might make this possible.
>> But yes, the self-hosting goal is a pretty hard one, since you'd need
>> most of the toolchain to be self-hosted as well.
>>   
> Exactly why I suggested essentially moving to emulating standard 
> Debian MIPS/MIPSEL.  Makes the maintainance burden dissapear :D
>
>
>>>> The improvements you suggest all sound very logical. Perhaps we need
>>>> to find someone acting as "lead" of NestedVM to spin up a real bug
>>>> tracker and project site so we can start making a real go at this? The
>>>> success of libraries like sqlite-jdbc show me that this thing has
>>>> legs.
>>>>
>>>>       
>>> Most progress is driven by a concrete need, and I would think that 
>>> the lead
>>> for this endaveour should have one.
>>>
>>> But the idea is sound, any takers?
>>>     
>>
>> I'm hoping to take a wack at using jaffl-nestedvm to bind sqlite3 to a
>> JRuby extension, which might help shake out any early issues. You
>> might be able to help by looking over the jaffl-nestedvm support and
>> trying to use it for something else.
>>
>> Do you have a concrete need driving your interest?
>>   
> Yes.  My need is "rsync in Java", since a headless JVM is the only 
> thing we can be certain of on our target platform.
>
> Since apparently there is no momentum in a Java port of the rsync 
> source, the second best is running a real Unix binary in a Java 
> emulator.   I researched the subject a few years back and at that time 
> NestedVM was the most mature approach to this.  I do not know if that 
> is still true.
>
> But, this might be a lower than llvm entry point for code into a JVM.  
> It might even be usable generically across platforms.  But first we 
> need to get rid of the technical debt. 
Oops, only answered Charles directly.

Bringing in the nestedvm list again :)

-- 
  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"