extending the constant pool

[Peter B. Kessler]

Patrick McNally wrote:

> Hello!
> 
> I'm playing with the class file parser at the moment and I could use 
> some help. Specifically, I am trying to use annotations to modify 
> bytecode and the constant pool. Byte code turns out to be pretty easy, 
> since it and the annotations are parsed at basically the same point. But 
> the constant pool has already been parsed and finalized by the time the 
> class file parser gets around to parsing my annotations. So what I've 
> been doing is creating a new constant pool with the extra number of 
> entries, adding what I want to this new pool and then reassigning the 
> original constant pool's handle to point to my new one. This works fine 
> for a few lines after parse_methods returns, but then all of a sudden my 
> new constant pool seems to get garbage collected as any reference I try 
> to make to it returns garbage. I'm pretty fuzzy about the hotspot 
> garbage collector, so any suggestions about how to get a new constant 
> pool to stick around would be much appreciated. I've basically just 
> reused the new constant pool instantiation code from the 
> parse_constantpool method.

I can't say if what you are doing is right way to extend a constant
pool, but I'll try to address the garbage collector issue you seem
to be having.

If you have a constantPoolHandle, then the collector will know that
your constantPool is live and everything should be fine.  If the
collector needs to relocate your constantPool it will, and will adjust
the constantPoolHandle accordingly.  If you only have a constantPoolOop,
or if you "unwrap" the constantPoolHandle and get a constantPoolOop,
then you cannot safely hold that oop across a garbage collection,
because the collector will not know to adjust the constantPoolOop
if the constantPool gets moved.  Or the collector may decide that
the constantPool is unreferenced and recycle the space for it.
Things go downhill after that.

			... peter