• Page restrictions apply
• Added by Edwin Dawson [Atlassian Technical Writer], last edited by Andrew Myers [Atlassian] on Jun 16, 2010  (view change)
• show comment hide comment

I am getting Out of Memory errors, how can I allocate more memory to FishEye?

Since the default memory setting usually is around 64MB or 128MB, you might have to adjust the settings to run a bigger FishEye instance with sufficient memory.
On this page:

• Out Of Memory Errors
  • OutOfMemoryError: Java Heap Space
  • OutOfMemoryError: PermGen space, or Permanent Generation Size
  • OutOfMemoryError: unable to create new native thread
  • OutOfMemoryError: GC overhead limit exceeded
  • java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?

Out Of Memory Errors

There are a number of different memory errors that the JVM will throw. The most common are listed as follows.
In the following, you will be required to set your memory settings via your FISHEYE_OPTS Environment Variables.
You will need to restart your server after setting your FISHEYE_OPTS.

After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.

OutOfMemoryError: Java Heap Space

If you are running Fisheye/Crucible as a windows service, increasing memory needs to be done in the wrapper.conf file. Refere to the Can Fisheye be run as a Windows Service for instructions.

To solve this error, you will need to add the argument -Xmx1024m to FISHEYE_OPTS, in addition to any argument you use to set the heap size. Often you need to increase the amount of memory allocated to fisheye during the initial scan and period and once this is completed you can reduce back down.

FISHEYE_OPTS="-Xms128m -Xmx1024m -XX:MaxPermSize=256m"

After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.

OutOfMemoryError: PermGen space, or Permanent Generation Size

If you get the error message: java.lang.OutOfMemoryError: PermGen space this means that you have exceeded Java's fixed 64MB block for loading class files. You will need to add the argument -XX:MaxPermSize=256m to FISHEYE_OPTS, in addition to any argument you use to set the heap size.

FISHEYE_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=256m"

After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.

OutOfMemoryError: unable to create new native thread

This error occurs when the operating system is unable to create new threads. This is due to the JVM Heap taking up the available RAM.

Big heaps take away from the space that can be allocated for the stack of a new thread

For Linux the maximum heap size of the JVM cannot be greater than 2GB. If you only have 2GB RAM in your server, it is not recommended to set the Max size of the JVM that high.
The size of the stack per thread can also contribute to this problem. The stack size can reduce the number of threads that can be created.

To fix this problem, you should reduce the size of your JVM Heap and also the size of the stack per thread.
The stack size can be changed with the following (example) parameter being added to your FISHEYE_OPTS:

FISHEYE_OPTS="-Xms128m -Xmx1024m -XX:MaxPermSize=256m -Xss512k"

Please refer to this guide as a reference for JVM tuning.

After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.

OutOfMemoryError: GC overhead limit exceeded

This error indicates that the JVM took too long to free up memory during its GC process. This error can be thrown from the Parallel or Concurrent collectors.

The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

This kind of OutOfMemoryError can be caused if your java process is starting to use swapped memory for its heap. This will cause the JVM to take a lot longer than normal to perform normal GC operations. This can eventually cause a timeout to occur and cause this error.

To overcome this issue, you need to make sure that all processes can't allocate more memory than there is system memory. In practice this is impossible to do for all processes. At a minimum you should make sure that all your jvm's do not have a total maximum memory allocation than your normally available system memory.

Please refer to this guide for more information.

java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?

Essentially the native objects does not have enough memory to use. This is usually because you have allocated too much memory to your heap reducing the amount available for native objects. See this article.

The solution is to reduce the amount of heap memory you have allocated. For example if you have set -Xmx4096, you should consider reducing this to -Xmx2048m.

Remember if you are using a 32bit JVM you cannot allocate more than -Xmx2048m for linux (and even less for windows). Using a 64 bit JVM can resolve this problem, but is not recommended for fisheye/crucible instances (refer to System Requirements).

Read the Tuning FishEye page for more detail on adjusting resource limits and performance settings in FishEye.

I used to be able to open *.sql files in my Eclipse text editor. For some reason that stopped working this morning:

    Invalid menu handle.

    Problems opening an editor... unable to open external editor.

To fix this behavior for ALL files of a certain extension:

    Window > Preferences -

... and on the Preferences Tree:

    General > Editors > File Associations -

... add your File Type extension, for example *.sql

... and finally add your Associated Editor. I chose "internal editors" - "text editor"

You can also change the behavior "temporarily" for a single file. Right click the file, click "Open With..." and select the editor...

Why is serialization required?

In today's world, a typical enterprise application will have multiple components and will be distributed across various systems and networks. In Java, everything is represented as objects; if two Java components want to communicate with each other, there needs be a mechanism to exchange data. One way to achieve this is to define your own protocol and transfer an object. This means that the receiving end must know the protocol used by the sender to re-create the object, which would make it very difficult to talk to third-party components. Hence, there needs to be a generic and efficient protocol to transfer the object between components. Serialization is defined for this purpose, and Java components use this protocol to transfer objects.

Figure 1 shows a high-level view of client/server communication, where an object is transferred from the client to the server through serialization.

Figure 1. A high-level view of serialization in action (click to enlarge)

How to serialize an object

In order to serialize an object, you need to ensure that the class of the object implements the java.io.Serializable interface, as shown in Listing 1.

Listing 1. Implementing Serializable

				

						import java.io.Serializable;

class TestSerial implements Serializable {
	public byte version = 100;
	public byte count = 0;
}
				
		

In Listing 1, the only thing you had to do differently from creating a normal class is implement the java.io.Serializable interface. The Serializable interface is a marker interface; it declares no methods at all. It tells the serialization mechanism that the class can be serialized.

Now that you have made the class eligible for serialization, the next step is to actually serialize the object. That is done by calling the writeObject() method of the java.io.ObjectOutputStream class, as shown in Listing 2.

Listing 2. Calling writeObject()

				

						public static void main(String args[]) throws IOException {
	FileOutputStream fos = new FileOutputStream("temp.out");
	ObjectOutputStream oos = new ObjectOutputStream(fos);
	TestSerial ts = new TestSerial();
	oos.writeObject(ts);
	oos.flush();
	oos.close();
}
				
		

Listing 2 stores the state of the TestSerial object in a file called temp.out. oos.writeObject(ts); actually kicks off the serialization algorithm, which in turn writes the object to temp.out.

To re-create the object from the persistent file, you would employ the code in Listing 3.

Listing 3. Recreating a serialized object

				

						public static void main(String args[]) throws IOException {
	FileInputStream fis = new FileInputStream("temp.out");
	ObjectInputStream oin = new ObjectInputStream(fis);
	TestSerial ts = (TestSerial) oin.readObject();
	System.out.println("version="+ts.version);
}
				
		

In Listing 3, the object's restoration occurs with the oin.readObject() method call. This method call reads in the raw bytes that we previously persisted and creates a live object that is an exact replica of the original object graph. Because readObject() can read any serializable object, a cast to the correct type is required.

Executing this code will print version=100 on the standard output.

The serialized format of an object

What does the serialized version of the object look like? Remember, the sample code in the previous section saved the serialized version of the TestSerial object into the file temp.out. Listing 4 shows the contents of temp.out, displayed in hexadecimal. (You need a hexadecimal editor to see the output in hexadecimal format.)

Listing 4. Hexadecimal form of TestSerial

				

						AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65
73 74 A0 0C 34 00 FE B1 DD F9 02 00 02 42 00 05
63 6F 75 6E 74 42 00 07 76 65 72 73 69 6F 6E 78
70 00 64
				
		

If you look again at the actual TestSerial object, you'll see that it has only two byte members, as shown in Listing 5.

Listing 5. TestSerial's byte members

				

							public byte version = 100;
	public byte count = 0;
				
		

The size of a byte variable is one byte, and hence the total size of the object (without the header) is two bytes. But if you look at the size of the serialized object in Listing 4, you'll see 51 bytes. Surprise! Where did the extra bytes come from, and what is their significance? They are introduced by the serialization algorithm, and are required in order to to re-create the object. In the next section, you'll explore this algorithm in detail.

Java's serialization algorithm

By now, you should have a pretty good knowledge of how to serialize an object. But how does the process work under the hood? In general the serialization algorithm does the following:

• It writes out the metadata of the class associated with an instance.
• It recursively writes out the description of the superclass until it finds java.lang.object.
• Once it finishes writing the metadata information, it then starts with the actual data associated with the instance. But this time, it starts from the topmost superclass.
• It recursively writes the data associated with the instance, starting from the least superclass to the most-derived class.

I've written a different example object for this section that will cover all possible cases. The new sample object to be serialized is shown in Listing 6.

Listing 6. Sample serialized object

				

						class parent implements Serializable {
	int parentVersion = 10;
}

class contain implements Serializable{
	int containVersion = 11;
}
public class SerialTest extends parent implements Serializable {
	int version = 66;
	contain con = new contain();

	public int getVersion() {
		return version;
	}
	public static void main(String args[]) throws IOException {
		FileOutputStream fos = new FileOutputStream("temp.out");
		ObjectOutputStream oos = new ObjectOutputStream(fos);
		SerialTest st = new SerialTest();
		oos.writeObject(st);
		oos.flush();
		oos.close();
	}
}
				
		

This example is a straightforward one. It serializes an object of type SerialTest, which is derived from parent and has a container object, contain. The serialized format of this object is shown in Listing 7.

Listing 7. Serialized form of sample object

				

						AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65
73 74 05 52 81 5A AC 66 02 F6 02 00 02 49 00 07
76 65 72 73 69 6F 6E 4C 00 03 63 6F 6E 74 00 09
4C 63 6F 6E 74 61 69 6E 3B 78 72 00 06 70 61 72
65 6E 74 0E DB D2 BD 85 EE 63 7A 02 00 01 49 00
0D 70 61 72 65 6E 74 56 65 72 73 69 6F 6E 78 70
00 00 00 0A 00 00 00 42 73 72 00 07 63 6F 6E 74
61 69 6E FC BB E6 0E FB CB 60 C7 02 00 01 49 00
0E 63 6F 6E 74 61 69 6E 56 65 72 73 69 6F 6E 78
70 00 00 00 0B
				
		

Figure 2 offers a high-level look at the serialization algorithm for this scenario.

Figure 2. An outline of the serialization algorithm

Let's go through the serialized format of the object in detail and see what each byte represents. Begin with the serialization protocol information:

• AC ED: STREAM_MAGIC. Specifies that this is a serialization protocol.
• 00 05: STREAM_VERSION. The serialization version.
• 0x73: TC_OBJECT. Specifies that this is a new Object.

The first step of the serialization algorithm is to write the description of the class associated with an instance. The example serializes an object of type SerialTest, so the algorithm starts by writing the description of the SerialTest class.

• 0x72: TC_CLASSDESC. Specifies that this is a new class.
• 00 0A: Length of the class name.
• 53 65 72 69 61 6c 54 65 73 74: SerialTest, the name of the class.
• 05 52 81 5A AC 66 02 F6: SerialVersionUID, the serial version identifier of this class.
• 0x02: Various flags. This particular flag says that the object supports serialization.
• 00 02: Number of fields in this class.

Next, the algorithm writes the field int version = 66;.

• 0x49: Field type code. 49 represents "I", which stands for Int.
• 00 07: Length of the field name.
• 76 65 72 73 69 6F 6E: version, the name of the field.

And then the algorithm writes the next field, contain con = new contain();. This is an object, so it will write the canonical JVM signature of this field.

• 0x74: TC_STRING. Represents a new string.
• 00 09: Length of the string.
• 4C 63 6F 6E 74 61 69 6E 3B: Lcontain;, the canonical JVM signature.
• 0x78: TC_ENDBLOCKDATA, the end of the optional block data for an object.

The next step of the algorithm is to write the description of the parent class, which is the immediate superclass of SerialTest.

• 0x72: TC_CLASSDESC. Specifies that this is a new class.
• 00 06: Length of the class name.
• 70 61 72 65 6E 74: SerialTest, the name of the class
• 0E DB D2 BD 85 EE 63 7A: SerialVersionUID, the serial version identifier of this class.
• 0x02: Various flags. This flag notes that the object supports serialization.
• 00 01: Number of fields in this class.

Now the algorithm will write the field description for the parent class. parent has one field, int parentVersion = 100;.

• 0x49: Field type code. 49 represents "I", which stands for Int.
• 00 0D: Length of the field name.
• 70 61 72 65 6E 74 56 65 72 73 69 6F 6E: parentVersion, the name of the field.
• 0x78: TC_ENDBLOCKDATA, the end of block data for this object.
• 0x70: TC_NULL, which represents the fact that there are no more superclasses because we have reached the top of the class hierarchy.

So far, the serialization algorithm has written the description of the class associated with the instance and all its superclasses. Next, it will write the actual data associated with the instance. It writes the parent class members first:

• 00 00 00 0A: 10, the value of parentVersion.

Then it moves on to SerialTest.

• 00 00 00 42: 66, the value of version.

The next few bytes are interesting. The algorithm needs to write the information about the contain object, shown in Listing 8.

Listing 8. The contain object

				

						contain con = new contain();
				
		

Remember, the serialization algorithm hasn't written the class description for the contain class yet. This is the opportunity to write this description.

• 0x73: TC_OBJECT, designating a new object.
• 0x72: TC_CLASSDESC.
• 00 07: Length of the class name.
• 63 6F 6E 74 61 69 6E: contain, the name of the class.
• FC BB E6 0E FB CB 60 C7: SerialVersionUID, the serial version identifier of this class.
• 0x02: Various flags. This flag indicates that this class supports serialization.
• 00 01: Number of fields in this class.

Next, the algorithm must write the description for contain's only field, int containVersion = 11;.

• 0x49: Field type code. 49 represents "I", which stands for Int.
• 00 0E: Length of the field name.
• 63 6F 6E 74 61 69 6E 56 65 72 73 69 6F 6E: containVersion, the name of the field.
• 0x78: TC_ENDBLOCKDATA.

Next, the serialization algorithm checks to see if contain has any parent classes. If it did, the algorithm would start writing that class; but in this case there is no superclass for contain, so the algorithm writes TC_NULL.

• 0x70: TC_NULL.

Finally, the algorithm writes the actual data associated with contain.

• 00 00 00 0B: 11, the value of containVersion.

Conclusion

In this tip, you have seen how to serialize an object, and learned how the serialization algorithm works in detail. I hope this article gives you more detail on what happens when you actually serialize an object.

From  ： http://www.javaworld.com/community/node/2915

The GC will send some sort of "finalize" message to the object and then set any weakly-referencing variables to null whenever it disposes of the referenced object. This allows "finalization" logic to be run before the object is disposed of (e.g., close a file if still open, commit any open transaction(s), etc.). Java 1.1 does not support weak references other than via an undocumented Ref class that is not supported under Netscape. Weak references arrived officially with JDK 1.2. Java has three kinds of weak references, called soft references, weak references, and phantom references, in order of increasing weakness.

Java has four orders of strength in holding onto Objects. In descending order from strongest to weakest they are:

1. The JVM holds onto regular Objects until they are no longer reachable by either clients or any container. In other words Objects are garbage collected when there are no more live references to them. Dead references don’t count.
   garbage collection
2. Soft references can be deleted from a container if the clients are no longer referencing them and memory is tight.
3. Weak references are automatically deleted from a container as soon clients stop referencing them.
4. Phantom references point to objects that are already dead and have been finalised.

在我的机器上(Sun Java 1.4.2)的运行结果
sun.misc.Launcher$AppClassLoader@1a0c10f
sun.misc.Launcher$ExtClassLoader@e2eec8
null
java.lang.Object's loader is null
LoaderSample1's loader is sun.misc.Launcher$AppClassLoader@1a0c10f
第一行表示，系统类装载器实例化自类sun.misc.Launcher$AppClassLoader
第二行表示，系统类装载器的parent实例化自类sun.misc.Launcher$ExtClassLoader
第三行表示，系统类装载器parent的parent为bootstrap
第四行表示，核心类java.lang.Object是由bootstrap装载的
第五行表示，用户类LoaderSample1是由系统类装载器装载的
 
 
二．parent delegation模型
从1.2版本开始，Java引入了双亲委托模型，从而更好的保证Java平台的安全。在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的parent去装载，若parent能装载，则返回这个类所对应的Class对象，若parent不能装载，则由parent的请求者去装载。

图 1 parent delegation模型
如图1所示，loader2的parent为loader1，loader1的parent为system class loader。假设loader2被要求装载类MyClass，在parent delegation模型下，loader2首先请求loader1代为装载，loader1再请求系统类装载器去装载MyClass。若系统装载器能成功装载，则将MyClass所对应的Class对象的reference返回给loader1，loader1再将reference返回给loader2，从而成功将类MyClass装载进虚拟机。若系统类装载器不能装载MyClass，loader1会尝试装载MyClass，若loader1也不能成功装载，loader2会尝试装载。若所有的parent及loader2本身都不能装载，则装载失败。
 
若有一个能成功装载，实际装载的类装载器被称为定义类装载器，所有能成功返回Class对象的装载器（包括定义类装载器）被称为初始类装载器。如图1所示，假设loader1实际装载了MyClass，则loader1为MyClass的定义类装载器，loader2和loader1为MyClass的初始类装载器。
 
需要指出的是，Class Loader是对象，它的父子关系和类的父子关系没有任何关系。
 
那么parent delegation模型为什么更安全了？因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代替由父亲装载器装载的可靠代码。实际上，类装载器的编写者可以自由选择不用把请求委托给parent，但正如上所说，会带来安全的问题。
 
 
三．命名空间及其作用
每个类装载器有自己的命名空间，命名空间由所有以此装载器为创始类装载器的类组成。不同命名空间的两个类是不可见的，但只要得到类所对应的Class对象的reference，还是可以访问另一命名空间的类。
 
例2演示了一个命名空间的类如何使用另一命名空间的类。在例子中，LoaderSample2由系统类装载器装载，LoaderSample3由自定义的装载器loader负责装载，两个类不在同一命名空间，但LoaderSample2得到了LoaderSample3所对应的Class对象的reference，所以它可以访问LoaderSampl3中公共的成员(如age)。
例2不同命名空间的类的访问
/*LoaderSample2.java*/

/*sub/Loadersample3.java*/

编译：javac LoaderSample2.java; javac sub/LoaderSample3.java
运行：java LoaderSample2
LoaderSample3 loaded
age is 30
从运行结果中可以看出，在类LoaderSample2中可以创建处于另一命名空间的类LoaderSample3中的对象并可以访问其公共成员age。
运行时包(runtime package)
由同一类装载器定义装载的属于相同包的类组成了运行时包，决定两个类是不是属于同一个运行时包，不仅要看它们的包名是否相同，还要看的定义类装载器是否相同。只有属于同一运行时包的类才能互相访问包可见的类和成员。这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。假设用户自己定义了一个类java.lang.Yes，并用用户自定义的类装载器装载，由于java.lang.Yes和核心类库java.lang.*由不同的装载器装载，它们属于不同的运行时包，所以java.lang.Yes不能访问核心类库java.lang中类的包可见的成员。
 
总结
命名空间并没有完全禁止属于不同空间的类的互相访问，双亲委托模型加强了Java的安全，运行时包增加了对包可见成员的保护。
 
二．    扩展ClassLoader方法
我们目的是从本地文件系统使用我们实现的类装载器装载一个类。为了创建自己的类装载器我们应该扩展ClassLoader类，这是一个抽象类。我们创建一个FileClassLoader extends ClassLoader。我们需要覆盖ClassLoader中的findClass(String name)方法，这个方法通过类的名字而得到一个Class对象。

   我们还应该提供一个方法loadClassData(String name)，通过类的名称返回class文件的字
节数组。然后使用ClassLoader提供的defineClass()方法我们就可以返回Class对象了。

再说说Package权限。Java语言规定，在同一个包中的class，如果没有修饰符，默认为Package权限，包内的class都可以访问。但是这还不够准确。确切的说，只有由同一个ClassLoader装载的class才具有以上的Package权限。比如启动类装载器装载了java.lang.String，类路径装载器装载了我们自己写的java.lang.Test，它们不能互相访问对方具有Package权限的方法。这样就阻止了恶意代码访问核心类的Package权限方法。

The Java programming language also provides operators that perform bitwise and bit shift operations on integral types. The operators discussed in this section are less commonly used. Therefore, their coverage is brief; the intent is to simply make you aware that these operators exist.

The unary bitwise complement operator "~" inverts a bit pattern; it can be applied to any of the integral types, making every "0" a "1" and every "1" a "0". For example, a byte contains 8 bits; applying this operator to a value whose bit pattern is "00000000" would change its pattern to "11111111".

The signed left shift operator "<<" shifts a bit pattern to the left, and the signed right shift operator ">>" shifts a bit pattern to the right. The bit pattern is given by the left-hand operand, and the number of positions to shift by the right-hand operand. The unsigned right shift operator ">>>" shifts a zero into the leftmost position, while the leftmost position after ">>" depends on sign extension.

The bitwise & operator performs a bitwise AND operation.

The bitwise ^ operator performs a bitwise exclusive OR operation.

The bitwise | operator performs a bitwise inclusive OR operation.

The following program, BitDemo , uses the bitwise AND operator to print the number "2" to standard output.

								class BitDemo {
     public static void main(String[] args) {
          int bitmask = 0x000F;
	  int val = 0x2222;
	  System.out.println(val & bitmask);  // prints "2"
     }

						

The methods that create processes may not work well for special processes on certain
native platforms, such as native windowing processes, daemon processes, Win16/DOS 
processes on Microsoft Windows, or shell scripts.

The created subprocess does not have its own terminal or console. All its standard 
io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process
through three streams (getOutputStream(), getInputStream(), getErrorStream()). 
...

Process proc = Runtime.getRuntime().exec(command);

// Create thread for reading inputStream (process' stdout)
proc.getInputStream();

// Create thread for reading errorStream (process' stderr)
proc.getErrorStream()

// this will wait for the process to end!!! I think it is very important
// not to interfere with other process in the O.S.
int returnCode = proc.waitFor();

String msg = "Shell command [" + commandString + "] result [";
if (returnCode == 0)
{
    msg += "SUCCEEDED";
}
else
{
    msg = msg + "FAILED - ret code: " + returnCode;
}
msg += "]";