>From your email, just make me wonder what's Guava portability
story. I assume you guys are doing to do a Window NT version
as well. How do Guava hide the differnece among NT and Solaris?
Could you put command line option for Guava? So a user could
specify whether he wants a LWP per thread or not. In some cases
(lots of I/O done by a Java thread), a user may want a LWP/thread.
When Guava embedded in native apps, how do we handle per thread
data? Is OS exception per thread as well?
In message "Re: Re: Please try Guava Beta 6", firstname.lastname@example.org writes:
>> Thanks, Michael. Solaris is a bit strange in this case. But as a Java =
>> programmer one does not see it's a Solaris problem but rather a VM =
>> problem. In fact, why don't you create the first thread on VM startup
>> and use it or keep it somewhere? I know it's hack but I thought you =
>> guys are hackers anyway :-). So users would always have Solaris threads ass=
>> ociated with their own LWPs respectively. Users don't need to hack =
>> the Java code if they use a real threading VM!
>> As for some real applications (e.g. Math computation), threads would =
>> not call yield or I/O stuff, i.e. never reach any context switching =
>> point. =
>In fact we do create a new thread before the Java "main" function is run.
>It's actually non-trivial to get Solaris to behave the way you might
>expect it to. It is possible to create a new LWP for each thread, but this
>causes other problems for highly threaded applications.
>Peter Chubb looked at the threading code yesterday after seeing your mail
>and has made some changes to our threading code so that your example program
>behaves in a more sensible way. These changes will be incorporated into our
>next release (unless you really want a package made up now). His changes
>don't solve the general problem, though, which is simply that Solaris threads
>don't always behave in the way you expect.
>I'd like to point out that Guava conforms to the JVM specification as far
>as threads are concerned. The people at Sun who specified Java left the
>choice of a threading model up to implementations. This decision has not
>been met with universal praise, but it's something Java programmers just
>have to put up with.
>> Since we don't have any docs on native API, I wonder if you could =
>> answer some of my questions: =
>> 1. How different is from JDK1.1 native API? Especially the =
>> Object model? =
>JDK 1.1 is backwards compatible - in other words "well written" JDK 1.0.2
>programs should work with JDK 1.1. The definition of "well written" is a
>bit fuzzy, but essentially any programs that were written to conform with
>the API without relying on the particular implementation of the JVM should
>work with 1.1.
>There are no explicit changes to the JVM in 1.1 (e.g. classfiles are
>unchanged, no new bytecodes). However, 1.1 does provide more classes in
>the core Java class library (including introspection and reflection, for
>> 2. Could Guava be embedded in other apps. (e.g. implemented in C)
>Yes, Guava could be embedded in other apps - it's simply a matter of defining
>an API and linking Guava into a library instead of an executable. This is
>certainly possible, but we haven't done it at the moment because we've had
>very few requests for it.
>> 3. Any GC hooks for native code? =
>Yes. Guava has a different native interface than the JDK, but we have
>documentation in the form of manual pages for the functions and a tutorial
>on writing native methods. We are not ready to generally release these
>documents yet, but if you are interested we can probably arrange something.
>> 4. Any way to make a Java object(e.g. a byte array) fixed in
>> memory (i.e. not allowed to move by the GC)? =
>Our GC is a mark-sweep GC, and currently doesn't compact, so the issue is
>somewhat moot (i.e. objects are never moved anyway). However, the answer to
>your question is yes - it is possible to do this using a native method with
>the current version of Guava.
>The imp squinted for a moment. | Michael Cahill
>`Yep,' it said. `That's handwriting, | http://www.softway.com.au/~mjc
>sure enough. Curly bits, spiky bits, | Softway Pty Ltd, PO Box 305,
>all joined together. Yep. Handwriting. | Strawberry Hills, NSW 2012, Australia
>I'd recognize it anywhere.' | Tel +61 2 9698 2322 Fax +61 2 9699