Re: [sablevm-jchevm] Windows port

Enrico Migliore <[email protected]> Sun, 09 Apr 2006 12:51:06 +0200
Newsgroups gmane.comp.java.vm.sablevm.devel
Organization -
Message-ID <[email protected]>
Hi,

>Enrico Migliore wrote:
>  
>
>>In any case, I think that the Windows port should rely on the pthread
>>library written for Windows.
>>To speed the execution time, in the future, we might want to inline the
>>pthread functions used.
>>    
>>
>
>Thread functions, by nature, cause a context switch (OS call).  So,
>inlining won't affect performance in any significative way. 
>
I haven't ever made benchmarks of in-line vs non-inline code. I can only 
figure that if the compiler makes an in-line expansion, the program 
won't waste time in building the stack frame and jumping into the function.
If you say so, I trust you :-)

> I would
>much prefer a clean, out-of-vm, thread porting layer.  I am no fan of
>micro-optimizations, specially prior to having things up and running.
>
>  
>
Could you be more specific on the porting layer you've got in mind?
What I would do is:

   1. download the pthread.h header file for Windows
   2. download the pthread-xx-win32 static or dynamic library for Windows
   3. In case of static library, I'd configure the linker to link the 
library
   4. Compile the code

Actually I stick for static libraries whenever I can.


>
>Actually, SableVM only uses a small subset of libffi's functionality.
>I've always dreamt of a libjffi that simply supports JNI types.  We
>could actually do this, so as to simplify porting to new platforms.  All
>that's needed is ABI implementation on a target platform for passign
>around simple types as function arguments.
>
>  
>
You're saying: port just the functions needed, right?
That might require code inspection and calls dependacies checking but 
will save time.

>Now, libffi does work on windows.  I would be much surprised if it
>really required cygwin.  It might not be trivial to compile with
>Microsoft's compiler if it uses inlined assembly.  I should look at the
>  
>
ok.

>source code if it does that or if it uses separate assembly source files.
>
>  
>
>>3. popt source code inspection
>>    
>>
>
>As I said, we don't need to port the SableVM launcher.  Therefore, popt
>is not needed.
>
>  
>
ok

>>I also would like to make a written report of the work in order to allow
>>the port of JCHEVM without re-discovering the wheel.
>>    
>>
>
>Agreed.  You could either use the Wiki as a draft board, or better, we
>should settle the legal thingny so that you put it all into your sandbox.
>
>Could you give a look at:
>
>http://sablevm.org/svn/repository/sablevm/trunk/doc/contribution_policy.txt
>
>If this is something you feel OK with, we'll do the formal things.
>
>Etienne
>
>  
>
I'll read it tomorrow. Thanks,
 Enrico