Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"

[Coleen Phillimore]

On 2/1/2011 6:38 PM, David Holmes wrote:
> Keith McGuigan said the following on 02/01/11 23:11:
>> On Jan 31, 2011, at 9:20 PM, David Holmes wrote:
>>> As per your other email NULL check is pointless as "new" will never 
>>> return null but will instead call vm_exit_out_of_memory to abort the 
>>> VM - which is exactly my point. I don't believe that a failure to 
>>> allocate in this code should be considered a fatal error for the VM.
>>
>> I agree, there may be situations where memory allocation failures 
>> should be considered non-fatal, and the Hotspot allocation routines 
>> should offer some support for that.  However, it's not clear to me 
>> that the various specifications we adhere to have "escape-clause" 
>> situations where events can be dropped or features scaled back 
>> when/if we run into memory constraints.  They should, no doubt, but I 
>> don't recall seeing anything like that at the present.  It's a can of 
>> worms that is probably worth opening up, but it's a bigger issue than 
>> this bugfix.
>
> Given our allocation routines leave a lot to be desired we should 
> strive to avoid the need for dynamic allocation as it introduces new 
> abort points. A program that runs fine today may abort with this fix 
> due to additional C-Heap usage.

Even though our C heap allocation routines have a mostly undesirable 
failure mode, these items are not large and cannot be allocated within a 
ResourceObj or Arena, so really CHeapObj is the only way to allocate them.

Are there a lot of these event allocated at one time? Is there a lot of 
allocation/free calls?  Maybe it's worth having some sort of free list 
to manage these objects, but only if there's an observed performance 
hit, which is sort of hard to measure with jvmti.

Coleen