search for: permgen

Hello All, One of our user is facing java.lang.OutOfMemoryError: PermGen space issue on a Windows 2003 32 bit xVM domU with 4GB RAM. He is able to successfully do these tests on equivalent physical system with Windows 2003 OS and 4GB RAM. Another user is facing issues with Tomcat running out of heap space on a Win2008 64bit xvM domU Our xVM hypervisor server is X4...

I'm monitoring some CentOS 5 servers running Sun Java. We have set things up so 2048 MB of RAM are available for the base operating system, taking into account the xMx and permgen settings. What we're seeing is the swap space getting used up, and not released. Is this normal behavior? Performance doesn't seem to be affected, however I'm a bit concerned that the swap file is completely full: free -m total used free shared buffer...

...As far as multiple heaps go: There are two classes of heaps we're talking about. The first class are heaps that have different object lifetime policies. Those kinds of heaps should IMHO be managed entirely by the collector without the need for compiler support. In other words, if there's a permgen heap for permanent objects, the collector can store bits in the object header or it can do address comparisons to determine whether an object is in the permgen heap without needing to use the pointer address space field. In fact, using the pointer-address-space property wouldn't work for this,...

Hi Talin, Let me ask a question before we go too much further. Currently the argument > to llvm.gcroot must be an alloca instruction. You cannot GEP an internal > field within the alloca and pass it to the gcroot intrinsic. So the entire > alloca is considered a root, even if it has non-pointer fields. My question > is, in this new address-space proposal, are we talking about changing

...the type tells you all you need to know. So it seems obvious that instead of marking specific *values* as garbage collectible, we should instead be marking *types*. (Of course, there are occasionally instances where a given type may be *conditionally* garbage collectible (such as Java's "permgen" objects which live in permanent memory). But that's an edge case that can easily be handled by a number of techniques. Telling the compiler that a given type is garbage collectable in no way compels the runtime library to actually trace it.) On Sun, Apr 15, 2012 at 8:00 PM, Nathan Jeffor...

Just a thought, but it would it make sense for garbage collection to be some sort of minimal debug information for potentially optimized code. Store just enough debug information to reconstruct call stacks and know where gc-roots are. Perhaps an approach like this could minimize the work required as it is shared between gc-support and debug information support. >From what I understand, DWARF