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: local policy)
Date: Fri, 18 Aug 2006 20:14:55 +1000
From: Robin Garner <robin.garner@anu.edu.au>
Subject: Re: [drlvm][vm, mmtk] adding thread-local storage functionality to
 vmmagic
In-reply-to: <uwt96d2ey.fsf@gmail.com>
To: harmony-dev@incubator.apache.org
Message-id: <44E5931F.2010503@anu.edu.au>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <4dd1f3f00608161412l6fae05afm48b73b864d61b842@mail.gmail.com>
 <u1wrfetgg.fsf@gmail.com>
 <4dd1f3f00608170541of0093f0g82ebbc89f4289059@mail.gmail.com>
 <bc79dd600608170610p4046d1a8pe8fcbba0ce95e772@mail.gmail.com>
 <uwt96d2ey.fsf@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)

Egor Pasko wrote:
> On the 0x1C8 day of Apache Harmony Mikhail Fursov wrote:
>   
>> Egor,
>> Why do you think we need to support platform specific issues in helpers? Is
>> there any example that shows that we can't write a helper without reference
>> platform details? 
>>     
>
> It depends on how much of a helper code we want to write in Java. We
> can always say: "hey, this is platform-dependent, let it be a whole
> vmmagic and let JIT take care". If it is a large piece of code,
> it is not good to code it down in JIT IR(s) and is better written in
> Java. I think, we all agree here.
>
> As a 1 more example ... maybe some day we decide to inline fast-path
> of spinlocks. 
>
> Which is a) a helper b) is platfrom-dependent. 
>
> Implementing fast-path-spins in JIT IR is not a lot to do. But
> specifying the interface and updating all components (JITs) to handle
> that way of interaction on all platforms .. may make a burden. Coding
> spin-locking in Java would make it difficult to write optimal (think of
> explicitly parallel architectures...)
>
> Both approaches seem to be quite complicated here. But all-in-JIT
> approach seems to have more chances to be faster here.
>
> Thus, it would be good to have both:
> * vmmagic (inlined by JITs)
> * helpers (partially) written in Java (using vmmagic)
> and decide how fine-grained those magics should be depending on
> specific situation.
>
>   
>> I think we should avoid #ifdef's in Java as much as we can.
>>     
>
> Yes, my vision is the same. At least, until we come accross a large
> piece of system-dependent code that is good to be inlined by JIT. I
> think, it is not likely to happen, large pieces of code tend to work
> longer :) and inlining them does not give so much benefit..
>
>   
Jikesrvm uses "//-#if" style constructs for platform-specific codes, and 
it's something we are working hard to get rid of.  I think it's 
something you should definitely avoid at all costs.

One possible alternative is to use annotations instead, and the 
preprocessing infrastructure that goes with them.  But it's always 
better to try to abstract over the particular concern somehow.

As a last resort, write platform-specific versions of whole classes, and 
selectively include them at compile time.  Of course chase down the 
platform specific bits so they are as small as possible.

My thoughts on the thread-local storage issue is that it's a more 
general issue of accessing shared data structures from the Java side of 
the fence.  So perhaps a method such as

Object org.vmmagic.utility.accessVmStructure(<identifier>)

or even better, declare object instances with a pragma annotation

@IntrinsicDataStructure("name")
MutatorContext myMutatorContext;

and the compiler generates code to fetch the address.  Has better type 
safety, potentially.

-- robin

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org