Request for reviews (M): 7008325: CodeCache exhausted on sparc starting from hs20b04

[Vladimir Kozlov]

Looks good.

Could you rephrase next comment? It sounds strange.
May be simply "Construct a temporary BufferBlob"

  // Construct a temporary CodeBuffer to have it construct a BufferBlob
  // Cache this BufferBlob for this compile.

On side note for future optimizations (RFE). When I investigated this problem
I found that when only one constant is used more code is generated
(when RDPC is not used) since the table base construction take the same
number of instructions as one constant. Also I saw situations when
table base is constructed on fast path but it used used only on
slow paths (klasses passed to runtime calls for objects allocation).

Thanks,
Vladimir

On 12/23/10 3:52 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/7008325/webrev.01/
>
> 7008325: CodeCache exhausted on sparc starting from hs20b04
> Reviewed-by:
>
> The bug is that Compile::ScheduleAndBundle calls
> init_scratch_buffer_blob and later clear_scratch_buffer_blob to reset
> _scratch_buffer_blob and _scratch_locs_memory (setting to NULL).  But
> the CompilerWrapper destructor only frees the _scratch_buffer_blob if
> it's non-null resulting in a CodeCache memory leak.
>
> The fix is to remove clear_scratch_buffer_blob completely and let
> init_scratch_buffer_blob free and allocate a new blob if required.
>
> Additionally I added some code that prints the largest free block in
> CodeCache::print_bounds (as found in the hs_err file).