From dev-return-32649-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Mar 11 15:42:15 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 10779 invoked from network); 11 Mar 2008 15:42:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Mar 2008 15:42:14 -0000 Received: (qmail 19624 invoked by uid 500); 11 Mar 2008 15:42:09 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 19592 invoked by uid 500); 11 Mar 2008 15:42:09 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 19583 invoked by uid 99); 11 Mar 2008 15:42:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Mar 2008 08:42:09 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com designates 209.85.200.171 as permitted sender) Received: from [209.85.200.171] (HELO wf-out-1314.google.com) (209.85.200.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Mar 2008 15:41:33 +0000 Received: by wf-out-1314.google.com with SMTP id 29so2427288wff.24 for ; Tue, 11 Mar 2008 08:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=54C1MULWzG0vk4nQ5GqLxR6WIS/N7dBYvX8T2+ZXwAI=; b=QdT0TofT/RBwUOlBawckWtTA4j/RLeaJxvPNGDU/amGh3lvk2zpH7jCVStVHe5D7FRj70+tLZwLMIcEAGxOQDQpM7z18FqZiAoATYNNpUG8hQARLpZPZHuc1n7qYIvh+qIR4/wF1Mnr1ibbjDeSRHWpt5gK1r3Wll1G+DxwPOds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Xd7KlDhnTAEMdEuA7KmsL+lwdfUbWp/JOIvRkrRjfAvRwcudD/pW6UYDU+WeGSDCmGHxHQ0qYW5gvJeBHxjTkb6oCSMytsL8+yOc8HMCwUb5IciJ5gyN4Azq9qxkU8FqRHZc5vC6c6z5Tz2INv7VnZyiWO+LHe06IAWK2dppkh0= Received: by 10.142.12.14 with SMTP id 14mr2751157wfl.81.1205250103509; Tue, 11 Mar 2008 08:41:43 -0700 (PDT) Received: by 10.67.20.16 with HTTP; Tue, 11 Mar 2008 08:41:43 -0700 (PDT) Message-ID: Date: Tue, 11 Mar 2008 18:41:43 +0300 From: "Alexei Fedotov" To: dev@harmony.apache.org Subject: Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...) In-Reply-To: <9623c9a50803110806x414d0b05p46168dcfb9583752@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9623c9a50803110752p1f942275x741ef39dfb352c15@mail.gmail.com> <9623c9a50803110806x414d0b05p46168dcfb9583752@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Alexey, This is a very interesting thread. Let me give more examples of JNI pro and contra. * JNI is good for implementation of class library native functions, because their arguments are supplied in JNI form. * JNI is a good type system for java-based tools, plug-ins, etc. * JNI is desired to code java specific things like work with local/global references, class loading, finalization, jvmti. We usually put such staff in vmcore. (Class parsing may be an exception because even specification operates in a different notation. From the other side I believe we should build our class parser on the top of something like ASN.1 and get rid of this problem.) As for a current state of our code, I don't think JNI types are good for JIT, Encoder, GC, and an execution manager. They consistently use a different type system and I dream they become usable for other projects, so no need to force them being java specific. As for a porting layer, it consists of two types of functions: * OS and library calls: I believe we should just use *nix APIs and types instead of wrappers and re-implement them for Windows like Cygwin does. First, this is now possible, and second, this just gives us less wrappers. * Assembler wrappers (fences, atomics, monitor instructions, etc): they are too far from java to use JNI. From the other side java.util.concurent mandates JNI atomics, so sometimes JNI is good even here. What do you think? On Tue, Mar 11, 2008 at 6:06 PM, Xiao-Feng Li wrote: > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov > > wrote: > > > > > Consistent type definition is definitely good. Btw, what's the > > > POINTER_SIZE_INT counterpart in port library? > > > > AFAIU > > POINTER_SIZE_INT == UDATA > > POINTER_SIZE_SINT == IDATA > > > > I see. Thanks. > > -xiaofeng > > > > -- > http://xiao-feng.blogspot.com > -- With best regards, Alexei