On Apr 24, 2015, at 3:24 PM, Peter Levart <peter.lev...@gmail.com> wrote:
> Anyway. The inexact invoke() always transforms a specific MH to a generic one 
> (Object, Object, ...)Object, right?


> So using inexact invoke() on any MH can't trigger the leak. It's just that if 
> someone attempts to transform a generic MH to some more concrete one to be 
> able to "connect" it with further transformations does the danger of the leak 
> appear.

Good point, thanks.

This suggests that the right answer is to keep the 1-element cache as-is,
but don't fill it with any mh1=mh0.asType(...) for which mh1.type introduces
a class loader not already present in mh0.type.

I.e., don't use a weak reference for the 1-element cache, but don't fill it
with anything that might require a weak reference.  Use a backup cache
(if needed) to handle exotic type changes.

> So maybe, just for the purpose of inexact invoke(), the caching could be 
> performed just in case when asType transformed method type is of the form 
> (Object, Object, ...)Object. This would also prevent accidental thrashing of 
> the cache when inexact invoke() is intermixed with other asType() invocations.

The 1-element cache thrashes for other reasons already, and
I think we need a multi-way (multi-MH) backup cache of some sort.
The backup cache would have weak references.

Having a 1-element front-side cache would cover inefficiencies
in the backup cache, which in turn would cover inefficiencies 
for generating new conversion LFs and/or MHs.

One interesting point:  If we change the 1-element cache to use
a weak reference, the cost of reloading the cache will be higher,
since each reload must create a new WeakReference instance.
This is a possible reason to hold off on the suggested fix.

— John
mlvm-dev mailing list

Reply via email to