First draft of translation document

[Howard Lovatt]

This, MethodHandle efficiency, is only true if you don't need a
separate frame object, once you need a frame object then the overhead
of a method handle can be avoided by using the frame for everything.
This was Remi Forax's original point.

An interesting idea would be to change the semantics of an *anonymous*
inner class so that they could be garbage collected without having to
have first collected their class loader. Since an anonymous inner
class can only have one instance this change won't break ordinary
code. Though it will break reflective code that uses the inner class.

This change, collection of anonymous inner classes, would help with
the frame object.

On 21 May 2010 03:43, Brian Goetz <brian.goetz at oracle.com> wrote:
> VMs maintain many actively managed regions, such as caches for generated
> code, metadata derived from bytecode (such as CFG and SSA reductions), etc,
> that live outside what most java developers think of as "the heap" but don't
> necessarily live in "perm gen."
>
> On 5/20/2010 1:41 PM, Nathan Bryant wrote:
>>
>> In that case, if the VM were to decide to generate an optimized
>> specialization for a partially applied function, where does the
>> generated code go? A MethodHandle may be data, but seems like code is
>> code.
>>
>> Are you saying the code goes on the normal heap, then?
>>
>> -----Original Message-----
>> From: Brian Goetz [mailto:brian.goetz at oracle.com]
>> Sent: Thursday, May 20, 2010 1:37 PM
>> To: Nathan Bryant
>> Cc: Howard Lovatt; lambda-dev at openjdk.java.net
>> Subject: Re: First draft of translation document
>>
>>> Can that sort of thing be made safe from a permgen churn perspective?
>>
>> Permgen is an issue with nominal class metadata.  But method handle
>> activity
>> happen in the actively managed memory pools, because method handles are
>> anonymous.
>>
>



-- 
  -- Howard.