harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [arch] Modular JVM component diagram
Date Fri, 02 Sep 2005 14:50:49 GMT
I agree with Tom that APR / POSIX will have some of the functionality
required by the VM and classlibs.

I guess like other VMs, the J9 VM is based on a portable library
(portlib) interface to the underlying OS.  The J9 portlib has the
functionality that you'd expect to see (memory, files, threads, socket,
interrupt mgmt, locks), and some characteristics that you don't find in
APR / POSIX.

The J9 portlib is implemented as a table of function pointers with a
bunch of macros that add syntactic sugar to make it usable.  So a
typical usage in JNI would be something like this:

  jboolean JNICALL Java_java_io_File_deleteFileImpl(
     JNIEnv *env, jobject recv, jbyteArray path)
  {
     PORT_ACCESS_FROM_ENV(env);
     <<snip>>
     result = j9file_unlink(pathCopy);
    <<snip>>
  }

The macro "PORT_ACCESS_FROM_ENV(env)" picks out the portlib struct from
the JNIEnv, so the "j9file_unlink()" macro expands to the right function
pointer invocation.

The advantage of using function pointers rather than linking directly is
that applications can switch in different implementations of functions
"on the fly".

The other difference is that the portlib is self-referential, so the
  j9file_unlink(param)
macro expands to
  portLib->file_unlink(portLib, param)

and so on.  This means that the implementation of file_unlink uses my
definitions of the portlib functions.

If you put these together your "on the fly" function replacements are
cascaded down to the called functions.

This is turning into an essay <g> perhaps I'll continue on the wiki ...

Regards,
Tim


Tom Tromey wrote:
> On Tue, 2005-08-30 at 20:34 +0800, Xiao-Feng Li wrote:
> 
>>Hi, Ron, I think your concern is valid. We fully understand POSIX has
>>been and is being used widely. That's why we want to have a discussion
>>here. APR does have some features a JVM may need in all platforms,
>>such as atomic operations, which are lacked in POSIX. And APR is
>>available on a couple of different platforms. Yes, POSIX is availabe
>>on some non-UNIX systems too, e.g., one can use POSIX on Windows
>>through Windows Services for UNIX or Cygwin.
>> 
>>I'd like to hear how other people think. Folks on the mailing list, comments?
> 
> 
> Using APR makes sense.  In my opinion it should be the way Harmony
> is initially ported.  People who want to do a new port can then port
> APR.  (Or, perhaps they could strip out the APR-using code from Harmony
> and do a "raw" port.)
> 
> Experience with libgcj suggests that OS porting layer has few tricky
> parts[1].  The bulk of the code -- file and network I/O, for instance --
> is simple and porting it doesn't represent a major effort.  I think our
> "posix" port (includes linux, solaris, macos x) is about 4 KLOC.  The
> Windows-specific code is about 5 KLOC.  That's not much.
> 
> Tom
> 
> [1] Turning signals into exceptions is compiler, OS, and chip dependent.
> This qualifies as "tricky" :-).  Another occasionally tricky thing is
> interfacing between the GC and the native thread system -- finding
> stack bounds, noticing thread creation, etc.  I would guess that APR
> doesn't yet have support for these kinds of things, though I have not
> looked.  Note that these are not "pure" OS-dependent areas but are also
> impacted by decisions in other parts of the VM: exception handling
> approach, null pointer detection approach, GC approach, etc.
> 
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message