linux-mips-fnet
[Top] [All Lists]

re:Re: Re: Please try Guava Beta 6

To: mjc@suite.sw.oz.au
Subject: re:Re: Re: Please try Guava Beta 6
From: "Min Wei" <mwei@nortel.ca>
Date: 28 Feb 1997 08:36 EST
Cc: guava@suite.sw.oz.au, paul@suite.sw.oz.au, jp@northpoint.com, "Julian Craddock" <craddock@nortel.ca>
Sender: paul@suede.sw.oz.au
>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? 

        Thanks,
        --min

In message "Re: Re: Please try Guava Beta 6", mjc@suite.sw.oz.au writes:

>Dear Min,
>
>> 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
>example).
>
>>      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.
>
>Regards,
>Michael.
>
>-- 
>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 
>9174
>                                


<Prev in Thread] Current Thread [Next in Thread>
  • re:Re: Re: Please try Guava Beta 6, Min Wei <=