1847084 Members
5109 Online
110262 Solutions
New Discussion

Re: native_th

 
Rushank
Super Advisor

native_th

Env : L3000, HP-UX 11.00, Service Guard, SAN, VA7400. Firmware 16.

When I run 'top' I see native_th has a big number under the size and res column.

It looks like it's a java related thread. Anybody knows why it takes lots of system resources and any remidy??
4 REPLIES 4
Joseph C. Denman
Honored Contributor

Re: native_th

Rushank,

You are correct, they are java related.

Most likely are:

native_threads/java xxxxxxx
(java interpreter)
or

/native_threads/jre xxxxxxx
(java runtime interpreter)

man java
man jre

...jcd...
If I had only read the instructions first??
Steve Steel
Honored Contributor

Re: native_th

Hi

It is the way it is written

See the Java documentation for using green threads if you need a change.

Firstly. If you look at this url you appear to be using HP native.


http://www.hp.com/products1/unix/java/infolibrary/prog_guide/java1/threads.html

Users with the HP-UX Virtual Machine with JIT for Java (JVM) for HP-UX 11.0 have the choice of running the kernel-threaded or the green-threaded JVM. By default, the java command for HP-UX 11.0 uses the kernel-threaded JVM.

You can override the default by setting the THREADS_FLAG environment variable to "green":

In Korn shell:

export THREADS_FLAG=green
java MyJavaApplication
In C shell:

setenv THREADS_FLAG green
java MyJavaApplication
You may also override the default by passing the -green option to the java, jdb, javac or javap commands.

Setting the THREADS_FLAG environment variable to "native" or passing the -native option to the java, jdb, javac or javap commands forces the use of the kernel-threaded JVM.



2) Here is an extract from our ITRC forums concerning this.It is added by a colleague who has mor ejava experience than me.

On our servers these native_thr processes use lots of memory, from 16-37 Megabytes. If yours are using a similar amount then thats normal. Only if theyre using considerable more and your sure theyre runaways should you kill them but try shuttding your application the correct way first.

3)This url
http://www.javaworld.com/channel_content/jw-threads-index.shtml

Gives a lot of good information.

4)This url
http://www.jdance.com/threads.shtm

Points to

Topic:
Thread Types

Question:

What's the diffence between green threads and native threads?

Answer:

Green threads are the default threads provided by the JDKTM. Native threads are the threads that are provided by the native OS:

Native threads can provide several advantages over the default green threads implementation, depending on your computing situation.

Benefits of using the native threads:

If you run JavaTM code in a multi-processor environment, the Solaris kernel can schedule native threads on the parallel processors for increased performance. By contrast, green threads exist only at the user-level and are not mapped to multiple kernel threads by the operating system. Performance enhancement from parallelism cannot be realized using green threads.

The native threads implementation can call into C libraries that use Solaris native threads. Such libraries cannot be used with green threads.

When using the native threads, the VM can avoid some inefficient remapping of I/O system calls that are necessary when green threads are used.



5)http://www.artima.com/insidejvm/ed2/ch05JavaVirtualMachine2.html

Shows a diagram comparing the thread methods and definately show sthe fact that native uses more memory while being more performant.



6)An interesting alternative opinion is

http://industry.java.sun.com/javanews/stories/story2/0,1072,16516,00.html

Java Performance On HP/UX 11 Servers Enhanced By Native Thread Support in


Steve Steel
If you want truly to understand something, try to change it. (Kurt Lewin)
Stefan Farrelly
Honored Contributor

Re: native_th


the native_th processes are Java and theyre large on memory and cpu because java is crap. It must be poorly written to use so much cpu and memory - it reminds me of the old days with poorly written cobol applications. I know several companies that used it to write new applications but gave up when they saw how many resources it used and how unreliable it is (wait till you get it freeze and have to try to kill it off without a reboot!).
Im from Palmerston North, New Zealand, but somehow ended up in London...
Pete Randall
Outstanding Contributor

Re: native_th

Thankyou, Stefan.

Pete