RFR: 6543126: Level.known can leak memory

Mandy Chung mandy.chung at oracle.com
Tue Sep 13 14:56:59 UTC 2016


The new webrev.05 looks good.

> On Sep 13, 2016, at 5:45 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Mandy,
> 
> Here is a new webrev with your feedback integrated.
> 
> Finally I managed to get rid of the InternalError in MethodHandle
> by using:
>           PrivilegedAction<ClassLoader> pa = () ->
>                 customLevel.getClass().getClassLoader();
> 
> instead of
>           PrivilegedAction<ClassLoader> pa =
>                 customLevel.getClass()::getClassLoader;
> 
> Not quite sure what was the issue. I can't manage to reproduce
> it in a stand alone test :-(

There might be some bug lurking.  Are you able to reproduce it changing to method reference in the logging code?  It worths filing a bug to track it.

Mandy

> 
> Anyway - the new webrev no longer has the KnownLevelCLV class:
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.05
> 
> best regards,
> 
> -- daniel
> 
> On 29/08/16 21:10, Mandy Chung wrote:
>> 
>>> On Aug 29, 2016, at 6:10 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> Here is a new webrev that uses ClassLoaderValue as Peter suggested.
>>> 
>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.04/
>>> 
>> 
>> Looks good in general.
>> 
>> 553         // KnowLevelCLV is used to register custom level instances with
>> 
>> typo: s/KnowLevelCLV/KnownLevelCLV
>> 
>> 568             final Level level;
>> 
>> Nit: perhaps renaming level to customLevel to make it clear what this is.
>> 
>> line 645, 646: s/gced/GC’ed/
>> 
>> 
>>> I had to introduce a new private static class (KnownLevelCLV)
>>> to avoid using lambdas in KnownLevel.add - as CustomLevel.java
>>> was failing with an InternalError raised in MethodHandles$Lookup
>>> otherwise.
>> 
>> I agree it’s good to make progress on JDK-6543126.  I think it’d be good to understand how we get to this InternalError during bindCaller.  Can you file a low priority JBS issue to track that?
>> 
>> Mandy
>> 
> 



More information about the core-libs-dev mailing list