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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
