[MUD-Dev] TECH: Servers in Java

[Aaron Mulder]

Well I can't really answer your questions, but hopefully I can at
least poke you in the right direction:

On Sat, 29 Dec 2001, Brian Hook wrote:

> The first thing I've noticed is that Java's UDP implementation
> doesn't seem to have a non-blocking mode receive().  The apparent
> recommended strategy is to park your receive() on a separate
> thread.  I assume I'll be multiplexing incoming data based on the
> client's IP/port combo, as opposed to some proposals of forking
> off a new thread per client (which would obviously not be tenable
> with, say, 2000 clients).

Non-blocking I/O is one of the features of 1.4.  I don't know how
that would affect UDP sockets, though.  And how long that takes to
propogate to FreeBSD is an open question.  You can use the
SO_TIMEOUT flag under 1.3, FWIW.

If you *do* want to launch thousands of threads, see if there's a
"Green Threads" VM for FreeBSD.  The "Native Threads" VMs use a
process per thread, which limits you, but with Green Threads you get
multiple threads per process and you're restricted more by memory
than by process limits.  On the other hand, I'm not sure a Green
Threads VM can effectively use multiple CPUs.

I think the Solaris guys were talking up some mechanism of mapping a
large number of threads to a small number of processes (supporting
100000+ threads), but I don't really know anything more about that,
and I *certainly* don't know whether it would be available on
FreeBSD.  (Solaris for Intel is effectively free, I think, but I
don't know if the same options are available.)

> Other issues include the robustness of the various JVM
> implementations and the usability/predictability of Java GC
> implementations (that's a real big unknown for me -- is Java's GC
> going to be bad enough that it will affect a server's
> reliability?).

I'm not sure how many VM implementations are available for FreeBSD.
I didn't think there was that much variety.  But in any case, the
HotSpot VM exposes a lot of tweaks for the garbage collector.  My
memory on this is kind of dim, but I have a few notes from JavaOne:

 -verbose:gc will show you what the garbage collector is doing

 -Xincgc will produce smaller GC pauses at the cost of more overhead

 Some other GC-related options are -Xm=, -XX:MaxNewSize=, and
 -XX:MaxNew=

Object space is divided into two or more regions ("generational
garbage collecting"?), one of which is known as "Eden", and that's
where all new objects are created.  If Eden is to small, all objects
move out of Eden, which is bad because you want short-lived objects
to die in Eden.  But you don't want too big an Eden, or else (for
reasons that are no longer clear to me) all your GC runs are too
large.  I think the MaxNew or MaxNewSize control Eden somehow, but
again, I've forgotten how.

Sorry I don't have more specifics.

Aaron

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev