Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of tromey@redhat.com designates
 66.187.233.31 as permitted sender)
Subject: Re: [arch] Modular JVM component diagram
From: Tom Tromey <tromey@redhat.com>
To: harmony-dev@incubator.apache.org
In-Reply-To: <9623c9a505083005342b4a5ac@mail.gmail.com>
References: <20050819000417.86751.qmail@web41202.mail.yahoo.com>
	 <4305871C.5020200@gatewide.com> <20050819091045.GC27358@dozer>
	 <43065A13.7050006@gatewide.com> <9623c9a50508281806724af91b@mail.gmail.com>
	 <B7CC1D30-C456-45CC-B7D3-C1F716652E5B@braithwaites.net>
	 <9623c9a505083005342b4a5ac@mail.gmail.com>
Content-Type: text/plain
Date: Wed, 31 Aug 2005 11:23:28 -0700
Message-Id: <1125512609.3392.7.camel@mopsy>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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.