Re: Keyboard mnemonic problem

[Christopher Smith]

On Thu, 11 Feb 1999, Jackie Manning wrote:
> On my system, RH 5.1 updated to 2.0.36, jdk1.1.7-v1a, keyboard mnemonics
> do not function.  The same
> programs function properly on my laptop, RH 5.1 - 2.0.35, jdk1.1.7-v1a.
> 
> Can anyone give me a clue where to look for the problem?
I've got a friend who's got the same problem. I haven't looked at his
system carefully, but from preliminary tests, it appeared as though his
XBD was not setup properly.

--Chris

Re: Keyboard mnemonic problem

[Christopher Smith]

>What's an XBD?
The X keyboard extension.

--Chris

Re: Keyboard mnemonic problem

[Christopher Smith]

On Fri, 12 Feb 1999 [EMAIL PROTECTED] wrote:
> Whenever I start Motif applications on my linux box the [RETURN] does not 
> work, but strangely enough Control-J work. I basically have given up.
> 
> Does XBD (X keyboard extension) cure this problem ?
> How can I see XBD ?
This sounds like it might be related to your Xwindows setup (and therefore
XBD), although I'm a little suspect about why it only happens with Motif
apps.

Keep in mind, that you don't have to use XBD. However, it's the "new and
improved" way of doing things, so most distributions default to setting it
up.

--Chris

Re: Unidentified subject!

[Christopher Smith]

On Tue, 23 Feb 1999, Jason Meisel wrote:
> HI i am working on a senior project using RMI and Servlets  on a linux os 
> running on a i86 machine... i have installed the jdk, jre, and rt, and have
> adjusted the PATH to reflect where to look... 
> my problem is...
> when i type :  javac Hello.java
> it says cannot find library path... have you any ideas what might be the 
> problem?  
Looks to me like you need the Java Servlet Development Kit still. Unless
your Hello.java uses that, then I'm not sure what your problem is. If you
are using the latest JDK 1.1.x it should find the class libraries or you.
You could try setting your CLASSPATH environment variable, but tht should
no be necessary.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

New site for doing Java on Linux jlinux.org

[Christopher Smith]

Hi there. I have collected various bits of info on running Java on
Linux and decided to put it all together on a site. It's still very
early on, so there isn't a ton of information, but I'd love to hear
feedback from people. It can be found at:

http://www.jlinux.org/

Please note that I'm aware that the site has zero cosmetic value. ;-)
I'll address that sooner or later, but right now I just wanted to get
the info up.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New site for doing Java on Linux jlinux.org

[Christopher Smith]

On Thu, Jan 06, 2000 at 07:59:55PM -0500, Jacob Nikom wrote:
> Very good idea. However, how to separate Java from Java/Linux from
> Linux? Java/Linux from PC? Are you going to have different pages
> for those topics?
I'm not sure what you mean. Do you mean to break the information up
into sections according to these categories:

a) Java info
b) Java & Linux info
c) PC info

If so, my intention was to specifically point Linux developers in the
direction of tools/info that would help them develop Java. If those
tools/info help other developers for Java or other developers for
Linux, so be it, but lots of other sites provide that info as
well, and they undoubtedly have more detailed information.

I've done 2 presentations now about doing Java on Linux, and I field
questions about it all the time, so I figured this was a specific
problem that people have a lot of questions about.

Does that answer your question, or did you have something else in
mind?

--Chris
 PGP signature

Re: jasmin

[Christopher Smith]

On Fri, Jan 07, 2000 at 10:06:20PM +0700, yangyuexiang wrote:
> I download jasmin. It generated HelloWorld.class file.
> But I cannot run java HelloWorld.
> 
> Is it due to the version of java?
> I use Sun/Inprise version java for linux.
The Sun/Inprise version should be fine. What is the error message you
are getting?

--Chris

 PGP signature

Re: jasmin

[Christopher Smith]

On Sat, Jan 08, 2000 at 10:07:31AM +0700, yangyuexiang wrote:
> Exception in thread "main" java.lang.NoClassDefFoundError: HelloWorld (wrong
> name: examples/HelloWorld)
>  at java.lang.ClassLoader.defineClass0(Native Method)
>  at java.lang.ClassLoader.defineClass(ClassLoader.java:442)
>  at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:101)
>  at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>  at java.net.URLClassLoader.access$1(URLClassLoader.java:216)
>  at java.net.URLClassLoader$1.run(URLClassLoader.java, Compiled Code)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at java.net.URLClassLoader.findClass(URLClassLoader.java, Compiled Code) at
> java.lang.ClassLoader.loadClass(ClassLoader.java, Compiled Code)
>  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java, Compiled Code)
>  at java.lang.ClassLoader.loadClass(ClassLoader.java, Compiled Code)
Looks to me like you are typing in:

java examples/HelloWorld

instead of:

java examples.HelloWorld

In the future, try including what you typed in and the error message
from the get go... it makes it easier to figure out what's going
wrong.

--Chris

 PGP signature

Re: Which Linux JVM is better?

[Christopher Smith]

On Mon, Jan 10, 2000 at 10:00:55AM -0500, James Caple wrote:
> For what it's worth, my experience has been that the Blackdown RC3 port is
> much more scaleable and stable than the Inprise Linux port.  I'd place my
> bets on the Blackdown port for server-side performance and scaleability.
> Although somewhat slow in porting, Blackdown is doing a very thorough job.
> 
> My comments are based on tests using green threads without a JIT, at the
> moment.
While I might agree with you about stability, as far as scalability
goes, you need native threads to be able to being to test that. I
suspect the two are relatively similar. My main plug for the Inprise
port is that it has better debugging support, which is a big deal to
me.

--Chris
 PGP signature

Re: JVM hang

[Christopher Smith]

On Fri, Mar 31, 2000 at 08:14:47AM -0500, John Rousseau wrote:
> On Friday Mar 31, 2000, Natarajan SK wrote:
> Kevin Hendricks solved a very similar problem for me. This is
> assuming that you are using native threads. Try linking in -lpthread
> explicitly on your link line (and make sure you don't have an
> explicit -lc before it).
>
> This is because you may be picking up the non-thread safe versions
> of libc routines.

I am confused, I thought all you needed to do use the right routines
was to use -DREENTRANT.
 
--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JVM hang

[Christopher Smith]

On Fri, Mar 31, 2000 at 05:30:52PM -0500, John Rousseau wrote:
> On Friday Mar 31, 2000, Christopher Smith wrote:
> > On Fri, Mar 31, 2000 at 08:14:47AM -0500, John Rousseau wrote:
> > > On Friday Mar 31, 2000, Natarajan SK wrote:
> > > Kevin Hendricks solved a very similar problem for me. This is
> > > assuming that you are using native threads. Try linking in -lpthread
> > > explicitly on your link line (and make sure you don't have an
> > > explicit -lc before it).
> > >
> > > This is because you may be picking up the non-thread safe versions
> > > of libc routines.
> > 
> > I am confused, I thought all you needed to do use the right routines
> > was to use -DREENTRANT.
> 
> Unfortunately not. The Blackdown folks are/were considering adding
> wrappers to their native threads library (libhpi.so) so that it
> would pick up the correct versions. Currently you need to be careful
> about your link line.

Ok. I'm confused. This is from the glibc notes:

 - Macro: _THREAD_SAFE
 If you define one of these macros, reentrant versions of several
 functions get declared.  Some of the functions are specified in
 POSIX.1c but many others are only available on a few other systems
 or are unique to GNU libc.  The problem is that the
 standardization of the thread safe C library interface still is
 behind.

 Unlike on some other systems no special version of the C library
 must be used for linking.  There is only one version but while
 compiling this it must have been specified to compile as thread
 safe.

Is the problem actually with glibc or is it with libhpi?

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: high performance I/O?

[Christopher Smith]

On Wed, May 10, 2000 at 11:16:56AM -0700, Matt Welsh wrote:
> No. I want to wrap a *C array* as a Java object - not the other way around.
> What you are talking about is getting a C pointer to a Java object.
> Not the same thing!

Oh, I misunderstood. My apologies. Yes, the reverse would be REALLY
nice. Given Java's bounds checking though, at best it'd have to be
some kind of struct, rather than a raw pointer.
 
> Also, in the case of GetArrayElements(), the JVM does not
> promise not to copy the data -- and copying kills your performance.

The JVM has the option of copying or pinning, at it's discretion. This
is actually a good thing, IMHO, because if the array is small enough
copying may be significantly more advantageous than pinning down the
array structure. The interface does let you know if you got a copy or
not so you know if you have to post the update back to the JVM. In
theory at least, the JVM should know the copy/pin performance
tradeoffs better than a developer.

--Chris


 PGP signature

Re: Thread and Garbage collection

[Christopher Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, May 17, 2000 at 11:27:00AM +0700, yangyuex wrote:
> I have several threads in one hashtable.
> When I remove one of them, whether this thread still  consume CPU etc
> resources?
> That's to say, if I will not need one thread, whether I must stop or
> destory it explictly or
> just remove it from hashtable for garbage collection?
> I am not sure how JVM schedules multiple threads.

Before the Thread can be garbage collected, it must stop
executing. The Java API docs for java.lang.Thread describe the
different circumstances under which this can occur. Beyond that, there
must not be a reference to the Thread instance which is accessible
from any other Thread which hasn't completed execution.

- --Chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard 

iD8DBQE5IjUGfrrCpthD+UYRAr5kAJ9n5TmYaMe8p4btEN3izar9ZTvBwACg2QtS
GUTzvgrlAoCjUZ7On2U7akE=
=auUr
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Thread hangs, signals and JNI

[Christopher Smith]

>If you make sure, you do not mask your SIGUSR1 and SIGUSR2,
>you should be able to run fine. However, there is one caveat. Linux
>threads use SIGUSR1 and SIGUSR2 for their internal
>communication in some products. If your >product also uses them,
>you should see for alternatives.

Actually, I believe the Linux thread support in glibc no longer uses SIGUSR1
& 2.

It's more likely his problem is coming from masking all those signals (bad,
bad, bad) which the JVM needs to have available to it.

The AOLServer's sigwait() is essentially the source of your problems. I'm
not sure how you'd fix it, as I'm not familiar with the AOLServer code.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Thread and Garbage collection

[Christopher Smith]

On Thu, May 18, 2000 at 10:15:08AM +0700, yangyuex wrote:
> Thanks very much!
> 
> What's your mean:
> 
> "which BTW
> sets  *INTERRUPTED* flag in the Thread object,
> The use of the an instance variable is redundant since the thread
> already has
> a flag designed for that perpose."
> 
> I also think this is a feasible way.
> Because I think the root for garbage collection are
> implementation-dependant.
> Depending on the implementation and support for native methods,
> roots for garbage collection may be contained in:
> 
> o All pointers in all stack frames of the stacks of all JVM threads.
>   These include pointers in the local variable areas of the frames
>   and pointers in the operand stacks of the frames.
> 
> o All pointers to static fields of classes in the class and method
>   area of the JVM.
> 
> o native methods,

Native methods themselves do not provide roots, but the JNI interface
does define semantics for effectively adding objects involved in a JNI
invocation to the root set.
 
> o registers of the JVM (for optimization)

Well the JVM doesn't really have registers, it's just got a stack. ;-)
Seriously though, a lot of JVM's use conservative GC which makes it
possible for objects to be marked as reachable despite the fact that
they aren't.
 
> From here, I think there is no way for the GC to collect an alive thread
> although there is no reference  refer to it.

Actually, if a thread is still alive there is still a pointer to it,
otherwise, how could the Thread.enumerate() find it? ;-)

> So, by interrupt method here, which force run() method to finish, which
> is a safe way to make the thread dead.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: high performance I/O?

[Christopher Smith]

On Wed, May 10, 2000 at 01:10:20PM +0100, Miles Sabin wrote:
> Matt Welsh wrote,
> I guess that in principle it ought to be possible to tweak
> JVMs to special-case a priviledged class of byte[]s to allow
> them to be pinned for an extended interval without completely
> screwing GC, but I'm not at all clear at the mo' how that could 
> be done. By the look of it the latest rev. of Jaguar might
> give me some answers.

I could swear you can actually do this with JNI. From the JNI spec:

"...Second, programmers can use another set of functions to retrieve a
pinned- down version of array elements. Keep in mind that these
functions may require the Java VM to perform storage allocation and
copying. Whether these functions in fact copy the array depends on the
VM implementation, as follows:..."


"...Our approach provides flexibility. A garbage collector algorithm
can make separate decisions about copying or pinning for each given
array. For example, the garbage collector may copy small objects, but
pin the larger objects..."

I believe the relevant API's are GetArrayElements() and
ReleaseArrayElements.

--Chris

 PGP signature

Re: Native codes on Linux?

[Christopher Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, May 29, 2000 at 12:02:11PM -0700, Todd Papaioannou wrote:
> Apart from gcj, which I am having trouble using with the jdk1.2.2 collection
> classes, does anyone know of any other methods of generating native
> instruction codes on linux from java class or source files?

Lots of them. Probably the most notable one is TowerJ:

http://www.towerj.com/

Are you sure your collection class problem is specific to native compilation?

- --Chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard 

iD8DBQE5M1A6frrCpthD+UYRAh7cAJ0S0MRSq8VPLcoE3yRiohYJoq1xPwCg8xSh
yQjjFjBGKUkWnd9icNVf7LA=
=cgY9
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: J2SEE 1.3 for Linux!

[Christopher Smith]

On Mon, Jun 05, 2000 at 06:52:16PM -0400, Joseph Shraibman wrote:
> > The current implementation is almost 1.1-complaint and has parts of 1.2.
> > The Java spec is huge, of course, and getting the rest of the way to
> > a full implementation isn't a quick job. But, as far as I can tell,
> > Kaffe is by far the strongest of the open source Java implementations.
> I thought kaffe died when the company that wrote it got bought out my
> M$.

Nope, it was revitalized when aliens from the 26th century brought had
lost one of their space crafts to Tim Wilkinson. He's now
incrementally releasing some of this 26th century technology into the
Kaffe VM. ;-)

I have to say, I'm impressed with he power of the rumour
mill. Microsoft didn't buy out Transvirtual, they merely payed for the
development of some elements of the KaffeVM which made it compatible
with their own proprietary extensions. Despite the evil that MS
represents I have to say that they've treated Transvirtual MUCH better
than Sun.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: J2SEE 1.3 for Linux!

[Christopher Smith]

On Sun, Jun 11, 2000 at 08:48:13AM -0700, Larry Sanderson wrote:
> > with their own proprietary extensions. Despite the evil that MS
> > represents I have to say that they've treated Transvirtual MUCH better
> > than Sun.
> 
> Do you mean Microsoft treated Transvirtual better than Microsoft treated
> Sun, or Microsoft treated Transvirtual better than Sun treated Transvirtual?
> (or all of the above)  Just curious.

Ooops. Sorry for being confusing. I mean that MS has treated
Transvirtual quite nicely while Sun appears to have shunned
Transvirtual.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: J2SEE 1.3 for Linux!

[Christopher Smith]

On Sun, Jun 11, 2000 at 03:30:23PM -0700, Nathan Meyers wrote:
> Christopher Smith wrote:
> > Ooops. Sorry for being confusing. I mean that MS has treated
> > Transvirtual quite nicely while Sun appears to have shunned
> > Transvirtual.
> 
> Interesting observation. I'm not sure I'd expect or want Sun to treat
> Transvirtual with anything more than benign neglect. Microsoft, for a small
> investment, gained the ability to claim some cross-platform capabilities for its
> extensions. If you're more interested in doing real work than arguing industry
> politics, that's a pretty nice win all around.
> 
> If Transvirtual's work posed a business threat to Sun's JDK licensing or Unix
> platform business, I'm sure it would get much more attention from Sun - but not
> the sort of attention it would want.

This is exactly my frustration with where we are today in the Java
world. Sun controls the standard, but they act as though it's not in
their best interests for there to be independant implementations of
the standard. Net result: it is VERY difficult to comply to the Java
standard without Sun's help. Indeed, the Transvirtual guys have not
been allowed access to the certification suite. IS this in the best
interest of Sun? Perhaps. Is it in the best interest of Java
developers? I don't think os.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Serious bug in System.identityHashCode() found.

[Christopher Smith]

--On Monday, July 03, 2000 4:24 PM -0700 Mo DeJong <[EMAIL PROTECTED]> 
wrote:
> Exception in thread "main" tcl.lang.TclRuntimeError:
>
>  (find) table entry "SomeObject.1512497281" mapped to an invalid
>  entry,

I'm not familiar with the Jacl code base, but this error does not jibe with 
my own experiences with this method under heavy load situations. Is it 
possible that this is a bug in the Jacl engine? A real easy test would be 
take the two object which are supposedly using the same identity hash and 
test if the two objects are indeed identical.

Other items worth noting:

1) By the strictest of interpretations of the specifications of the 
specifications, it is in fact legal for two different objects to return the 
same value for System.identityHashCode() so long as you don't test the 
values at the same time.

2) If the previous object has been garbage collected, this in theory frees 
up the hash code for another object to use. Make sure that you really have 
two objects and this is not just a left over value from an already GC'd 
object.

My suspicion is that you are discovering that the JDK 1.2+ VM's move 
objects around in memory when they GC. This potentially results in 
different return values for System.indentityHashCode() for the same object 
before and after a GC.

So the assertion that:

static MyClass {
private static MyClass firstInstance = new MyClass();
private static int fiHashCode = System.identityHashCode(firstInstance);
public bool assert() {
if (this == firstInstance)
return true;
else
return fiHashCode != (System.identityHashCode(this));
}
}

MyClass.assert() will never return false is not true.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: Serious bug in System.identityHashCode() found.

[Christopher Smith]

--On Tuesday, July 04, 2000 1:37 AM +0100 Miles Sabin 
<[EMAIL PROTECTED]> wrote:
> Mo DeJong wrote,
>> There seems to be a really serious bug in the
>> System.identityHashCode() method in all > JDK 1.2 releases
>> derived from Sun code. The problem only shows up in "high
>> load" situations. Basically, two different Java objects of
>> the same class can return the exact same unique id from the
>> System.identityHashCode() method.
> Why is this a bug? The only requirement on a hashCode (system
> or otherwise) is that two == or .equal() objects should have
> the same hashCode. There's no requirement that != or !.equal()
> objects should have different hashCodes.

While this is true of generic implementations of hashCode(), 
Object.hashCode() does have this additional constraint from the spec:

"As much as is reasonably practical, the hashCode method defined by class 
Object does return distinct integers for distinct objects."

For most practical implementations of VM's this means they just return the 
pointer value, so on systems with less than 2^32 bytes of virtual memory, 
you can usually get away with the assumption that if (a != b) 
System.identityHashCode(a) != System.identityHashCode(b).

> You shouldn't expect System.identityHashCode() to be usable as
> a UID. Assuming otherwise is non-portable ... as you've just
> discovered.

This I agree with completely. If you really must implement your own. 
System.identityHashCode() can be used, with limitations, to implement an 
identity hash table, but you have to be VERY careful and aware of the 
potential problems involved. In general, using the standard hashCode() 
methods to implement hash tables in the like is dangerous business.

I do think it's unfortunate that the java.lang.* hierarchy doesn't have 
something which provides a guarunteed unique identifier for an object in 
memory.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Serious bug in System.identityHashCode() found.

[Christopher Smith]

> I don't get it. That was the whole point of adding the
> System.identityHashCode() method to 1.1. It was designed
> to return a UID in the case that a class overloaded
> the hashCode() method. Now folks seem to be saying "oh,
> yeah that was changed for 1.2". Changed to what?
> How would you suggest I generate a UID for two
> different object of the same class that return
> the exact same hash code? I can't get the memory
> location to implement my own UID method.

Nope, the whole point of System.identityHashCode() was added so that == had
equivalent operators to Object.equals(Object). Essentially it allowed you to
create an identity hash table. If they had ment it to be a uid they would
have called it Object.getUid(). ;-)

> I guess I could create another table of objects
> that map to the same hashCode but are not equal.
> It might also be possible to map every id to
> a Vector instead of directly to the object.
> Both of these "solutions" would be really ugly.
> I am really getting sick of Sun changing the
> APIs in really sneaky ways.

They didn't change the API. The docs have been the same for quite some time.
They did fix a conflict in the spec that said the following:

1) Object.equals(Object) returns true if two objects are equivalent.
2) Object.hashCode() always returns the same value for the same object.
3) if a.equals(b) then a.hashCode() == b.hashCode()

They realized that #2 couldn't always be true if #1 & #3 were true. That's
the only change I'm aware of with this API.

Standard hashtables are based on Object.equals() and as such deal with the
hashCode collision issue. So, if you just use a standard Hashtable (or Set
depending on your needs), make sure you're using identityHashCode() and
=='s, then collisions will be dealt with for you.

The thing to keep in mind is that hashCode() is generally speaking an
optimization, something that speeds up lookups, rather than being an
outright property of an object.

If you need is simply have an ID based lookup mechanism for objects in
memory, you can just use a double-WeakHashtable and some kind of a counter.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Serious bug in System.identityHashCode() found.

[Christopher Smith]

--On Monday, July 03, 2000 11:58 PM -0700 Mo DeJong <[EMAIL PROTECTED]> 
wrote:
> On Mon, 3 Jul 2000, Christopher Smith wrote:
>> > I don't get it. That was the whole point of adding the
>> > System.identityHashCode() method to 1.1. It was designed
>> > to return a UID in the case that a class overloaded
>> > the hashCode() method. Now folks seem to be saying "oh,
>> > yeah that was changed for 1.2". Changed to what?
>> > How would you suggest I generate a UID for two
>> > different object of the same class that return
>> > the exact same hash code? I can't get the memory
>> > location to implement my own UID method.
>> Nope, the whole point of System.identityHashCode() was added so that ==
>> had equivalent operators to Object.equals(Object). Essentially it
>> allowed you to create an identity hash table. If they had ment it to be
>> a uid they would have called it Object.getUid(). ;-)
>
> Humm, I am not sure if we are saying the same thing with different words.
> The System.identityHashCode() is not the equivalent of == in JDK 1.2. In

Nor should it be. Why bother creating a new method for doing something you 
can already do with the '==' operator?

> JDK 1.1 it worked that way but now I am not sure what it is the
> equivalent of. It is most certainly not the .equals() method, the
> error example I posted showed that the two objects that mapped
> to the same hash would return false from a equals() comparison.

Perhaps I was not clear enough:

System.identityHashCode() is to "==" as Object.hashCode() is to 
Object.equals(Object).

Does that make more sense?

> My example also shows that identityHashCode() is not the equivalent of ==,
> the == test for two objects that hash to the same value returned false.
> What exactly do you mean when you say "identity hash table"? What
> would such a table do for you?

That would give me a hash table where the key is the actual instance of the 
object itself rather than some concept of the value of the key. Such that 
(forgive the fact that this is 100% syntactically correct, I think it gets 
the idea across):

KeyClass keyA = new KeyClass();
KeyClass keyB;
KeyClass keyC;

keyC = keyA.clone(); //assume for KeyClass a.equals(a.clone())
   //is always true
keyB = keyA;

identityHash.put(keyC, "testC");
identityHash.put(keyB, "testB");
identityHash.put(keyA, "testA");

System.out.println(identityHash.get(keyA));
System.out.println(identityHash.get(keyB));
System.out.println(identityHash.get(keyC));

Should print out:

testA
testA
testC

>> They didn't change the API. The docs have been the same for quite some
>> time. They did fix a conflict in the spec that said the following:
> Yes they did. The API does not work the same way it did in JDK 1.1.

They changed the behavior, not the API. There is a difference. The 
specification is VERY clear that while the VM will make all resonable 
efforts to avoid duplicate values of System.identityHashCode(Object), it 
makes no guaruntees. One should expect behavior to be different from one 
JDK to the next. Indeed, one should be prepared for behavior to be 
different from one VM to the next, so long as they're consistent with the 
documentation, it's not a change in the API.

>> Standard hashtables are based on Object.equals() and as such deal with
>> the hashCode collision issue. So, if you just use a standard Hashtable
>> (or Set depending on your needs), make sure you're using
>> identityHashCode() and =='s, then collisions will be dealt with for you.
> I am using a "standard hashtable". I need to map a UID string to a
> single Object, without a UID provided by the identityHashCode(),
> I am going to have a hard time doing that.

Actually, it doesn't have to be hard at all. Just create your own UID's. I 
do this all the time.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Communication with Linux community

[Christopher Smith]

--On Wednesday, July 05, 2000 6:55 PM -0400 Jacob Nikom <[EMAIL PROTECTED]> 
wrote:
> My question is little off the usual java-linux topics and relates
> to the activity in Linux community.
>
> My company thinks about donating some of their applications to the
> Linux community. Where I can look how to do it, whom to communicate
> with and how it is usually happens?

A good place to start is http://www.opensource.org/.

You can always send an e-mail to ESR himself as well.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JDBC-ODBC for Linux

[Christopher Smith]

--On Thursday, July 06, 2000 11:56 AM -0700 Patrick Lacson 
<[EMAIL PROTECTED]> wrote:
> Newbie question:  Is it possible to have an Access datbase file located on
> the linux box and connect to it using the free Sun JDBC-ODBC driver?  If
> so where can I find more info.

The actual code using the JDBC driver will have to be installed on a 
machine with an Access ODBC driver (which I think must be a Windows box or 
a Mac box). The data store itself can reside anywhere (however the 
performance is limited).

To the best of my knowledge the Sun JDBC-ODBC driver has not been setup for 
Linux.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: speech recognition in java

[Christopher Smith]

On Sun, Jul 23, 2000 at 01:12:14AM -0700, nilesh modi wrote:
> IS IT POSSIBLE TO WRITE A SPEECH RECOGNITION PROGRAM IN JAVA ?  IF
> YES, PLEASE REFER ME A GOOD LITERATURE FOR IT .

http://java.sun.com/products/java-media/speech/

Please use lower case in all future communications.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Java and window managers

[Christopher Smith]

--On Friday, July 28, 2000 12:28 PM -0500 Julio Cesar Aguilar Cabrera 
<[EMAIL PROTECTED]> wrote:
> I'm using RedHat, XFree 3.3.6, and the latest IBM JDK 1.3 beta.
> When I started writing visual programs in Java I noticed some
> problems which I believe to be caused by AfterStep (1.8.1).
>
> I switched to KDE (1.1.2) and the problems dissapeared.
> KDE is good looking and all that but is slower and consumes
> more resources that AfterStep.
>
> Is anyone succesfully using a light windowmanager & java?

Wow, I never thought of AfterStep as "light". :-)

Generally speaking, you want a window manager that behaves as much as 
possible like mwm. I've found that a lot of the older window managers are 
pretty consistent (twm, gwm, and ctwm). Of course, you can always use 
LessTif's implementation of mwm, but I wouldn't call that "light" either. 
;-)

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Java and window managers

[Christopher Smith]

--On Friday, July 28, 2000 11:56 AM -0700 Christopher Smith <[EMAIL PROTECTED]> 
wrote:
> Generally speaking, you want a window manager that behaves as much as
> possible like mwm. I've found that a lot of the older window managers are

BTW, the reason for this is that the AWT makes a lot of assumptions about 
the window manager's behavior that are basically a lot like MWM. Perhaps 
the GNU Classpath version does not have this problem. Has anyone tried it?

> pretty consistent (twm, gwm, and ctwm). Of course, you can always use
> LessTif's implementation of mwm, but I wouldn't call that "light" either.
> ;-)

I think I also remember now that WindowMaker may have behaved pretty well 
when I used it.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to keep the application running on the server

[Christopher Smith]

On Sun, Aug 27, 2000 at 02:05:07PM -0400, Andrew Majercik wrote:
>   Applications "tie" themselves to the console window in a parent/child
> relationship. (once the parent goes away, so do all the children!) What you 

Actually, they are tied to the process which spawned them (typically
the shell). It' a subtle difference.

> need to do is detach the process from the terminal.  One way of doing this 
> is to run it as a daemon (if there are other ways, I do not know them ), 
> which essentially forks a process(which copies the process), and exits that 
> process, leaving a detached child process(your java app, in this
> case).   It 

This can be done with a simple shell script.

> is somewhat of a nuiscance to do from within java, since you'll need to make 
> a native call to do so. (going through JNI).
> The native portion is only about 6 lines long, and good unix book should be 
> able to tell you how to do that.   I suppose you could avoid the JNI call 
> altogether by writing a native program that could daemonize any program, and 
> then calling your program from it via command line.  I"ve done both, the JNI 
> call is a bit cleaner, since it ends up using only one process.

There's another reason not to do this from within Java. If you are
using a VM with native threads, then you are going to be forking a
process with multiple threads. The semantics for how this is done
varies from one system to another, and IMHO Linux's approach is no
better than any of the others. I find it better to avoid the whole
mess by doing all my forks before I spawn threads.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Java Window always on top.

[Christopher Smith]

--On 09/05/00 16:45:49 +0200 Anders LindbXck <[EMAIL PROTECTED]> wrote:
> Gurumurthi, Nandakumar skrev:
>> My problem concerns both Java and Linux, and I'm of the opinion that
>> this would be the ideal place to post the problem - " On linux, using
>> java, how do I create a Window that will *always* remain on top of all
>> other windows ?" I need to create a window that will always remain on
>> top of all other windows. It should also be possible for me to add
>> swing/awt components like JButton to this window.
> From a GUI design point your questions is wrong!
> You really do not want to do that.
>
> The questions should be - why do they want to have a window
> that never should be obscured!
>
> Personally I would never use a program that insists of being on top.

I know, things like the windows task bar & system tray, the Apple menu bar, 
icon managers, CDE's dashboard, KDE's task bars, and the GNOME panel are 
scourges to user interface design! ;-)

Seriously, it can make sense, it just depends on what you're doing.

--Chris



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Sun JDK 1.3.0 RC

[Christopher Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Sep 10, 2000 at 08:14:45AM -0500, Steve Michael wrote:
> I realize that I go against the grain of most people on this list,
> but I would see that as a foolish move.  I believe that there is
> plenty of room for open source software and commercial software.
> 
> By the way has anyone paid for a JVM lately?  I believe that the
> source code is even available with the download...

The issue isn't about paying for the JVM. The JVM is a complex piece
of software, and as a consequence it has a lot of bugs and performance
issues. It's also a nice piece of general purpose software which could
be retargeted to any number of solutions with a few modifications. As
a consequence, it's an ideal product to be released as open source.

- From Sun's perspective there would also be benefits: lower development
costs, better cross-platforms support on more platforms, better
reputation of stability for Java in general. 

Really, when you think about it it makes more sense for the JVM to be
open sourced than StarOffice.

- --Chris


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard 

iD8DBQE5vBIGfrrCpthD+UYRAve4AJ9ZC0sNC1CZNakMB+SY6FAdFWbr8ACfUzyM
/lY+bhFdvJEIB+t+rsxJljQ=
=Wees
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Sun JDK 1.3.0 RC

[Christopher Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Sep 10, 2000 at 06:11:21PM -0700, Nathan Meyers wrote:
> Christopher Smith wrote:
> > - From Sun's perspective there would also be benefits: lower development
> > costs, better cross-platforms support on more platforms, better
> > reputation of stability for Java in general.
> And loss of control. For better or worse, Sun equates tight control
> of the spec and the sample implementation with its business
> success. I have yet to see any compelling case that they're wrong,
> or that they could run a business the size of JavaSoft on an open
> source model. It's too bad they coopt the language of the open
> source community to describe their license - it creates erroneous
> expectations and ill will - but I doubt anything's going to change
> anytime soon.

Actually, Sun themselves have already based their company on
non-proprietary technologies. C/C++ managed to make Sun quite rich
despite their lack of ownership. Similarly NFS. Heck, they even keep
the Sparc processor architecture open. I suspect the only reason they
are concerned about control of Java is because they fear
Microsoft. That's not a "customer driven" focus if you ask me.
 
> > Really, when you think about it it makes more sense for the JVM to be
> > open sourced than StarOffice.
> 
> It does? Sun has built a serious business with Java. What kind of
> business is there in an office suite? StarOffice presents a great
> opportunity to challenge the Evil Empire on the desktop, but what
> company would be crazy enough to try to get rich doing it?  Corel?
> What more need be said? Open-sourcing StarOffice was a good move -
> that is, if they manage to attract a critical mass of developers to
> make it fly.

Sun could, in theory, derive direct revenue from StarOffice (as
Microsoft still does from their office suite). They don't have a
similar model for Java. Additionally, StarOffice is not the kind of
tool that developers (the kind who can write office suites) slave over
on a daily basis: there aren't as many itches to scratch out there. I
suspect MOST of the itches that will get scratched will have to do
with MS Office interoperability (I know once the code is out there I'm
going to hack in a fix so that password-protected Word documents can
be read). Java on the other hand, (and particularly the JVM), is a
tool which is intimately tied to the software developer's day-to-day
activities. As a consequence, itches in the JVM would get scratched if
they could be. (I certainly would have worked on it by now if it had
been open sourced, particularly the window manager integration
issues... instead I've worked on Kaffe.)

- --Chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE5vDmUfrrCpthD+UYRAhTKAKDR97A3HSv+94uQOgNxgIkmBgrzFgCg49cQ
HfqMkC7vx1vEQbX8PhJFgV0=
=SAQL
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Runtime.getRuntime().exec(message);

[Christopher Smith]

--On Thursday, October 05, 2000 4:55 PM +0530 Santosh Dawara 
<[EMAIL PROTECTED]> wrote:
> What if someone tried a
> Runtime.getRuntime().exec("java"); ?
> or Runtime.getRuntime().exec("javac");
>
> I get an IOException for the same.
> Wheras, native applications (like "ls" and "clear") work fine.
>
> Whats the differance between the two calls ?

I'm just guessing, but perhaps "java" and "javac" aren't in your path? 
Also, you aren't including sufficient arguments to the programs in 
question, although I don't think that will cause an IOException.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RedHat 7.1 (upgrade) and Sun JDK1.3.0_02 (i386)

[Christopher Smith]

--On Tuesday, April 24, 2001 15:37:04 -0400 "Alexander V. Konstantinou" 
<[EMAIL PROTECTED]> wrote:
> I just upgraded a test machine running RedHat 6.2 (with all the latest
> updates) to RedHat 7.1.  I'm having trouble getting Sun JDK 1.3.0_02 to
> work in the new environment (blackdown 1.3.0-FCS works as far as I've
> tested).
>
> Has anyone tried using Sun's JDK in RedHat 7.1 ?  I'd like to find out
> if it is an upgrade issue, or a generic RH7.1 issue.
>
> Here are some details: Off the box I run into the following problem :
>
> /usr/local/java/sun-jdk1.3.0_02/bin/java: /usr/bin/cut: No such file or
> directory
>
> In RedHat 6.2 /usr/bin/cut is part of the textutils package.  I found
> out that the utility has moved to /bin in RedHat 7.1 so I added a link
> from /bin/cut to /usr/bin/cut (ln -s /bin/cut /usr/bin/cut).

I believe the problem is that RedHat 7.1 makes some updates to glibc, and 
the Sun JDK have some nasty glibc dependancies. I believe the blackdown 
JDK's will work fine with 7.1.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: jni link error

[Christopher Smith]

--On Tuesday, May 15, 2001 09:34:50 -0700 Nathan Meyers 
<[EMAIL PROTECTED]> wrote:
> Zhihong Pan wrote:
>
>> I need jni in my java application. I created a shared library, and set
>> my library path (export LD_LIBRARY=/home/mydir/), but I still get the
>> following error message:java.lang.UnsatisfiedLinkError: no java_gsapi in
>> java.library.path. Could anybody help me ?
>
> You need LD_LIBRARY_PATH instead of LD_LIBRARY.

Can anyone explain to me why having the file in the path set in ld.so.conf 
shouldn't be enough?

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Signals, JNI and sigtimedwait()...

[Christopher Smith]

Okay, I'm writing some JNI code for some stuff using RT signals. I need to 
do some sigtimedwaits, which then post as IO events to the JVM. My original 
design was to have Java threads invoke something like waitForIO(), which 
was a native method which did the sigtimedwait(). Unfortunately, this seems 
like to cause problems for the JVM's GC.

Is the only solution to use native threads, have them "join" the VM to post 
events, and then have them "leave" the VM before invoking sigtimedwait() 
again? That seems just really slow and painful.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: jni link error

[Christopher Smith]

--On Tuesday, May 29, 2001 17:21:41 -0500 Joi Ellis <[EMAIL PROTECTED]> wrote:
> On Tue, 29 May 2001, Christopher Smith wrote:
>
>>
>> Can anyone explain to me why having the file in the path set in
>> ld.so.conf  shouldn't be enough?
>
> Heh.  Try getting the security nazis to agree to THAT for a user
> application.

Umm... on most systems ld.so.conf can only be modified by root, and 
normally you only set it to include "safe" directories. I mean, if I can 
load in fake shared libraries into ld.so.conf, I can hose your system 
regardless (through libc for example).

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Java/Linux at JavaOne

[Christopher Smith]

--On Tuesday, May 29, 2001 15:01:25 -0700 Nelson Minar <[EMAIL PROTECTED]> 
wrote:
> The Penguin Gets Pumped Up . . . Turning Linux into a High-Powered
> Java Technology-Based Application Server
>   Java/Linux performance talk
>   http://servlet.java.sun.com/javaone/conf/sessions/934/0-sf2001.jsp
>   Friday June 8, 8:30 AM - 9:30 AM

That's mine. It should be fun. We're mostly going to focus on the 
scalability issue, which appears to be the major question on everyone's 
mind. If anyone thinks there are other things I should be speaking to, say 
it now. ;-)

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Java/Linux at JavaOne

[Christopher Smith]

--On Tuesday, May 29, 2001 21:25:20 -0700 ed phillips <[EMAIL PROTECTED]> 
wrote:
> It might be helpful and may even spawn other suggestions if
> you were to flesh out in a post some of the aspects, as you articulate
> them, of scaling Java on Linux. Perhaps a kind of pre-BoF statement of
> the topic to be discussed?

That's a good suggestion. Here goes:

The biggest problem with scaling Java on Linux are threads. No question 
about it. Linux 2.4.x is very scalable to even as many as 16 processors, 
with excellent network, memory, and disk performance (particularly now with 
XFS & ReiserFS). In my experience, most Java applications won't push the 
kernel's capabilities in these areas even on a $2000 1U server with a 
single processor, and those that do will find Linux scales just as well as 
everyone else.

So, the thread issue is a nasty one, particularly if you're say hosting 
servlets on Linux. 90% of the reason you need all these threads is due to 
the thread-per-IO model in standard Java I/O. Unfortunately, this doesn't 
map too efficiently to the 1-1 thread model found in most Linux JVM's. 
There are a few strategies for coping with this:

1) Use green threads (people don't normally think of this as an OK solution 
for an application server)
2) Have a C or other application multiplex the I/O either over sockets or 
JMS.
3) Use lots of boxes & tweak the kernel to allow as many threads as 
possible.
4) Use JNI to use Linux's various asynch I/O API's.

The good news is Linux's thread model is moving in a direction to better 
support Java's approach to I/O (IBM's next generation pthreads 
implementation), and Java's approach to I/O (NIO) is moving closer to the 
efficient way to do I/O with Linux. Indeed, we're working on some 
benchmarks right now for #4 and also using NIO to see just how far Linux 
will go. My bet is Linux is actually going to prove very cost-effective in 
terms of scalability with this stuff.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Re: Java/Linux at JavaOne

[Christopher Smith]

On 31 May 2001 06:45:08 +1000, Jesus M. Salvo Jr. wrote:
> > 4) Use JNI to use Linux's various asynch I/O API's.
> Option 4) is how BEA WebLogic Server does it, ( I think ). They have this
> libmuxer.so ( which is also available for Solaris -- dont know why when JVM
> for Solaris makes use of solaris native threads ) which enables native I/O,
> or the so-called "performance pack".

Yes, many of the various application servers employ various strategies
for this. Unfortunately I am unaware of any of them who have taken the
time to do this for Linux.
 
> Speaking of 4), does anyway have a ready-made ( cut&paste ) C code that one
> can compile into a shared library and have all I/O made through this library
> via JNI?

I'll be demoing a library that does this with SGI's KAIO patch at the
presentation (presuming I can iron out this nasty sigtimedwait problem).
 
> And how does JDK 1.4 affect the performance on Linux, given that 1.4 was
> better I/O support overall, in particular non-blocking I/O.

We're benchmarking that right now, but it doesn't take a genius to
realize the impact is pretty spectacular. All you need to do is compare
Apache's performance with polling I/O based web servers on Linux to get
a good idea of the potential performance gains.

The NIO API is a little annoying to me though in that it's low enough
level that it exposing the polling approach to I/O. With the overhead of
JNI, it's much nicer to use an asynch I/O approach for most Java
applications.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Re: Java/Linux at JavaOne

[Christopher Smith]

On 31 May 2001 16:09:38 -0700, David Brownell wrote:
> I may have missed this ... will this be covering GCJ?
> 
> Compiled Java has some nice advantages.  Including
> more natural and efficient integration with native code,
> as well as faster startup and the ability to do some
> aggressive ahead-of-time optimizations, and working
> better with standard OS tools (RPM etc).

I will mention this, but so far in my experience GCJ has not produced
terribly optimal code, it's behind in terms of JDK support, and is not
supported by any of the application server vendors. Even Turbo/J seems
to have a tough time beating the more recent IBM & Sun JVM's.

I'm curious about your comment about it working better with RPM. Can you
give me an example of this?

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Java Threads on Linux

[Christopher Smith]

On Wed, Oct 03, 2001 at 06:46:52PM -0700, Nathan Meyers wrote:
> On Wed, Oct 03, 2001 at 06:32:11PM -0700, Dan Kegel wrote:
> > root wrote:
> > The 2.4 kernel uses 32 bit process ids, so that shouldn't be a 
> > problem.  Are there other precious resources you're worried about?
> > If not, there's a good chance NxM threading models will simply
> > introduce complexity rather than add performance.  That was Linus'
> > bet long ago, and the question is still open.
> 
> I'll defer to anyone who's faced this problem head-on. Any opinions
> from those who've hit the wall when scaling up Java on Linux?

NxM is actually pretty well proven as being a better way to
scale. It's also been proven that it's fairly complex to implement
properly. In general, there are a lot of issues with having N
kernel-level threads running where N is a large number. Generally
speaking, it works great as long as N is roughly proportional to the
number of processors in the system. Unfortunately, until JDK 1.4 came
out, Java programs would have threads proportional to the number of
simultaneous I/O operations (which in a network application is
typically MUCH higher than the number of threads).

As far as hitting the wall on Linux, without a lot of tweaking, you do
run into problems with memory consumption once you start spawning a
lot of threads.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Saving JIT work?

[Christopher Smith]

On Tue, 2003-05-27 at 05:34, John R MacMillan wrote:
> |> Are there any JITs that save what they do? [...]
> 
> I've been told that IBM's JVM for iSeries (AS/400) does this, but I 
> don't know that first-hand.

Yes, I forgot about the AS/400 JVM. It has support for this or some
variation on this notion.

> |[...] You'd
> |be amazed at how little of a net win this is.
> 
> In general I agree, but I think there may be special cases where it 
> would be a win.
> 
> For instruction sets that are relatively difficult to compile for (eg. 
> IA-64), it might be useful, for example. From what I've seen of IA-64 
> JVMs, the compilation time often swamps the runtime, making client-side 
> apps in particular run better without it.

I suspect this is more a result of the JVM JIT's not being sufficiently
adapted to IA-64 (something that likely won't happen until IA-64 has a
large market share). A cleverly written IA-64 VM will generate EPIC
instructions which simultaneously interpret byte codes, profile
execution, and generate native code at the same time. (Well, perhaps
it'd be ambitious to be able to do more than 2 of those at any given
point in time.) Of course, that is far more complex than simply caching
the JIT'd code, so I could see where a cache might yield a helpful
interim solution..

> It also could be useful in the more limited case of apps that are 
> short-lived and need/want to start up quickly.

Yes, although in those cases you likely would want to just compile the
app to native code.

-- 
Christopher Smith <[EMAIL PROTECTED]>


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: some tools in java....

[Christopher Smith]

On Mon, 2003-06-02 at 18:40, Kent E wrote:
> Are there any IDE with a built-in Version Control in it? Version control
> that can be configured in the IDE?

Basically ALL the IDE's have built in support for version control tools.
You might want to read some of the information on the tools that have
been mentioned before, or actually try them out. I think you'll find
most of your answers pretty quickly that way.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Volano Report update

[Christopher Smith]

On Tue, 2003-06-03 at 04:17, Bill Huey wrote:
> On Tue, Jun 03, 2003 at 11:49:28AM +0200, Marco Trevisan wrote:
> > In my opinion:
> > 
> > - you tested Blackdown-1.3.1 using green threads, but Sun JVM used
> > native threads. In Linux this makes a huge difference in terms of thread
> > scalability with one CPU. It should be useful to show the Linux Sun
> > 1.3.1 JVM results with -green option.
> 
> Also, 2.5.x Linux has changes to their 1:1 model that greatly increases
> scalability for dealing with a large number of threads.

Actually, those changes are already available in the standard kernel in
RH9 (well, as long as you are on a Pentium Pro or better).

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Volano Report update

[Christopher Smith]

On Tue, 2003-06-03 at 19:29, John Neffenger wrote:
> Hi Bill,
> 
> > Also, 2.5.x Linux has changes to their 1:1 model that greatly increases
> > scalability for dealing with a large number of threads.
> 
> I was under the impression that Java application developers will have to 
> wait for the Java virtual machines to take advantage of those threading 
> changes before we see any benefits.  I read that IBM needs to make 
> changes in their Java VM on Linux to support it, for example.  Is that 
> correct?

That is my understanding right now. The latest JVM's from Sun and IBM
apparently take steps to disable NPTL. I'm not if anyone working on the
blackdown project is planning to get support for NPTL in ahead of Sun or
IBM.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Volano Report update

[Christopher Smith]

Juergen Kreileder wrote:

  Christopher Smith <[EMAIL PROTECTED]> writes:

  
  
On Tue, 2003-06-03 at 19:29, John Neffenger wrote:


  Hi Bill,

  
  
Also, 2.5.x Linux has changes to their 1:1 model that greatly
increases scalability for dealing with a large number of threads.

  
  I was under the impression that Java application developers will
have to wait for the Java virtual machines to take advantage of
those threading changes before we see any benefits.  I read that
IBM needs to make changes in their Java VM on Linux to support it,
for example.  Is that correct?
  

That is my understanding right now. The latest JVM's from Sun and
IBM apparently take steps to disable NPTL.

  
  
Huh?  RH 9 already uses NPTL, Sun and Blackdown JVMs work on it.  
(I don't know about IBM's.)

To clarify: yes, RH9 has NPTL. However, NPTL changes the behavior of
threading on Linux (actually makes it more POSIX compliant). These
subtle changes in behavior tend to cause problems with complex software
that is tightly tied to the underlying thread model. Certainly the
existing Linux JVM's have had a LOT of tweaking done to them in order
to deal with "differences" in Linux's thread model. This is also a
problem for the WINE project (as another example). So, the simple thing
to do is disable NPTL and use the old, less scalable thread model
(basically you just set an environment variable and magically glibc
uses LinuxThreads-style pthreads). It's my understanding that the Sun
JVM does this, as does the WINE project. I am not certain about the IBM
VM, but since they have not released a new VM since NPTL was released
on a mainstream Linux platform (RH9), I suspect this is not the case.
Someone who knows more, please let me know.

I suspect that prior to NPTL being usable, changes will have to be made
both the VM and the standard libraries. Perhaps with luck Sun/IBM/etc.
can just use code from other POSIX platforms. I don't know.

--Chris

Re: Volano Report update

[Christopher Smith]

On Tue, 2003-06-03 at 23:30, Calvin Austin wrote:
> I hope you guys are not confusing NGPT with NPTL :*)
> 
> All JVMs can support NPTL with little or no change, NPTL is still an ongoing
> project but you can see a difference already with Redhat 9 and Suns 1.4.2beta,
> 1.4.1 will also work. I have an article waiting that has a benchmark showing
> the difference

I stand corrected. I had run benchmarks in the past which indicated that
NPTL was not being used. I just reran the benchmarks, and I appear to be
quite wrong.

I also checked with lsof, and sure enough the JVM is linking with the
NPTL libraries (unless you set LD_ASSUME_KERNEL to 2.4.1). I did some
searching on bugtrack and found Bug ID #4802778, which indicates that
the JVM has not been tuned for NPTL, but currently does use it, and that
the LinuxThreads work arounds in the JVM proved to be benign.

So, now I know what I'll be doing tomorrow: trying to figure out why the
benchmarks indicated otherwise when I tested this a few months ago. :-(

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: setting the class path -an easier way

[Christopher Smith]

On Sat, 2003-06-14 at 17:12, Paul Tremblay wrote:
> This gets real tedious. And this is for just one application. 
> 
> I know with python, for example, you can just tell python to look in one
> folder for all the libraries. 
> 
> Is there a way to do this with java? Is there an easier way to create
> the CLASSPATH?

There are several ways.

1) You can invoke the application use -jar jarfile.jar, and the manifest
for the jarfile can set the classpath.

2) You can use ant, which which will let you set a classpath with
regexp's like "dir/*.jar".

3) You can write a short script using find and sed to do what ant does.

4) You can build jar files which aggregate various jars into a larger
jar file.

5) You can copy commonly used libraries into your $JAVA_HOME/jre/lib/ext
directory (this is the path for extensions), so that they'll get added
automatically.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to get better performances from a linux plateforme ?

[Christopher Smith]

On Wed, 2003-06-25 at 08:15, Damien Lecan wrote:
> Hello,
> 
> I am trying to get better performances from a linux plateforme and I am 
> a little bit disappointed.
> 
> I am testing a full J2EE application, ie 3 physical layers 
> (apache/tomcat <=> jboss <=> oracle db ; 3 servers), and this is very 
> slow on linux ... compared to the same plateforme on Windows 2000 server 
> (except for the db, this a HP server for both tests).
> 
> Every servers are equiped with JVM SUN 1.4.1_01 and Linux is RedHat 7.3, 
> not customized.
> 
> I know I could try other VM, but I am wondering if the problem comes 
> from the OS or from the VM (on windows, performances are twice better), 
> or from both ?
> 
> What should I modify on my redhat ? Should I use IBM ou Blackdown VM ?
> 
> Thanks for your help, I really would like to use linux instead of 
> windows for servers ...

So, it's really hard to say without a lot more data and analysis. I
would recommend that you do some profiling to see where you are seeing
the bottleneck. It could be something as simple as a configuration
issue. It would also be helpful to have some notion of "very slow".

I have to say that if you are using apache/tomcat on Windows 2000, I am
surprised that the Windows 2000 box is outperforming Linux. My own
experiences with that particular configuration yielded pretty poor
results.

The one other thing that crosses my mind is that it is possible you are
using the server VM for the Linux test, but the client VM for the
Windows test (particularly because Windows JVM does not come with the
server VM by default). Benchmarking the server VM can be a bit of a
trick, because you essentially have to do some "VM training" in order to
get it to optimize itself. While both VM's "train" as they run, the
train time for the client VM is very short, and the client VM runs
faster while training, so it will tend to show much better numbers.

But really, aside from the issue I raised in the previous paragraph, I'd
want to do a lot of profiling and analysis on the system before making a
call on this.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to get better performances from a linux plateforme ?

[Christopher Smith]

On Thu, 2003-06-26 at 09:35, Calvin Austin wrote:
> > NPTL does NOT provide better performances for Java. It only (but
> > that's VERY valuable) provides MUCH BETTER reliability.
> > Linux 2.4 is far from being an industrial O.S. for heavy load.
> > Waiting for 2.6 to see how much progress has been done.
> 
> Ok so where is your benchmark for NPTL? How can we trust you? Why all the info about
> AIX, that can't even  run on the same machine as windows 2000 or linux x86?
> 
> For the record I showed a NPTL benchmark at Javaone which showed improved
> performance and
> scalability. And this is only the first cut at NPTL on Redhat 9
> 
> The benchmark had 191% speed on a dual machine between running 1.4.1 and 1.4.2 with
> NPTL
> on the exact same machine. It was a heavy threaded chat server

I would second this with my own experiences with C++, as well as some of the
benchmarks used to demonstrated the goodness of NPTL by the NPTL developers.

Sure, for code that doesn't spawn many threads, and doesn't synchronize
very much, the benefit of NPTL is more in terms of the better POSIX
compliance (which in many ways translates to better stability since
POSIX semantics are more likely to be well understood by programmers).
However, for code who's primary bottlnecks were in Linux's thread
library, you will definitely see huge performance wins.

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please tell redhat to fix ps

[Christopher Smith]

On Thu, 2003-09-25 at 15:37, Joseph Shraibman wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97586
> 
> Please post comments about how ps reporting the wrong size for multithreaded apps is 
> indeed a bug.

I think it's kind of pointless to send this in as a distribution bug. It
is something that you should report to the psutils, nptl and/or kernel
folks, rather than redhat. I'm sure that will in turn result in a debate
as to what is right or wrong, but that is not a decision you'd want Red
Hat to make.

-- 
Christopher Smith <[EMAIL PROTECTED]>


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please tell redhat to fix ps

[Christopher Smith]

On Thu, 2003-09-25 at 16:34, Joseph Shraibman wrote:
> That begs the questions 1) what did ps do in redhat 8? and 2) what is top doing 
> different?

Red Hat 8 was using a totally different thread library. I'm sure this
behavioral difference is tied to NPTL (easy way to test this too, just
disable NPTL and try it). top is invariably doing the wrong thing. It
has a lovely history in this regard.

> If I need to understand the memory usage on my system I need to know the *real* 
> memory 
> used, not allocated.  Allocated isn't very useful at all, only being good for 
> understanding why you suddenly can't allocate any more memory even though you seem 
> to be 
> using much less than the theoretical limit.

Allocated is useful in some circumstances, used is useful in others.
However, what your notion of "used" is may vary from the kernel's. As
such, things like RSS and VSIZE are the much more reliable measures of
what's going on with your system, or just have your program track it's
allocations so it can report information to you directly.

Anyway, this is not really a Java discussion, but a Linux discussion
that is best had with those that maintain the relevant components.

-- 
Christopher Smith <[EMAIL PROTECTED]>


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]