Re: 7127687: MethodType leaks memory due to interning

[John Rose]

Jim's and Remi's comments on the problem are correct.

In the current design, MH.type values must be interned.  Comments on this 
design decision are interesting and useful, but this is not new ground; we went 
over it during the JDK 7 engineering and spec. work.  It is likely we will 
revisit this decision at some point, but not today.

To risk stating the obvious: I am not asking at this point for a review of the 
use of interned method types.  I am asking for a review of a change to the 
mechanism *by which they are interned*.

— John

P.S. I will also point out that the "intern" design pattern, although very old 
in Java (String.intern), is poorly supported by the collections API.  I think a 
lot of the comments people have are based on the assumption, "surely there must 
be a way to do this without so much code copying".  One would hope so, but in 
this case one would be wrong.  What's needed is a Set with the following 
properties:

1. Assuming set.contains(x), a way to return a reference to the equal value x' 
already in the set.
2. Assuming !set.contains(x), a way to insert x.
3. Thread safety.
4. Weak references, so that unreferenced elements x' are quietly dropped.

1,2 would be covered by something like this hypothetical API:
  interface InterningSet extends Set {
E intern(E x);  // ensures in set; returns x or pre-existing x'
E find(E x);  // returns null if not in set, else pre-existing x'
  }

Every JVM has some mechanism like this for String.intern, somewhere.

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: bug in MacroAssembler::check_method_handle_type for x86

[Christian Thalinger]

On Mar 28, 2012, at 7:31 PM, John Rose wrote:

> On Mar 21, 2012, at 8:17 AM, Christian Thalinger wrote:
> 
>> John, I think there is a bug in MacroAssembler::check_method_handle_type for 
>> x86 (with meth-lazy):
> 
> That's correct.  Thanks for noticing it; I'll push a fix.  — John

The weird thing is that when I implement it correctly on SPARC I get:

MH _invokeBasic mh=0x0007ab4a4fc0 saved_sp=0x7dcfb681 
args=0x7dcfbf40
MethodHandle:(Ltest/java/lang/invoke/MethodHandlesTest$HasFields;)Z : #( *** 
unrecognized MH type }
=== DEBUG MESSAGE: _invokeBasic 

But it worked with the broken version.

-- Chris

> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: hg: mlvm/mlvm/jdk: meth-lazy: rebased; added an incomplete fix for 7129034

[Christian Thalinger]

On Mar 29, 2012, at 5:58 PM, christian.thalin...@oracle.com wrote:

> Changeset: 66e23d30ba5c
> Author:twisti
> Date:  2012-03-29 17:58 +0200
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/66e23d30ba5c
> 
> meth-lazy: rebased; added an incomplete fix for 7129034

The fix is incomplete because we get two errors when running MethodHandlesTest:

There were 2 failures:
1) testFindGetter(test.java.lang.invoke.MethodHandlesTest)
java.lang.RuntimeException: failed to catch NPE exception (caughtEx=null)
...
2) testFindSetter(test.java.lang.invoke.MethodHandlesTest)
java.lang.RuntimeException: failed to catch NPE exception (caughtEx=null)
...

I think the runtime check is okay.  Maybe I broke the test.

-- Chris

> 
> ! meth-lazy-7023639.bcg.patch
> ! meth-lazy-7023639.patch
> ! meth-lazy-7023639.refac.patch
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

hg: mlvm/mlvm/jdk: meth-lazy: rebased; added an incomplete fix for 7129034

[christian . thalinger]

Changeset: 66e23d30ba5c
Author:twisti
Date:  2012-03-29 17:58 +0200
URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/66e23d30ba5c

meth-lazy: rebased; added an incomplete fix for 7129034

! meth-lazy-7023639.bcg.patch
! meth-lazy-7023639.patch
! meth-lazy-7023639.refac.patch

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Status of indy opto, update releases...

[Mark Roos]

For this test I am using the August test case ( just for this bug ) as it 
takes quite
a bit of thrashing to get it to occur.

I'll put together a new version in the next few days
mark




From:   Christian Thalinger 
To: Da Vinci Machine Project 
Date:   03/29/2012 03:48 AM
Subject:Re: Status of indy opto, update releases...
Sent by:mlvm-dev-boun...@openjdk.java.net




On Mar 22, 2012, at 8:20 PM, Mark Roos wrote:

I still get the NoClassDefFoundError (same jar I posted some time ago) 

on OSX with 

java  -agentpath:javaDebug.dylib -jar RtalkTest.jar 
ri/experiment2/RtalkTest 

openjdk version "1.7.0-u4-b10" 
OpenJDK Runtime Environment (build 1.7.0-u4-b10-20120216) 
OpenJDK 64-Bit Server VM (build 23.0-b15, mixed mode) 

I don't get it with the jar on the boot class path 

java  -agentpath:javaDebug.dylib -Xbootclasspath/a:RtalkTest.jar 
ri/experiment2/RtalkTest 

Is there a newer version of your runtime available somewhere?  I still 
have the one from last August.

-- Chris


mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: 7127687: MethodType leaks memory due to interning

[Jim Laskey]

If you have instances of a MethodType A and B, that have the exact same return 
type and arguments, then they are equivalent and it is necessary to only keep 
one (let's say A.)  It's also desirable to only keep one copy because of the 
equals test, not just java code, but also internally in the Hotspot C++ code.   
Thus, if A and B are constructed independently, we need to go thru an interning 
process to guarantee uniqueness (a singleton for each unique MethodType.)  
Using a set S only gets you half the way thru the process.  We can add A to S 
and we can then find B in S, but we need a function F(S, B) -> A, so we can 
discard B and use A in it's stead.  Sets do not have such a function,  maps do, 
but then we get into the hard reference issue.  WeakInternSet is effectively a 
set with function F added.

On 2012-03-29, at 10:25 AM, Vitaly Davidovich wrote:

> I don't see anything precluding == equality check.  MethodType is the key, it 
> implements equals() via ==.  In order to look it up in the data structure you 
> need to have a reference to one of these instances already, correct? So if 
> you have a reference to it, call containsKey() using it and get true, then 
> you already have a handle to the same instance.  I must be missing something 
> though ...
> 
> Sent from my phone
> 
> On Mar 29, 2012 9:03 AM, "Jim Laskey"  wrote:
> That's probably a legitimate argument.  I only chose Set because it was based 
> on the existing code in WeakHashMap/WeakHashSet.  Maybe WeakInterner may be 
> more appropriate.
> 
> "although possibly different instance"  is THE thing.  We only want one 
> instance of each MethodType in the environment so that MethodType.equals is a 
> simple == test.
> 
> On 2012-03-29, at 9:55 AM, Vitaly Davidovich wrote:
> 
>> No set that I know of allows you to get the key - you can check for its 
>> presence or remove it.  Since containsKey() requires that you pass it the 
>> key to find, there's nothing to return since you already have an equivalent 
>> key (although possibly different instance).  If that's not the intent of 
>> WeakInternSet then it shouldn't be called a set :).
>> 
>> Sent from my phone
>> 
>> On Mar 29, 2012 5:46 AM, "Jim Laskey"  wrote:
>> What we are trying to do is intern the MethodType. Maps are designed to 
>> provide the key -> value relationship (one way.) If we only used the key and 
>> a dummy value in the Map, it would be equivalent to a write only collection, 
>> since there is no method to return a found key.  We would have to set the 
>> value to sometime meaningful like the existing MethodType. Doing so creates 
>> the hard reference to the MethodType and transitively to the unloadable 
>> Classes. 
>> 
>> We encountered this problem in Nashorn where we generate object classes at 
>> runtime. MethodTypes that referred to these classes "hung on" to them 
>> indefinitely.  When running JavaScript test suites, we soon exhausted the 
>> perm gen.
>> 
>> I tried using WeakHashMap initially but then realized the implications. 
>> WeakHashSet is useless, since it uses WeakHashMap, making it not weak at 
>> all. 
>> 
>> This fix has been well tested, as it is integrated in our test system (4 
>> times a day on several different platforms.)
>> 
>> 
>> Sent from my iPhone
>> 
>> On 2012-03-28, at 11:51 PM, Vitaly Davidovich  wrote:
>> 
>>> We only care about keys here anyway, right? WeakHashMap with a dummy value 
>>> object (some static reference) should achieve the same thing since its 
>>> Entry will have the key referenced weakly and the value strongly (but we 
>>> don't care since the value is a dummy static ref).  Maybe I misunderstood 
>>> the intent though ...
>>> 
>>> Sent from my phone
>>> 
>>> On Mar 28, 2012 9:02 PM, "Jim Laskey"  wrote:
>>> The WeakHashMap leads to a non-weak reference to the class, since only the 
>>> key is weak. Same is true for public versions of WeakHashSet. The 
>>> collection used here is truly weak. 
>>> 
>>> Sent from my iPhone 4
>>> 
>>> On 2012-03-28, at 9:42 PM, Vitaly Davidovich  wrote:
>>> 
 Hi John,
 
 I think you can use diamond generic inference when declaring the weak 
 intern set.
 
 Also any reason you didn't use WeakHashMap directly with dummy value to 
 simulate the set? Or wrap the WeakHashMap and synchronize the accessors to 
 it?
 
 Sent from my phone
 
 On Mar 28, 2012 7:52 PM, "John Rose"  wrote:
 http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
 
 7127687: MethodType leaks memory due to interning
 Summary: Replace internTable with a weak-reference version.
 
 This is a point fix for JDK 8, and will (pending approval) also be 
 back-ported to JDK 7u.
 
 — John
 
 Notes on process:  This code is part of JSR 292.  Therefore the review 
 comments will be collected in mlvm-dev, and changes will be integrated via 
 hsx/hotspot-comp.
 
 At least one reviewer must be an official Reviewer the JDK 8 

Re: 7127687: MethodType leaks memory due to interning

[Vitaly Davidovich]

I don't see anything precluding == equality check.  MethodType is the key,
it implements equals() via ==.  In order to look it up in the data
structure you need to have a reference to one of these instances already,
correct? So if you have a reference to it, call containsKey() using it and
get true, then you already have a handle to the same instance.  I must be
missing something though ...

Sent from my phone
On Mar 29, 2012 9:03 AM, "Jim Laskey"  wrote:

> That's probably a legitimate argument.  I only chose Set because it was
> based on the existing code in WeakHashMap/WeakHashSet.  Maybe WeakInterner
> may be more appropriate.
>
> "although possibly different instance"  is THE thing.  We only want one
> instance of each MethodType in the environment so that MethodType.equals is
> a simple == test.
>
> On 2012-03-29, at 9:55 AM, Vitaly Davidovich wrote:
>
> No set that I know of allows you to get the key - you can check for its
> presence or remove it.  Since containsKey() requires that you pass it the
> key to find, there's nothing to return since you already have an equivalent
> key (although possibly different instance).  If that's not the intent of
> WeakInternSet then it shouldn't be called a set :).
>
> Sent from my phone
> On Mar 29, 2012 5:46 AM, "Jim Laskey"  wrote:
>
>> What we are trying to do is intern the MethodType. Maps are designed to
>> provide the key -> value relationship (one way.) If we only used the key
>> and a dummy value in the Map, it would be equivalent to a write only
>> collection, since there is no method to return a found key.  We would have
>> to set the value to sometime meaningful like the existing MethodType. Doing
>> so creates the hard reference to the MethodType and transitively to the
>> unloadable Classes.
>>
>> We encountered this problem in Nashorn where we generate object classes
>> at runtime. MethodTypes that referred to these classes "hung on" to them
>> indefinitely.  When running JavaScript test suites, we soon exhausted the
>> perm gen.
>>
>> I tried using WeakHashMap initially but then realized the implications.
>> WeakHashSet is useless, since it uses WeakHashMap, making it not weak at
>> all.
>>
>> This fix has been well tested, as it is integrated in our test system (4
>> times a day on several different platforms.)
>>
>>
>> Sent from my iPhone
>>
>> On 2012-03-28, at 11:51 PM, Vitaly Davidovich  wrote:
>>
>> We only care about keys here anyway, right? WeakHashMap with a dummy
>> value object (some static reference) should achieve the same thing since
>> its Entry will have the key referenced weakly and the value strongly (but
>> we don't care since the value is a dummy static ref).  Maybe I
>> misunderstood the intent though ...
>>
>> Sent from my phone
>> On Mar 28, 2012 9:02 PM, "Jim Laskey"  wrote:
>>
>>> The WeakHashMap leads to a non-weak reference to the class, since only
>>> the key is weak. Same is true for public versions of WeakHashSet. The
>>> collection used here is truly weak.
>>>
>>> Sent from my iPhone 4
>>>
>>> On 2012-03-28, at 9:42 PM, Vitaly Davidovich  wrote:
>>>
>>> Hi John,
>>>
>>> I think you can use diamond generic inference when declaring the weak
>>> intern set.
>>>
>>> Also any reason you didn't use WeakHashMap directly with dummy value to
>>> simulate the set? Or wrap the WeakHashMap and synchronize the accessors to
>>> it?
>>>
>>> Sent from my phone
>>> On Mar 28, 2012 7:52 PM, "John Rose"  wrote:
>>>
 http://cr.openjdk.java.net/~jrose/7127687/webrev.00/

 7127687: MethodType leaks memory due to interning
 Summary: Replace internTable with a weak-reference version.

 This is a point fix for JDK 8, and will (pending approval) also be
 back-ported to JDK 7u.

 — John

 Notes on process:  This code is part of JSR 292.  Therefore the review
 comments will be collected in mlvm-dev, and changes will be integrated via
 hsx/hotspot-comp.

 At least one reviewer must be an official Reviewer the JDK 8 Project
 [1], but other reviewers are most welcome.

 [1] http://openjdk.java.net/census#jdk8

 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>>
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>> __

Re: 7127687: MethodType leaks memory due to interning

[Jim Laskey]

That's probably a legitimate argument.  I only chose Set because it was based 
on the existing code in WeakHashMap/WeakHashSet.  Maybe WeakInterner may be 
more appropriate.

"although possibly different instance"  is THE thing.  We only want one 
instance of each MethodType in the environment so that MethodType.equals is a 
simple == test.

On 2012-03-29, at 9:55 AM, Vitaly Davidovich wrote:

> No set that I know of allows you to get the key - you can check for its 
> presence or remove it.  Since containsKey() requires that you pass it the key 
> to find, there's nothing to return since you already have an equivalent key 
> (although possibly different instance).  If that's not the intent of 
> WeakInternSet then it shouldn't be called a set :).
> 
> Sent from my phone
> 
> On Mar 29, 2012 5:46 AM, "Jim Laskey"  wrote:
> What we are trying to do is intern the MethodType. Maps are designed to 
> provide the key -> value relationship (one way.) If we only used the key and 
> a dummy value in the Map, it would be equivalent to a write only collection, 
> since there is no method to return a found key.  We would have to set the 
> value to sometime meaningful like the existing MethodType. Doing so creates 
> the hard reference to the MethodType and transitively to the unloadable 
> Classes. 
> 
> We encountered this problem in Nashorn where we generate object classes at 
> runtime. MethodTypes that referred to these classes "hung on" to them 
> indefinitely.  When running JavaScript test suites, we soon exhausted the 
> perm gen.
> 
> I tried using WeakHashMap initially but then realized the implications. 
> WeakHashSet is useless, since it uses WeakHashMap, making it not weak at all. 
> 
> This fix has been well tested, as it is integrated in our test system (4 
> times a day on several different platforms.)
> 
> 
> Sent from my iPhone
> 
> On 2012-03-28, at 11:51 PM, Vitaly Davidovich  wrote:
> 
>> We only care about keys here anyway, right? WeakHashMap with a dummy value 
>> object (some static reference) should achieve the same thing since its Entry 
>> will have the key referenced weakly and the value strongly (but we don't 
>> care since the value is a dummy static ref).  Maybe I misunderstood the 
>> intent though ...
>> 
>> Sent from my phone
>> 
>> On Mar 28, 2012 9:02 PM, "Jim Laskey"  wrote:
>> The WeakHashMap leads to a non-weak reference to the class, since only the 
>> key is weak. Same is true for public versions of WeakHashSet. The collection 
>> used here is truly weak. 
>> 
>> Sent from my iPhone 4
>> 
>> On 2012-03-28, at 9:42 PM, Vitaly Davidovich  wrote:
>> 
>>> Hi John,
>>> 
>>> I think you can use diamond generic inference when declaring the weak 
>>> intern set.
>>> 
>>> Also any reason you didn't use WeakHashMap directly with dummy value to 
>>> simulate the set? Or wrap the WeakHashMap and synchronize the accessors to 
>>> it?
>>> 
>>> Sent from my phone
>>> 
>>> On Mar 28, 2012 7:52 PM, "John Rose"  wrote:
>>> http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
>>> 
>>> 7127687: MethodType leaks memory due to interning
>>> Summary: Replace internTable with a weak-reference version.
>>> 
>>> This is a point fix for JDK 8, and will (pending approval) also be 
>>> back-ported to JDK 7u.
>>> 
>>> — John
>>> 
>>> Notes on process:  This code is part of JSR 292.  Therefore the review 
>>> comments will be collected in mlvm-dev, and changes will be integrated via 
>>> hsx/hotspot-comp.
>>> 
>>> At least one reviewer must be an official Reviewer the JDK 8 Project [1], 
>>> but other reviewers are most welcome.
>>> 
>>> [1] http://openjdk.java.net/census#jdk8
>>> 
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: 7127687: MethodType leaks memory due to interning

[Vitaly Davidovich]

No set that I know of allows you to get the key - you can check for its
presence or remove it.  Since containsKey() requires that you pass it the
key to find, there's nothing to return since you already have an equivalent
key (although possibly different instance).  If that's not the intent of
WeakInternSet then it shouldn't be called a set :).

Sent from my phone
On Mar 29, 2012 5:46 AM, "Jim Laskey"  wrote:

> What we are trying to do is intern the MethodType. Maps are designed to
> provide the key -> value relationship (one way.) If we only used the key
> and a dummy value in the Map, it would be equivalent to a write only
> collection, since there is no method to return a found key.  We would have
> to set the value to sometime meaningful like the existing MethodType. Doing
> so creates the hard reference to the MethodType and transitively to the
> unloadable Classes.
>
> We encountered this problem in Nashorn where we generate object classes at
> runtime. MethodTypes that referred to these classes "hung on" to them
> indefinitely.  When running JavaScript test suites, we soon exhausted the
> perm gen.
>
> I tried using WeakHashMap initially but then realized the implications.
> WeakHashSet is useless, since it uses WeakHashMap, making it not weak at
> all.
>
> This fix has been well tested, as it is integrated in our test system (4
> times a day on several different platforms.)
>
>
> Sent from my iPhone
>
> On 2012-03-28, at 11:51 PM, Vitaly Davidovich  wrote:
>
> We only care about keys here anyway, right? WeakHashMap with a dummy value
> object (some static reference) should achieve the same thing since its
> Entry will have the key referenced weakly and the value strongly (but we
> don't care since the value is a dummy static ref).  Maybe I misunderstood
> the intent though ...
>
> Sent from my phone
> On Mar 28, 2012 9:02 PM, "Jim Laskey"  wrote:
>
>> The WeakHashMap leads to a non-weak reference to the class, since only
>> the key is weak. Same is true for public versions of WeakHashSet. The
>> collection used here is truly weak.
>>
>> Sent from my iPhone 4
>>
>> On 2012-03-28, at 9:42 PM, Vitaly Davidovich  wrote:
>>
>> Hi John,
>>
>> I think you can use diamond generic inference when declaring the weak
>> intern set.
>>
>> Also any reason you didn't use WeakHashMap directly with dummy value to
>> simulate the set? Or wrap the WeakHashMap and synchronize the accessors to
>> it?
>>
>> Sent from my phone
>> On Mar 28, 2012 7:52 PM, "John Rose"  wrote:
>>
>>> http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
>>>
>>> 7127687: MethodType leaks memory due to interning
>>> Summary: Replace internTable with a weak-reference version.
>>>
>>> This is a point fix for JDK 8, and will (pending approval) also be
>>> back-ported to JDK 7u.
>>>
>>> — John
>>>
>>> Notes on process:  This code is part of JSR 292.  Therefore the review
>>> comments will be collected in mlvm-dev, and changes will be integrated via
>>> hsx/hotspot-comp.
>>>
>>> At least one reviewer must be an official Reviewer the JDK 8 Project
>>> [1], but other reviewers are most welcome.
>>>
>>> [1] http://openjdk.java.net/census#jdk8
>>>
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Status of indy opto, update releases...

[Charles Oliver Nutter]

On Thu, Mar 29, 2012 at 10:46 AM, Christian Thalinger
 wrote:
>> * indy classloading headaches
>>
>> The old NoClassDefFound problems seem to have gone away (or I just
>> haven't been able to trigger them) but more recently I reported on
>> this list about LinkageErrors that seemed to be caused by indy. I
>> eventually patched around them, forcing more classes to be created and
>> isolated...but I don't see how I could have been at fault in my code.
>
> This should all disappear in our new implementation (meth-lazy patches in the 
> repository) because of the way we handle signatures.  Unfortunately the 
> compiler support isn't complete yet (inlining is not perfect yet) so it may 
> be a pain to test it (because it's slow) but the code executed in the 
> interpreter and in the compilers is the same.  And so should trigger the same 
> errors (if there are any).

Ok, I'm happy to start testing it out to shake loose any issues. I
will assume I shouldn't report performance degradation right now.

>> The performance is bad enough that I may have to install some tiering
>> logic into JRuby's compiler so that methods over a certain size don't
>> use invokedynamic at all. It will be messy.
>
> That performance problem also disappears with the meth-lazy stuff.

Excellent! I have heled off on a few additional uses of invokedynamic
in JRuby because of the degradation, but I'm looking forward to
turning those on.

> 7u4 is pretty much closed.  The newer stuff has to wait for a future update 
> release.

Ahh, that's too bad. Hopefully u4 will be sufficient for folks
interested in trying JRuby + invokedynamic and u6 will help anyone who
runs into perf issues or bugs in u4.

At this point I'm debating options for JRuby 1.7. We've delayed it a
long time, and need to get it released, but the invokedynamic story is
still a bit of a mixed bag. I don't want to have indy logic disabled
by default in JRuby 1.7, but we'll consider that possibility as we
approach a final release in the next couple months.

> I try to polish the meth-lazy.jit patch a bit so that it works and running 
> tests isn't awfully slow.  Let's see what I can come up with.  I'll keep you 
> posted.

Excellent! I will be standing by :)

Would it be possible to get a paragraph describing how the new MH
logic differs from the old logic? It might be of some interest to
attendees at my deep-dive session at JAX next month.

- Charlie

- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: hg: mlvm/mlvm/jdk: rebase to current hsx/hotspot-comp; remove preview for 7113349

[Christian Thalinger]

Just a heads up:  most meth-lazy patches don't apply after this rebase.  I try 
to fix it.

-- Chris

On Mar 27, 2012, at 2:26 AM, john.r.r...@oracle.com wrote:

> Changeset: fbbb26a3c3ff
> Author:jrose
> Date:  2012-03-26 17:26 -0700
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/fbbb26a3c3ff
> 
> rebase to current hsx/hotspot-comp; remove preview for 7113349
> 
> - macosx-7113349.patch
> ! series
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: 7127687: MethodType leaks memory due to interning

[A. Sundararajan]

Looks good to me.

PS.  Remi notes that only constructor and "add" method of WeakInternSet 
are accessed from the containing class. The rest can be made private.

-Sundar

John Rose wrote:
> Thanks, Jim. 
>
> -- John  (on my iPhone T-1000)
>
> On Mar 28, 2012, at 6:01 PM, Jim Laskey  wrote:
>
>   
>> The WeakHashMap leads to a non-weak reference to the class, since only the 
>> key is weak. Same is true for public versions of WeakHashSet. The collection 
>> used here is truly weak. 
>>
>> Sent from my iPhone 4
>>
>> On 2012-03-28, at 9:42 PM, Vitaly Davidovich  wrote:
>>
>> 
>>> Hi John,
>>>
>>> I think you can use diamond generic inference when declaring the weak 
>>> intern set.
>>>
>>> Also any reason you didn't use WeakHashMap directly with dummy value to 
>>> simulate the set? Or wrap the WeakHashMap and synchronize the accessors to 
>>> it?
>>>
>>> Sent from my phone
>>>
>>> On Mar 28, 2012 7:52 PM, "John Rose"  wrote:
>>> http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
>>>
>>> 7127687: MethodType leaks memory due to interning
>>> Summary: Replace internTable with a weak-reference version.
>>>
>>> This is a point fix for JDK 8, and will (pending approval) also be 
>>> back-ported to JDK 7u.
>>>
>>> — John
>>>
>>> Notes on process:  This code is part of JSR 292.  Therefore the review 
>>> comments will be collected in mlvm-dev, and changes will be integrated via 
>>> hsx/hotspot-comp.
>>>
>>> At least one reviewer must be an official Reviewer the JDK 8 Project [1], 
>>> but other reviewers are most welcome.
>>>
>>> [1] http://openjdk.java.net/census#jdk8
>>>
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>   
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited

[Christian Thalinger]

Looks good.  -- Chris

On Mar 29, 2012, at 1:54 AM, John Rose wrote:

> http://cr.openjdk.java.net/~jrose/7087658/webrev.00/
> 
> 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods 
> that are multiply inherited
> 
> This is a point fix for JDK 8, and will (pending approval) also be 
> back-ported to JDK 7u.
> 
> — John
> 
> Notes on process:  This code is part of JSR 292.  Therefore the review 
> comments will be collected in mlvm-dev, and changes will be integrated via 
> hsx/hotspot-comp.
> 
> At least one reviewer must be an official Reviewer the JDK 8 Project [1], but 
> other reviewers are most welcome.
> 
> [1] http://openjdk.java.net/census#jdk8
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Status of indy opto, update releases...

[Christian Thalinger]

On Mar 22, 2012, at 8:20 PM, Mark Roos wrote:

> I still get the NoClassDefFoundError (same jar I posted some time ago) 
> 
> on OSX with 
> 
> java  -agentpath:javaDebug.dylib -jar RtalkTest.jar  ri/experiment2/RtalkTest 
> 
> openjdk version "1.7.0-u4-b10" 
> OpenJDK Runtime Environment (build 1.7.0-u4-b10-20120216) 
> OpenJDK 64-Bit Server VM (build 23.0-b15, mixed mode) 
> 
> I don't get it with the jar on the boot class path 
> 
> java  -agentpath:javaDebug.dylib -Xbootclasspath/a:RtalkTest.jar  
> ri/experiment2/RtalkTest 

Is there a newer version of your runtime available somewhere?  I still have the 
one from last August.

-- Chris

> 
> mark___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Status of indy opto, update releases...

[Christian Thalinger]

On Mar 22, 2012, at 11:39 AM, Charles Oliver Nutter wrote:

> Hey all! We're nearing the end of JRuby's 1.7 dev cycle, and I thought
> I should check in on the status of invokedynamic optimization work,
> update releases, and so on.
> 
> We've been getting more and more excellent reports of JRuby
> performance far exceeding people's expectations. A number of folks are
> already running JRuby 1.7dev in production because "it's the fastest
> thing they've ever seen". Kudos for all the excellent work up to this
> point!

That's good news.

> 
> Of course, nothing's ever perfect :)
> 
> Here's a few outstanding items I know have been in progress, but we
> haven't heard about recently.
> 
> * indy classloading headaches
> 
> The old NoClassDefFound problems seem to have gone away (or I just
> haven't been able to trigger them) but more recently I reported on
> this list about LinkageErrors that seemed to be caused by indy. I
> eventually patched around them, forcing more classes to be created and
> isolated...but I don't see how I could have been at fault in my code.

This should all disappear in our new implementation (meth-lazy patches in the 
repository) because of the way we handle signatures.  Unfortunately the 
compiler support isn't complete yet (inlining is not perfect yet) so it may be 
a pain to test it (because it's slow) but the code executed in the interpreter 
and in the compilers is the same.  And so should trigger the same errors (if 
there are any).

> 
> * degraded performance is still a big issue
> 
> I've run into a number of user cases where large methods end up
> significantly slower with indy than without. The performance of
> degraded (read: not jitted or not inlined) call sites and MH chains is
> so bad that some cases end up worse than JRuby's interpreted mode. I
> talked with Christian some weeks ago about a new plan to always
> compile the MH chain and do be smarter about what gets inlined into
> it, but I have not heard anything nor tracked progress since then.
> 
> The performance is bad enough that I may have to install some tiering
> logic into JRuby's compiler so that methods over a certain size don't
> use invokedynamic at all. It will be messy.

That performance problem also disappears with the meth-lazy stuff.

> 
> * u4? u6?
> 
> If I remember right, the original plan was to have the first big round
> of optimizations in u2, and then the "right way" of optimizing along
> with stability issues fixed for u4. With u4 rapidly locking down (did
> I see something about phase 2?) where do we stand on getting indy
> updates into that release?

7u4 is pretty much closed.  The newer stuff has to wait for a future update 
release.

> 
> As always, I'm standing by to help test, benchmark, profile, and read
> assembly dumps. I've not *yet* had a change to start working on
> Hotspot itself, but there may be some interesting changes coming up
> that will make it easier for me to do so :)

I try to polish the meth-lazy.jit patch a bit so that it works and running 
tests isn't awfully slow.  Let's see what I can come up with.  I'll keep you 
posted.

-- Chris

> 
> Anyway, thanks for everything, and I hope indy work is still moving
> forward. It really is amazing.
> 
> OH, P.S. I'm delivering a keynote at JAXConf 2012 on invokedynamic!
> I'd love to get as much information as possible about current and
> future status of indy in OpenJDK.
> 
> - Charlie
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: 7127687: MethodType leaks memory due to interning

[Rémi Forax]

John,
I think you can remove all public methods of class WeakInternSet
but ,add() i.e. tailor the implementation only for the need, at least 
until Doug Lea
provides a weak/concurent/hashmap in java.util.concurent.

Rémi

On 03/29/2012 11:45 AM, Jim Laskey wrote:
> What we are trying to do is intern the MethodType. Maps are designed 
> to provide the key -> value relationship (one way.) If we only used 
> the key and a dummy value in the Map, it would be equivalent to a 
> write only collection, since there is no method to return a found key. 
> We would have to set the value to sometime meaningful like the 
> existing MethodType. Doing so creates the hard reference to the 
> MethodType and transitively to the unloadable Classes.
>
> We encountered this problem in Nashorn where we generate object 
> classes at runtime. MethodTypes that referred to these classes "hung 
> on" to them indefinitely. When running JavaScript test suites, we soon 
> exhausted the perm gen.
>
> I tried using WeakHashMap initially but then realized the 
> implications. WeakHashSet is useless, since it uses WeakHashMap, 
> making it not weak at all.
>
> This fix has been well tested, as it is integrated in our test system 
> (4 times a day on several different platforms.)
>
>
> Sent from my iPhone
>
> On 2012-03-28, at 11:51 PM, Vitaly Davidovich  > wrote:
>
>> We only care about keys here anyway, right? WeakHashMap with a dummy 
>> value object (some static reference) should achieve the same thing 
>> since its Entry will have the key referenced weakly and the value 
>> strongly (but we don't care since the value is a dummy static ref). 
>> Maybe I misunderstood the intent though ...
>>
>> Sent from my phone
>>
>> On Mar 28, 2012 9:02 PM, "Jim Laskey" > > wrote:
>>
>> The WeakHashMap leads to a non-weak reference to the class, since
>> only the key is weak. Same is true for public versions of
>> WeakHashSet. The collection used here is truly weak.
>>
>> Sent from my iPhone 4
>>
>> On 2012-03-28, at 9:42 PM, Vitaly Davidovich > > wrote:
>>
>>> Hi John,
>>>
>>> I think you can use diamond generic inference when declaring the
>>> weak intern set.
>>>
>>> Also any reason you didn't use WeakHashMap directly with dummy
>>> value to simulate the set? Or wrap the WeakHashMap and
>>> synchronize the accessors to it?
>>>
>>> Sent from my phone
>>>
>>> On Mar 28, 2012 7:52 PM, "John Rose" >> > wrote:
>>>
>>> http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
>>> 
>>>
>>> 7127687: MethodType leaks memory due to interning
>>> Summary: Replace internTable with a weak-reference version.
>>>
>>> This is a point fix for JDK 8, and will (pending approval)
>>> also be back-ported to JDK 7u.
>>>
>>> — John
>>>
>>> Notes on process: This code is part of JSR 292. Therefore
>>> the review comments will be collected in mlvm-dev, and
>>> changes will be integrated via hsx/hotspot-comp.
>>>
>>> At least one reviewer must be an official Reviewer the JDK 8
>>> Project [1], but other reviewers are most welcome.
>>>
>>> [1] http://openjdk.java.net/census#jdk8
>>>
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net 
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net 
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net 
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net 
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: 7127687: MethodType leaks memory due to interning

[Jim Laskey]

What we are trying to do is intern the MethodType. Maps are designed to provide 
the key -> value relationship (one way.) If we only used the key and a dummy 
value in the Map, it would be equivalent to a write only collection, since 
there is no method to return a found key.  We would have to set the value to 
sometime meaningful like the existing MethodType. Doing so creates the hard 
reference to the MethodType and transitively to the unloadable Classes. 

We encountered this problem in Nashorn where we generate object classes at 
runtime. MethodTypes that referred to these classes "hung on" to them 
indefinitely.  When running JavaScript test suites, we soon exhausted the perm 
gen.

I tried using WeakHashMap initially but then realized the implications. 
WeakHashSet is useless, since it uses WeakHashMap, making it not weak at all. 

This fix has been well tested, as it is integrated in our test system (4 times 
a day on several different platforms.)


Sent from my iPhone

On 2012-03-28, at 11:51 PM, Vitaly Davidovich  wrote:

> We only care about keys here anyway, right? WeakHashMap with a dummy value 
> object (some static reference) should achieve the same thing since its Entry 
> will have the key referenced weakly and the value strongly (but we don't care 
> since the value is a dummy static ref).  Maybe I misunderstood the intent 
> though ...
> 
> Sent from my phone
> 
> On Mar 28, 2012 9:02 PM, "Jim Laskey"  wrote:
> The WeakHashMap leads to a non-weak reference to the class, since only the 
> key is weak. Same is true for public versions of WeakHashSet. The collection 
> used here is truly weak. 
> 
> Sent from my iPhone 4
> 
> On 2012-03-28, at 9:42 PM, Vitaly Davidovich  wrote:
> 
>> Hi John,
>> 
>> I think you can use diamond generic inference when declaring the weak intern 
>> set.
>> 
>> Also any reason you didn't use WeakHashMap directly with dummy value to 
>> simulate the set? Or wrap the WeakHashMap and synchronize the accessors to 
>> it?
>> 
>> Sent from my phone
>> 
>> On Mar 28, 2012 7:52 PM, "John Rose"  wrote:
>> http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
>> 
>> 7127687: MethodType leaks memory due to interning
>> Summary: Replace internTable with a weak-reference version.
>> 
>> This is a point fix for JDK 8, and will (pending approval) also be 
>> back-ported to JDK 7u.
>> 
>> — John
>> 
>> Notes on process:  This code is part of JSR 292.  Therefore the review 
>> comments will be collected in mlvm-dev, and changes will be integrated via 
>> hsx/hotspot-comp.
>> 
>> At least one reviewer must be an official Reviewer the JDK 8 Project [1], 
>> but other reviewers are most welcome.
>> 
>> [1] http://openjdk.java.net/census#jdk8
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev