From john.r.rose at oracle.com  Tue Oct  1 14:29:04 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 1 Oct 2013 14:29:04 -0700
Subject: RFR (S) 8001105: findVirtual of Object[].clone produces internal
	error
In-Reply-To: <4AFDBF02-CFAE-40ED-9BCB-BC53B769AEC2@oracle.com>
References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
	<4AFDBF02-CFAE-40ED-9BCB-BC53B769AEC2@oracle.com>
Message-ID: <966D87E0-575B-41A3-B3AC-99927EDFBADE@oracle.com>

Second call for reviews.  I need two official Reviewers for this change.  ? John

P.S.  Thanks for your comments Morris; I enhanced the comment:

+    // The JVM does this hack also.
++   // (See ClassVerifier::verify_invoke_instructions
++   // and LinkResolver::check_method_accessability.)
++   // Because the JVM does not allow separate methods on array types,
+    // there is no separate method for int[].clone.
+    // All arrays simply inherit Object.clone.
+    // But for access checking logic, we make Object.clone
+    // (normally protected) appear to be public.
+    // Later on, when the DirectMethodHandle is created,
+    // its leading argument will be restricted to the
+    // requested array type.
++   // N.B. The return type is not adjusted, because
++   // that is *not* the bytecode behavior.

Oddly, the JVMS does not mention this hack explicitly.  Maybe it's buried in the Prolog code.

On Sep 21, 2013, at 2:34 AM, Morris Meyer <morris.meyer at oracle.com> wrote:

> This looks good.  Might want to point out where in HotSpot this change originates from in your comment.
> 
>    --mm
> 
> 
>> On Sep 18, 2013, at 10:32 PM, John Rose <rose00 at me.com> wrote:
>> 
>> http://cr.openjdk.java.net/~jrose/8001105/webrev.00/
>> 
>> Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type.
>> 
>> See: http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-October/005035.html
>> 
>> ? John
>> 
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From john.r.rose at oracle.com  Tue Oct  1 15:15:24 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 1 Oct 2013 15:15:24 -0700
Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller
	sensitivity
Message-ID: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com>

This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity.

It also adjusts some unit tests.

The key change is to the order of the security manager logic.  The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions.  This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written.

The API spec. and security rules have been internally reviewed.  This is a review of implementation and unit tests.

http://cr.openjdk.java.net/~jrose/8025112/webrev.00

For more background, see my JavaOne presentation:
  http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf

Thanks,
? John

From john.r.rose at oracle.com  Tue Oct  1 15:19:30 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 1 Oct 2013 15:19:30 -0700
Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8
References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
Message-ID: <A0CC4EDA-1C46-40EF-863C-E75F4BCB586C@oracle.com>

http://cr.openjdk.java.net/~jrose/8024438/webrev.00

These are miscellaneous edits to javadoc and unit tests, clarifying various minor corner cases and improving presentation.

There is also a single API change (already under review by CCC): Adding a missing wildcard to Constructor<?>.

Please review.

Thanks,
? John


From jon.masamitsu at oracle.com  Tue Oct  1 06:38:44 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 01 Oct 2013 06:38:44 -0700
Subject: jdk8 metaspace problem with indy
In-Reply-To: <5249C7AC.4040900@gmx.org>
References: <524442A7.704@gmx.org> <52498F22.6020706@oracle.com>
	<5249944C.6040409@oracle.com> <5249C7AC.4040900@gmx.org>
Message-ID: <524AD064.6050200@oracle.com>


On 9/30/13 11:49 AM, Jochen Theodorou wrote:
> Am 30.09.2013 17:10, schrieb Stefan Karlsson:
> [...]
>> First, my experiments were done without --indy so I might be seeing a
>> different issue than you are. On the other hand, the experiments shows a
>> real problem with our Metaspace and GC interaction, so I think that's
>> worth investigating.
>>
>> The root cause of the problem I'm seeing is that SoftReferences are not
>> cleared when the GC is triggered because of high metaspace memory
>> pressure. I've created the bug:
>> https://bugs.openjdk.java.net/browse/JDK-8025635 - SoftReferences are
>> not cleared before metaspace OOME are thrown
>
> SoftReferences not cleared.. especially SoftReferences to Class and in 
> worst case a soft reference to an object that has a hard reference to 
> a class was always a critical point. We have some history with that. 
> And this I see as critical bug for us. So I am very happy if it gets 
> fixed before the final jdk8 ;)
>
> I did read your description and I think you should try with indy (also 
> see http://groovy.codehaus.org/InvokeDynamic+support). What I have 
> seen is not that metaspace increases indefinitely. Instead there is an 
> OOME, before free memory is exhausted. Granted, jdk8 did, as far as I 
> remember, allow about 4 times

The OOME was for an attempted allocation from the Java heap?  In 
particular it was not an out-of-memory
from an attempted metadata allocation?

Jon

> more classes to be created than jdk4u25, but it failed to clear the 
> number of loaded classes at one point... afaik that was somewhere at 
> 40k classes being loaded (and 38k of them dead). But of course it is 
> possible I missed that there can be no free memory claimed and maybe 
> the fix for JDK-8025635 is a fix for what I did see as well
>
> bye Jochen
>


From john.r.rose at oracle.com  Tue Oct  1 22:19:56 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 1 Oct 2013 22:19:56 -0700
Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and
	caller sensitivity
In-Reply-To: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com>
References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com>
Message-ID: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com>

Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager".  The result is more clearly correct and maintainable.

Here is the respin:
  http://cr.openjdk.java.net/~jrose/8025112/webrev.01

? John

On Oct 1, 2013, at 3:15 PM, John Rose <john.r.rose at oracle.com> wrote:

> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity.
> 
> It also adjusts some unit tests.
> 
> The key change is to the order of the security manager logic.  The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions.  This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written.
> 
> The API spec. and security rules have been internally reviewed.  This is a review of implementation and unit tests.
> 
> http://cr.openjdk.java.net/~jrose/8025112/webrev.00
> 
> For more background, see my JavaOne presentation:
>  http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf
> 
> Thanks,
> ? John


From martijnverburg at gmail.com  Wed Oct  2 05:38:03 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 2 Oct 2013 13:38:03 +0100
Subject: JVM Language Summit (Europe)?
Message-ID: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>

Hi all,

Hope this is the right mailing list to post on, apologies for the slight OT
post.

A few people asked whether the LJC could/would host a JVM language summit
in Europe which would hopefully cover the EMEA based folks that can't make
the existing summit.

I'd like to get an idea of whether there's appetite for this and if so when
it should be run:

* At the same time and have some video-conferencing sessions? OR
* At a time almost 'opposite' to the existing summit so that there's a
summit roughly every 6-months.

Ping me directly with your thoughts (unless this is the right mailing list
- in that case reply back here).

Cheers,
Martijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131002/ce4320bd/attachment.html 

From christian.thalinger at oracle.com  Wed Oct  2 11:23:59 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 2 Oct 2013 11:23:59 -0700
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
In-Reply-To: <11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com>
References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
	<239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>
	<523C69EA.3030107@oracle.com>
	<11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com>
Message-ID: <BABCBAF2-C0A8-4183-B1D9-5D5989051792@oracle.com>

Since there is no new webrev I assume you incorporated all the stuff below.  If that's the case then it looks good.

On Sep 20, 2013, at 6:18 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
>> John,
>> 
>> I don't see much value in documenting buggy behavior of early JDK7 in JDK8 code. So, I would remove it.
> 
> OK.  I think I had it in mainly to make sure the unit tests did something interesting.

> 
>> Regarding the test:
>> 31  * @run main/othervm/timeout=3600
>> - why do you have timeout set to 1h?
> 
> Copy-and-paste from some other test.  Removed.
> 
>> I like the idea how you count events.
>> 
>> As a suggestion for enhancement - maybe it's more reliable to check the "type" of event as well? To ensure that particular class was initialized.
> 
> Good idea.  But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types.  I did the following, for each of the six test cases:
> 
> @@ -150,9 +150,11 @@
>     }
> 
>     private static int runFoo() throws Throwable {
> +        assertEquals(Init1Tick, 0);  // Init1 not initialized yet
>         int t1 = tick("runFoo");
>         int t2 = (int) INDY_foo().invokeExact();
>         int t3 = tick("runFoo done");
> +        assertEquals(Init1Tick, t2);  // when Init1 was initialized
>         assertEquals(t1+2, t3);  // exactly two ticks in between
>         assertEquals(t1+1, t2);  // init happened inside
>         return t2;

> 
> 
> ? John
> 
>> Best regards,
>> Vladimir Ivanov
>> 
>> On 9/20/13 1:38 AM, John Rose wrote:
>>> On Sep 12, 2013, at 7:24 PM, John Rose <john.r.rose at oracle.com
>>> <mailto:john.r.rose at oracle.com>> wrote:
>>> 
>>>> Please review this change for a change to the JSR 292 implementation:
>>>> 
>>>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
>>>> 
>>>> Summary: Align MH semantic with bytecode behavior of constructor and
>>>> static member accesses, regarding <clinit> invocation.
>>>> 
>>>> The change is to javadoc and unit tests, documenting and testing some
>>>> corner cases of JSR 292 APIs.
>>> 
>>> I have a reviewer (Alex Buckley) for the documentation changes, but I
>>> would also like a quick code review for the unit test.
>>> 
>>> Also, there is a code insertion (predicated on a "false" symbolic
>>> constant) which serves to document the buggy JDK 7 behavior.  I'm not
>>> particularly attached to it, so I'm open to either a yea or nay on
>>> keeping it.  Leaning nay at the moment.
>>> 
>>> ? John
>>> 
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From christian.thalinger at oracle.com  Wed Oct  2 11:39:16 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 2 Oct 2013 11:39:16 -0700
Subject: RFR (S) 8001105: findVirtual of Object[].clone produces internal
	error
In-Reply-To: <966D87E0-575B-41A3-B3AC-99927EDFBADE@oracle.com>
References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
	<4AFDBF02-CFAE-40ED-9BCB-BC53B769AEC2@oracle.com>
	<966D87E0-575B-41A3-B3AC-99927EDFBADE@oracle.com>
Message-ID: <BBFE2DF0-7EBC-4556-8F1F-94CEE2374A72@oracle.com>

Looks good.

On Oct 1, 2013, at 2:29 PM, John Rose <john.r.rose at oracle.com> wrote:

> Second call for reviews.  I need two official Reviewers for this change.  ? John
> 
> P.S.  Thanks for your comments Morris; I enhanced the comment:
> 
> +    // The JVM does this hack also.
> ++   // (See ClassVerifier::verify_invoke_instructions
> ++   // and LinkResolver::check_method_accessability.)
> ++   // Because the JVM does not allow separate methods on array types,
> +    // there is no separate method for int[].clone.
> +    // All arrays simply inherit Object.clone.
> +    // But for access checking logic, we make Object.clone
> +    // (normally protected) appear to be public.
> +    // Later on, when the DirectMethodHandle is created,
> +    // its leading argument will be restricted to the
> +    // requested array type.
> ++   // N.B. The return type is not adjusted, because
> ++   // that is *not* the bytecode behavior.
> 
> Oddly, the JVMS does not mention this hack explicitly.  Maybe it's buried in the Prolog code.
> 
> On Sep 21, 2013, at 2:34 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
> 
>> This looks good.  Might want to point out where in HotSpot this change originates from in your comment.
>> 
>>   --mm
>> 
>> 
>>> On Sep 18, 2013, at 10:32 PM, John Rose <rose00 at me.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~jrose/8001105/webrev.00/
>>> 
>>> Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type.
>>> 
>>> See: http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-October/005035.html
>>> 
>>> ? John
>>> 
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From christian.thalinger at oracle.com  Wed Oct  2 12:14:33 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 2 Oct 2013 12:14:33 -0700
Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8
In-Reply-To: <A0CC4EDA-1C46-40EF-863C-E75F4BCB586C@oracle.com>
References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
	<A0CC4EDA-1C46-40EF-863C-E75F4BCB586C@oracle.com>
Message-ID: <35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com>

src/share/classes/java/lang/invoke/MethodHandles.java:

+     *     <th><a name="equiv"></a>lookup expression</th>

Apparently the name attribute is obsolete for <a/> in HTML5:

http://dev.w3.org/html5/markup/a.html

I think they want you to use <th id="equiv">.

+     * <p style="font-size:smaller;">
+     * <a name="privacc"></a>
+     * <em>Discussion of private access:</em>

Same here.

+     * <h1><a name="secmgr"></a>Security manager interactions</h1>

And here.

+     * because the desired class member is missing, because the

Did you want an "or" before "because" like the others?

Otherwise this looks good.

On Oct 1, 2013, at 3:19 PM, John Rose <john.r.rose at oracle.com> wrote:

> http://cr.openjdk.java.net/~jrose/8024438/webrev.00
> 
> These are miscellaneous edits to javadoc and unit tests, clarifying various minor corner cases and improving presentation.
> 
> There is also a single API change (already under review by CCC): Adding a missing wildcard to Constructor<?>.
> 
> Please review.
> 
> Thanks,
> ? John
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From christian.thalinger at oracle.com  Wed Oct  2 12:17:57 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 2 Oct 2013 12:17:57 -0700
Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and
	caller sensitivity
In-Reply-To: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com>
References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com>
	<0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com>
Message-ID: <5CD24332-806B-47A5-B3B6-150E98993BFD@oracle.com>

Thank you for doing this; it is much clearer now.  Looks good.

On Oct 1, 2013, at 10:19 PM, John Rose <john.r.rose at oracle.com> wrote:

> Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager".  The result is more clearly correct and maintainable.
> 
> Here is the respin:
>  http://cr.openjdk.java.net/~jrose/8025112/webrev.01
> 
> ? John
> 
> On Oct 1, 2013, at 3:15 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
>> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity.
>> 
>> It also adjusts some unit tests.
>> 
>> The key change is to the order of the security manager logic.  The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions.  This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written.
>> 
>> The API spec. and security rules have been internally reviewed.  This is a review of implementation and unit tests.
>> 
>> http://cr.openjdk.java.net/~jrose/8025112/webrev.00
>> 
>> For more background, see my JavaOne presentation:
>> http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf
>> 
>> Thanks,
>> ? John
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From john.r.rose at oracle.com  Wed Oct  2 12:33:33 2013
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 2 Oct 2013 12:33:33 -0700
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
In-Reply-To: <BABCBAF2-C0A8-4183-B1D9-5D5989051792@oracle.com>
References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
	<239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>
	<523C69EA.3030107@oracle.com>
	<11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com>
	<BABCBAF2-C0A8-4183-B1D9-5D5989051792@oracle.com>
Message-ID: <D1D84FAB-3F66-4414-91E1-A7CD4A92F8DC@oracle.com>

Push-button webrev generator to the rescue:
  http://cr.openjdk.java.net/~jrose/8024599/webrev.01

? John

On Oct 2, 2013, at 11:23 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Since there is no new webrev I assume you incorporated all the stuff below.  If that's the case then it looks good.
> 
> On Sep 20, 2013, at 6:18 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
>> On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>> 
>>> John,
>>> 
>>> I don't see much value in documenting buggy behavior of early JDK7 in JDK8 code. So, I would remove it.
>> 
>> OK.  I think I had it in mainly to make sure the unit tests did something interesting.
> 
>> 
>>> Regarding the test:
>>> 31  * @run main/othervm/timeout=3600
>>> - why do you have timeout set to 1h?
>> 
>> Copy-and-paste from some other test.  Removed.
>> 
>>> I like the idea how you count events.
>>> 
>>> As a suggestion for enhancement - maybe it's more reliable to check the "type" of event as well? To ensure that particular class was initialized.
>> 
>> Good idea.  But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types.  I did the following, for each of the six test cases:
>> 
>> @@ -150,9 +150,11 @@
>>    }
>> 
>>    private static int runFoo() throws Throwable {
>> +        assertEquals(Init1Tick, 0);  // Init1 not initialized yet
>>        int t1 = tick("runFoo");
>>        int t2 = (int) INDY_foo().invokeExact();
>>        int t3 = tick("runFoo done");
>> +        assertEquals(Init1Tick, t2);  // when Init1 was initialized
>>        assertEquals(t1+2, t3);  // exactly two ticks in between
>>        assertEquals(t1+1, t2);  // init happened inside
>>        return t2;
> 
>> 
>> 
>> ? John
>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> On 9/20/13 1:38 AM, John Rose wrote:
>>>> On Sep 12, 2013, at 7:24 PM, John Rose <john.r.rose at oracle.com
>>>> <mailto:john.r.rose at oracle.com>> wrote:
>>>> 
>>>>> Please review this change for a change to the JSR 292 implementation:
>>>>> 
>>>>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
>>>>> 
>>>>> Summary: Align MH semantic with bytecode behavior of constructor and
>>>>> static member accesses, regarding <clinit> invocation.
>>>>> 
>>>>> The change is to javadoc and unit tests, documenting and testing some
>>>>> corner cases of JSR 292 APIs.
>>>> 
>>>> I have a reviewer (Alex Buckley) for the documentation changes, but I
>>>> would also like a quick code review for the unit test.
>>>> 
>>>> Also, there is a code insertion (predicated on a "false" symbolic
>>>> constant) which serves to document the buggy JDK 7 behavior.  I'm not
>>>> particularly attached to it, so I'm open to either a yea or nay on
>>>> keeping it.  Leaning nay at the moment.
>>>> 
>>>> ? John
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>> 
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From christian.thalinger at oracle.com  Wed Oct  2 12:38:40 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 2 Oct 2013 12:38:40 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <FDE825DB-BF3B-460F-B0F0-BBE238D2A713@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
	<523CC710.5030806@oracle.com>
	<FDE825DB-BF3B-460F-B0F0-BBE238D2A713@oracle.com>
Message-ID: <5CE51916-2D1B-4FA6-A8EF-52A71C832839@oracle.com>


On Sep 20, 2013, at 5:09 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
>> I cleaned javadoc a little [1], so it is more readable in the browser now.
> 
> Thanks; I applied those edits.  I fixed the problem of a missing <p> in a few other places too.
> 
>> The test code looks ok, though the logic is over-complicated.
>> But the whole MethodHandlesTest is written in the same vein.
> 
> Thanks.  (Looks like it wasn't written by a real test engineer.)

:-D  I try to not touch MethodHandlesTest.  We should think about splitting it into smaller test cases.

> 
> ? John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131002/aad8be14/attachment.html 

From john.r.rose at oracle.com  Wed Oct  2 14:31:06 2013
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 2 Oct 2013 14:31:06 -0700
Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8
In-Reply-To: <35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com>
References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
	<A0CC4EDA-1C46-40EF-863C-E75F4BCB586C@oracle.com>
	<35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com>
Message-ID: <3C5298FB-3149-4FED-920F-4254D07C3956@oracle.com>

On Oct 2, 2013, at 12:14 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> src/share/classes/java/lang/invoke/MethodHandles.java:
> 
> +     *     <th><a name="equiv"></a>lookup expression</th>
> 
> Apparently the name attribute is obsolete for <a/> in HTML5:
> 
> http://dev.w3.org/html5/markup/a.html
> 
> I think they want you to use <th id="equiv">.
> 
> +     * <p style="font-size:smaller;">
> +     * <a name="privacc"></a>
> +     * <em>Discussion of private access:</em>
> 
> Same here.
> 
> +     * <h1><a name="secmgr"></a>Security manager interactions</h1>
> 
> And here.

Wow; I don't know where HTML5 fits in the javadoc story.  That might be nice to upgrade, but I'm not gonna go first:
--------
	fgrep '<a name=' $(hg loc -I src/share/classes/java -X src/share/classes/java/lang/invoke) | wc
     235    1372   23349
--------
	fgrep '<a id=' $(hg loc -I src/share/classes/java -X src/share/classes/java/lang/invoke) | wc
       0       0       0
--------
	grep '<[a-z]* id=' $(hg loc -I src/share/classes/java) | wc
      12      72    1186   ## a few CSS tags
--------
	fgrep '<a name=' $(hg loc -I src/share/classes/java/lang/invoke) | wc
       8      46     884    ## lots of people were going faster than me, officer!
--------

> +     * because the desired class member is missing, because the
> 
> Did you want an "or" before "because" like the others?

Yes, you are right.  It started out as "a, b, or c" but then got out of control.  Switching to "a, or b, or...".

> Otherwise this looks good.

Thanks.  At your verbal suggestion I also did this:

      * If the filter returns a value, the target must accept that value as
-     * its {@code pos} argument, plus any arguments not passed to the filter.
+     * its argument in position {@code pos}, preceded and/or followed by
+     * any arguments not passed to the filter.
      * If the filter returns void, the target must accept all arguments
      * not passed to the filter.

? John

From mandy.chung at oracle.com  Wed Oct  2 15:03:47 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 02 Oct 2013 15:03:47 -0700
Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and
	caller sensitivity
In-Reply-To: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com>
References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com>
	<0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com>
Message-ID: <524C9843.50704@oracle.com>

On 10/1/13 10:19 PM, John Rose wrote:
> Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager".  The result is more clearly correct and maintainable.
>
> Here is the respin:
>    http://cr.openjdk.java.net/~jrose/8025112/webrev.01

Looks good to me.

Mandy
>
> ? John
>
> On Oct 1, 2013, at 3:15 PM, John Rose <john.r.rose at oracle.com> wrote:
>
>> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity.
>>
>> It also adjusts some unit tests.
>>
>> The key change is to the order of the security manager logic.  The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions.  This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written.
>>
>> The API spec. and security rules have been internally reviewed.  This is a review of implementation and unit tests.
>>
>> http://cr.openjdk.java.net/~jrose/8025112/webrev.00
>>
>> For more background, see my JavaOne presentation:
>>   http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf
>>
>> Thanks,
>> ? John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From christian.thalinger at oracle.com  Thu Oct  3 14:56:01 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 3 Oct 2013 14:56:01 -0700
Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8
In-Reply-To: <3C5298FB-3149-4FED-920F-4254D07C3956@oracle.com>
References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
	<A0CC4EDA-1C46-40EF-863C-E75F4BCB586C@oracle.com>
	<35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com>
	<3C5298FB-3149-4FED-920F-4254D07C3956@oracle.com>
Message-ID: <DB1FC743-93A6-47F3-B211-FDD1F7E67830@oracle.com>


On Oct 2, 2013, at 2:31 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Oct 2, 2013, at 12:14 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> src/share/classes/java/lang/invoke/MethodHandles.java:
>> 
>> +     *     <th><a name="equiv"></a>lookup expression</th>
>> 
>> Apparently the name attribute is obsolete for <a/> in HTML5:
>> 
>> http://dev.w3.org/html5/markup/a.html
>> 
>> I think they want you to use <th id="equiv">.
>> 
>> +     * <p style="font-size:smaller;">
>> +     * <a name="privacc"></a>
>> +     * <em>Discussion of private access:</em>
>> 
>> Same here.
>> 
>> +     * <h1><a name="secmgr"></a>Security manager interactions</h1>
>> 
>> And here.
> 
> Wow; I don't know where HTML5 fits in the javadoc story.  That might be nice to upgrade, but I'm not gonna go first:

Sure :-)  It was only a note.

> --------
> 	fgrep '<a name=' $(hg loc -I src/share/classes/java -X src/share/classes/java/lang/invoke) | wc
>     235    1372   23349
> --------
> 	fgrep '<a id=' $(hg loc -I src/share/classes/java -X src/share/classes/java/lang/invoke) | wc
>       0       0       0
> --------
> 	grep '<[a-z]* id=' $(hg loc -I src/share/classes/java) | wc
>      12      72    1186   ## a few CSS tags
> --------
> 	fgrep '<a name=' $(hg loc -I src/share/classes/java/lang/invoke) | wc
>       8      46     884    ## lots of people were going faster than me, officer!
> --------
> 
>> +     * because the desired class member is missing, because the
>> 
>> Did you want an "or" before "because" like the others?
> 
> Yes, you are right.  It started out as "a, b, or c" but then got out of control.  Switching to "a, or b, or...".
> 
>> Otherwise this looks good.
> 
> Thanks.  At your verbal suggestion I also did this:
> 
>      * If the filter returns a value, the target must accept that value as
> -     * its {@code pos} argument, plus any arguments not passed to the filter.
> +     * its argument in position {@code pos}, preceded and/or followed by
> +     * any arguments not passed to the filter.
>      * If the filter returns void, the target must accept all arguments
>      * not passed to the filter.

Thanks!

> 
> ? John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From christian.thalinger at oracle.com  Thu Oct  3 14:57:43 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 3 Oct 2013 14:57:43 -0700
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
In-Reply-To: <D1D84FAB-3F66-4414-91E1-A7CD4A92F8DC@oracle.com>
References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
	<239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>
	<523C69EA.3030107@oracle.com>
	<11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com>
	<BABCBAF2-C0A8-4183-B1D9-5D5989051792@oracle.com>
	<D1D84FAB-3F66-4414-91E1-A7CD4A92F8DC@oracle.com>
Message-ID: <1B49E2DD-D109-46B5-B225-856E37177285@oracle.com>

Looks good.

On Oct 2, 2013, at 12:33 PM, John Rose <john.r.rose at oracle.com> wrote:

> Push-button webrev generator to the rescue:
>  http://cr.openjdk.java.net/~jrose/8024599/webrev.01
> 
> ? John
> 
> On Oct 2, 2013, at 11:23 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> Since there is no new webrev I assume you incorporated all the stuff below.  If that's the case then it looks good.
>> 
>> On Sep 20, 2013, at 6:18 PM, John Rose <john.r.rose at oracle.com> wrote:
>> 
>>> On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>> 
>>>> John,
>>>> 
>>>> I don't see much value in documenting buggy behavior of early JDK7 in JDK8 code. So, I would remove it.
>>> 
>>> OK.  I think I had it in mainly to make sure the unit tests did something interesting.
>> 
>>> 
>>>> Regarding the test:
>>>> 31  * @run main/othervm/timeout=3600
>>>> - why do you have timeout set to 1h?
>>> 
>>> Copy-and-paste from some other test.  Removed.
>>> 
>>>> I like the idea how you count events.
>>>> 
>>>> As a suggestion for enhancement - maybe it's more reliable to check the "type" of event as well? To ensure that particular class was initialized.
>>> 
>>> Good idea.  But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types.  I did the following, for each of the six test cases:
>>> 
>>> @@ -150,9 +150,11 @@
>>>   }
>>> 
>>>   private static int runFoo() throws Throwable {
>>> +        assertEquals(Init1Tick, 0);  // Init1 not initialized yet
>>>       int t1 = tick("runFoo");
>>>       int t2 = (int) INDY_foo().invokeExact();
>>>       int t3 = tick("runFoo done");
>>> +        assertEquals(Init1Tick, t2);  // when Init1 was initialized
>>>       assertEquals(t1+2, t3);  // exactly two ticks in between
>>>       assertEquals(t1+1, t2);  // init happened inside
>>>       return t2;
>> 
>>> 
>>> 
>>> ? John
>>> 
>>>> Best regards,
>>>> Vladimir Ivanov
>>>> 
>>>> On 9/20/13 1:38 AM, John Rose wrote:
>>>>> On Sep 12, 2013, at 7:24 PM, John Rose <john.r.rose at oracle.com
>>>>> <mailto:john.r.rose at oracle.com>> wrote:
>>>>> 
>>>>>> Please review this change for a change to the JSR 292 implementation:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
>>>>>> 
>>>>>> Summary: Align MH semantic with bytecode behavior of constructor and
>>>>>> static member accesses, regarding <clinit> invocation.
>>>>>> 
>>>>>> The change is to javadoc and unit tests, documenting and testing some
>>>>>> corner cases of JSR 292 APIs.
>>>>> 
>>>>> I have a reviewer (Alex Buckley) for the documentation changes, but I
>>>>> would also like a quick code review for the unit test.
>>>>> 
>>>>> Also, there is a code insertion (predicated on a "false" symbolic
>>>>> constant) which serves to document the buggy JDK 7 behavior.  I'm not
>>>>> particularly attached to it, so I'm open to either a yea or nay on
>>>>> keeping it.  Leaning nay at the moment.
>>>>> 
>>>>> ? John
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> mlvm-dev mailing list
>>>>> mlvm-dev at openjdk.java.net
>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>> 
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From christian.thalinger at oracle.com  Fri Oct  4 11:17:38 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 4 Oct 2013 11:17:38 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
Message-ID: <6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com>

src/share/classes/java/lang/invoke/MethodHandles.java:

You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.:

+     * If the filter method handle {@code coll} consumes one argument and produces
+     * a non-void result, then {@code collectArguments(mh, N, coll)}
+     * is equivalent to {@code filterArguments(mh, N, coll)}.

Otherwise this looks good.

On Sep 12, 2013, at 7:55 PM, John Rose <john.r.rose at oracle.com> wrote:

> Please review this change for a change to the JSR 292 implementation:
> 
> http://cr.openjdk.java.net/~jrose/8001110/webrev.00/
> 
> Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types
> 
> The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
> 
> Bug Description:  Currently, a method handle can be transformed so that multiple arguments are collected and passed to the original method handle. However, the two routes to doing this are both limited to special purposes. 
> 
> (They are asCollector, which collects only trailing arguments, and only into an array; and foldArguments, which collects only leading arguments into filter function, and passes both the filtered result *and* the original arguments to the original.)
> 
> MethodHandles.collectArguments(mh, pos, collector) should produce a method handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*, x, c*) }, where the span of arguments b* is located by pos and the arity of the collector.
> 
> There is internal machinery in any JSR 292 implementation to do this. It should be made available to users.
> 
> This is a missing part of the JSR 292 spec.
> 
> Thanks,
> ? John
> 
> P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
> Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From john.r.rose at oracle.com  Fri Oct  4 11:34:53 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 4 Oct 2013 11:34:53 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
	<6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com>
Message-ID: <26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com>

Yikes; good catch.  I used javac -Xdoclint to find a couple typos in @param also.  ? John

On Oct 4, 2013, at 11:17 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.:
> 
> +     * If the filter method handle {@code coll} consumes one argument and produces
> +     * a non-void result, then {@code collectArguments(mh, N, coll)}
> +     * is equivalent to {@code filterArguments(mh, N, coll)}.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131004/772ad2a8/attachment.html 

From john.r.rose at oracle.com  Fri Oct  4 14:40:46 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 4 Oct 2013 14:40:46 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
	<6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com>
	<26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com>
Message-ID: <DA478204-6833-4027-AF61-5BD6BC90B1C0@oracle.com>

Actually it's OK:  The name "coll" is defined a couple lines up by the "A collection adapter {@code collectArguments(mh, 0, coll)} ...", and the term "filter" is persistently applied to it. So I think it is intelligible as posted.  ? John

On Oct 4, 2013, at 11:34 AM, John Rose <john.r.rose at oracle.com> wrote:

> Yikes; good catch.  I used javac -Xdoclint to find a couple typos in @param also.  ? John
> 
> On Oct 4, 2013, at 11:17 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.:
>> 
>> +     * If the filter method handle {@code coll} consumes one argument and produces
>> +     * a non-void result, then {@code collectArguments(mh, N, coll)}
>> +     * is equivalent to {@code filterArguments(mh, N, coll)}.
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131004/580b8abc/attachment.html 

From christian.thalinger at oracle.com  Fri Oct  4 14:53:27 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 4 Oct 2013 14:53:27 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <DA478204-6833-4027-AF61-5BD6BC90B1C0@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
	<6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com>
	<26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com>
	<DA478204-6833-4027-AF61-5BD6BC90B1C0@oracle.com>
Message-ID: <498B0E56-0DD9-4B4B-9A0C-6D877421E8C2@oracle.com>


On Oct 4, 2013, at 2:40 PM, John Rose <john.r.rose at oracle.com> wrote:

> Actually it's OK:  The name "coll" is defined a couple lines up by the "A collection adapter {@code collectArguments(mh, 0, coll)} ...", and the term "filter" is persistently applied to it. So I think it is intelligible as posted.  ? John

I'm fine with that.

> 
> On Oct 4, 2013, at 11:34 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
>> Yikes; good catch.  I used javac -Xdoclint to find a couple typos in @param also.  ? John
>> 
>> On Oct 4, 2013, at 11:17 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.:
>>> 
>>> +     * If the filter method handle {@code coll} consumes one argument and produces
>>> +     * a non-void result, then {@code collectArguments(mh, N, coll)}
>>> +     * is equivalent to {@code filterArguments(mh, N, coll)}.
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131004/a403e659/attachment.html 

From george.marrows at googlemail.com  Fri Oct  4 15:49:27 2013
From: george.marrows at googlemail.com (George Marrows)
Date: Fri, 4 Oct 2013 23:49:27 +0100
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
Message-ID: <CAEmy5TFe5FQkHLiusjGxWUnGAESGP0ay0i0CNo3JBpe=_4CFxA@mail.gmail.com>

Hi Martijn,

Yes, I'm interested, along with a couple of other people from work.

I'd suggest 'opposite' to the existing summit, so that we might get some of
the key figures from that conf (Brian Goetz, John Rose, Charlie Nutter etc)
over in Europe. Charlie has certainly said he'd be interested in coming to
one in Europe, particularly if it preceded/followed another European conf
he would like to attend.

Please let me know how plans progress and if there's anything I can do to
help.

Yours, George

George Marrows
General Electric
Cambridge, UK


On Wed, Oct 2, 2013 at 1:38 PM, Martijn Verburg <martijnverburg at gmail.com>wrote:

> Hi all,
>
> Hope this is the right mailing list to post on, apologies for the slight
> OT post.
>
> A few people asked whether the LJC could/would host a JVM language summit
> in Europe which would hopefully cover the EMEA based folks that can't make
> the existing summit.
>
> I'd like to get an idea of whether there's appetite for this and if so
> when it should be run:
>
> * At the same time and have some video-conferencing sessions? OR
> * At a time almost 'opposite' to the existing summit so that there's a
> summit roughly every 6-months.
>
> Ping me directly with your thoughts (unless this is the right mailing list
> - in that case reply back here).
>
> Cheers,
> Martijn
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131004/27b5f703/attachment.html 

From mroos at roos.com  Fri Oct  4 17:35:28 2013
From: mroos at roos.com (Mark Roos)
Date: Fri, 4 Oct 2013 17:35:28 -0700
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAEmy5TFe5FQkHLiusjGxWUnGAESGP0ay0i0CNo3JBpe=_4CFxA@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<CAEmy5TFe5FQkHLiusjGxWUnGAESGP0ay0i0CNo3JBpe=_4CFxA@mail.gmail.com>
Message-ID: <OFD77874F8.70D1F691-ON88257BFA.0082FE59-88257BFB.00033EE7@roos.com>

I would prefer a spring time event in Europe.  I have seen quite enough of 
winter in Europe.

regards
mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131004/ee389c48/attachment.html 

From headius at headius.com  Fri Oct  4 17:38:55 2013
From: headius at headius.com (Charles Oliver Nutter)
Date: Fri, 4 Oct 2013 19:38:55 -0500
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAEmy5TFe5FQkHLiusjGxWUnGAESGP0ay0i0CNo3JBpe=_4CFxA@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<CAEmy5TFe5FQkHLiusjGxWUnGAESGP0ay0i0CNo3JBpe=_4CFxA@mail.gmail.com>
Message-ID: <CAE-f1xSS3s9S9E42JPugGhQ_Wug7sxRFFvVESbGJm51v159ENg@mail.gmail.com>

On Oct 4, 2013 5:50 PM, "George Marrows" <george.marrows at googlemail.com>
wrote:
> I'd suggest 'opposite' to the existing summit, so that we might get some
of the key figures from that conf (Brian Goetz, John Rose, Charlie Nutter
etc) over in Europe. Charlie has certainly said he'd be interested in
coming to one in Europe, particularly if it preceded/followed another
European conf he would like to attend.

Absolutely!

The FOSDEM Java room has kinda served that purpose but it has a broader
focus. I would definitely like an official event.

> On Wed, Oct 2, 2013 at 1:38 PM, Martijn Verburg <martijnverburg at gmail.com>
wrote:
>>
>> Hope this is the right mailing list to post on, apologies for the slight
OT post.

This is a pretty good list. Also JVM-L (I will forward).

>> * At the same time and have some video-conferencing sessions? OR
>> * At a time almost 'opposite' to the existing summit so that there's a
summit roughly every 6-months.

Opposite for sure. I hate to stack another event on the FOSDEM+Jfokus
schedule but that would maybe maximize the number of US folks that would be
there.

- Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131004/fe5eacac/attachment-0001.html 

From cedric.champeau at gmail.com  Fri Oct  4 23:30:26 2013
From: cedric.champeau at gmail.com (=?ISO-8859-1?Q?C=E9dric_Champeau?=)
Date: Sat, 5 Oct 2013 08:30:26 +0200
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
Message-ID: <CADQzvm=3g22DNAYBvunLRKUdWRFokhWGJfSBJ=1z4gTTgqVF0g@mail.gmail.com>

Hi!

I am interested too, and I'd vote for an "opposite" summit.

C?dric


2013/10/2 Martijn Verburg <martijnverburg at gmail.com>

> Hi all,
>
> Hope this is the right mailing list to post on, apologies for the slight
> OT post.
>
> A few people asked whether the LJC could/would host a JVM language summit
> in Europe which would hopefully cover the EMEA based folks that can't make
> the existing summit.
>
> I'd like to get an idea of whether there's appetite for this and if so
> when it should be run:
>
> * At the same time and have some video-conferencing sessions? OR
> * At a time almost 'opposite' to the existing summit so that there's a
> summit roughly every 6-months.
>
> Ping me directly with your thoughts (unless this is the right mailing list
> - in that case reply back here).
>
> Cheers,
> Martijn
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131005/84eaa137/attachment.html 

From martijnverburg at gmail.com  Sat Oct  5 03:09:41 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 5 Oct 2013 11:09:41 +0100
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CADQzvm=3g22DNAYBvunLRKUdWRFokhWGJfSBJ=1z4gTTgqVF0g@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<CADQzvm=3g22DNAYBvunLRKUdWRFokhWGJfSBJ=1z4gTTgqVF0g@mail.gmail.com>
Message-ID: <CAP7YuAThwv0S77Ct0C1cRkCtEa7aUDd1=FjM8NM4zSH91n0Lrg@mail.gmail.com>

Hi all,

Great - I think that's enough positive responses + the ones I got on
twitter :-).  Ben and I will put our thinking caps on and see if we can put
something very close to FOSDEM so that folks can just Eurostar across (it's
the only way to travel ;p).

We'll try to grab some sponsorship etc, but I'll warn people that for now
they should expect to pay their own way for travel and accommodation.

Will post here again when we have some more concrete plans!


Cheers,
Martijn


On 5 October 2013 07:30, C?dric Champeau <cedric.champeau at gmail.com> wrote:

> Hi!
>
> I am interested too, and I'd vote for an "opposite" summit.
>
> C?dric
>
>
> 2013/10/2 Martijn Verburg <martijnverburg at gmail.com>
>
>> Hi all,
>>
>> Hope this is the right mailing list to post on, apologies for the slight
>> OT post.
>>
>> A few people asked whether the LJC could/would host a JVM language summit
>> in Europe which would hopefully cover the EMEA based folks that can't make
>> the existing summit.
>>
>> I'd like to get an idea of whether there's appetite for this and if so
>> when it should be run:
>>
>> * At the same time and have some video-conferencing sessions? OR
>> * At a time almost 'opposite' to the existing summit so that there's a
>> summit roughly every 6-months.
>>
>> Ping me directly with your thoughts (unless this is the right mailing
>> list - in that case reply back here).
>>
>> Cheers,
>> Martijn
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131005/dab604d6/attachment.html 

From benjamin.john.evans at gmail.com  Sat Oct  5 06:23:47 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Sat, 5 Oct 2013 14:23:47 +0100
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAP7YuAThwv0S77Ct0C1cRkCtEa7aUDd1=FjM8NM4zSH91n0Lrg@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<CADQzvm=3g22DNAYBvunLRKUdWRFokhWGJfSBJ=1z4gTTgqVF0g@mail.gmail.com>
	<CAP7YuAThwv0S77Ct0C1cRkCtEa7aUDd1=FjM8NM4zSH91n0Lrg@mail.gmail.com>
Message-ID: <CABKW8RjBfGSxK2uqBY2hihfZmf8mdOhMVCU+KSVQPDLrMrjHdg@mail.gmail.com>

How about a 1.5 day conference on Thursday 30th & morning of Friday 31st
January?

Then people who are coming to Europe for FOSDEM can arrive in London on
Weds, have the language summit for 1.5 days & we can all get the Eurostar
to Brussels together to arrive in time for the Delerium cafe?

Thanks,

Ben


On Sat, Oct 5, 2013 at 11:09 AM, Martijn Verburg
<martijnverburg at gmail.com>wrote:

> Hi all,
>
> Great - I think that's enough positive responses + the ones I got on
> twitter :-).  Ben and I will put our thinking caps on and see if we can put
> something very close to FOSDEM so that folks can just Eurostar across (it's
> the only way to travel ;p).
>
> We'll try to grab some sponsorship etc, but I'll warn people that for now
> they should expect to pay their own way for travel and accommodation.
>
> Will post here again when we have some more concrete plans!
>
>
> Cheers,
> Martijn
>
>
> On 5 October 2013 07:30, C?dric Champeau <cedric.champeau at gmail.com>wrote:
>
>> Hi!
>>
>> I am interested too, and I'd vote for an "opposite" summit.
>>
>> C?dric
>>
>>
>> 2013/10/2 Martijn Verburg <martijnverburg at gmail.com>
>>
>>> Hi all,
>>>
>>> Hope this is the right mailing list to post on, apologies for the slight
>>> OT post.
>>>
>>> A few people asked whether the LJC could/would host a JVM language
>>> summit in Europe which would hopefully cover the EMEA based folks that
>>> can't make the existing summit.
>>>
>>> I'd like to get an idea of whether there's appetite for this and if so
>>> when it should be run:
>>>
>>> * At the same time and have some video-conferencing sessions? OR
>>> * At a time almost 'opposite' to the existing summit so that there's a
>>> summit roughly every 6-months.
>>>
>>> Ping me directly with your thoughts (unless this is the right mailing
>>> list - in that case reply back here).
>>>
>>> Cheers,
>>> Martijn
>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>>
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131005/15332049/attachment.html 

From feeder.of.the.bears at gmail.com  Sun Oct  6 07:24:37 2013
From: feeder.of.the.bears at gmail.com (David Pollak)
Date: Sun, 6 Oct 2013 10:24:37 -0400
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CABKW8RjBfGSxK2uqBY2hihfZmf8mdOhMVCU+KSVQPDLrMrjHdg@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<CADQzvm=3g22DNAYBvunLRKUdWRFokhWGJfSBJ=1z4gTTgqVF0g@mail.gmail.com>
	<CAP7YuAThwv0S77Ct0C1cRkCtEa7aUDd1=FjM8NM4zSH91n0Lrg@mail.gmail.com>
	<CABKW8RjBfGSxK2uqBY2hihfZmf8mdOhMVCU+KSVQPDLrMrjHdg@mail.gmail.com>
Message-ID: <CAH6e9LgqhktoxX9M5j21ivgmrqWyh+5VrSq2Aj+u+kWKHyrHkw@mail.gmail.com>

FWIW, Monkigras is running at the same time:
http://lanyrd.com/2014/monkigras/

I don't know the cross-over between the two conferences, but I put it out
there if there is.


On Sat, Oct 5, 2013 at 9:23 AM, Ben Evans <benjamin.john.evans at gmail.com>wrote:

> How about a 1.5 day conference on Thursday 30th & morning of Friday 31st
> January?
>
> Then people who are coming to Europe for FOSDEM can arrive in London on
> Weds, have the language summit for 1.5 days & we can all get the Eurostar
> to Brussels together to arrive in time for the Delerium cafe?
>
> Thanks,
>
> Ben
>
>
> On Sat, Oct 5, 2013 at 11:09 AM, Martijn Verburg <martijnverburg at gmail.com
> > wrote:
>
>> Hi all,
>>
>> Great - I think that's enough positive responses + the ones I got on
>> twitter :-).  Ben and I will put our thinking caps on and see if we can put
>> something very close to FOSDEM so that folks can just Eurostar across (it's
>> the only way to travel ;p).
>>
>> We'll try to grab some sponsorship etc, but I'll warn people that for now
>> they should expect to pay their own way for travel and accommodation.
>>
>> Will post here again when we have some more concrete plans!
>>
>>
>> Cheers,
>> Martijn
>>
>>
>> On 5 October 2013 07:30, C?dric Champeau <cedric.champeau at gmail.com>wrote:
>>
>>> Hi!
>>>
>>> I am interested too, and I'd vote for an "opposite" summit.
>>>
>>> C?dric
>>>
>>>
>>> 2013/10/2 Martijn Verburg <martijnverburg at gmail.com>
>>>
>>>> Hi all,
>>>>
>>>> Hope this is the right mailing list to post on, apologies for the
>>>> slight OT post.
>>>>
>>>> A few people asked whether the LJC could/would host a JVM language
>>>> summit in Europe which would hopefully cover the EMEA based folks that
>>>> can't make the existing summit.
>>>>
>>>> I'd like to get an idea of whether there's appetite for this and if so
>>>> when it should be run:
>>>>
>>>> * At the same time and have some video-conferencing sessions? OR
>>>> * At a time almost 'opposite' to the existing summit so that there's a
>>>> summit roughly every 6-months.
>>>>
>>>> Ping me directly with your thoughts (unless this is the right mailing
>>>> list - in that case reply back here).
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>>
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>


-- 
Brick Alloy http://brickalloy.com <https://telegr.am>
Lift, the simply functional web framework http://liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131006/fb24a31c/attachment.html 

From john.r.rose at oracle.com  Sun Oct  6 22:42:00 2013
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Mon, 07 Oct 2013 05:42:00 +0000
Subject: hg: mlvm/mlvm/jdk: rebase to current jdk8/tl;
	split meth-{asm,btype,tidy} out of meth-lfc
Message-ID: <20131007054202.2E51662DE2@hg.openjdk.java.net>

Changeset: cf0407968713
Author:    jrose
Date:      2013-10-06 22:41 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/cf0407968713

rebase to current jdk8/tl; split meth-{asm,btype,tidy} out of meth-lfc

- indy-bsm-8024761.patch
- meth-aclone-8001105.patch
- meth-arity-8019417.patch
+ meth-asm.patch
+ meth-btype.patch
- meth-clinit-8024599.patch
- meth-coll-8001110.patch
! meth-counts.patch
! meth-lfc.patch
- meth-mr-8024438.patch
- meth-nsme-8001108.patch
- meth-spr-8001109.patch
+ meth-tidy.patch
! meth.patch
! series
- testng-anti-diff.patch
- tl-fixes.1.patch
- tl-fixes.2.patch
- tl-fixes.3.patch


From john.r.rose at oracle.com  Sun Oct  6 23:32:25 2013
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Mon, 07 Oct 2013 06:32:25 +0000
Subject: hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp
Message-ID: <20131007063226.A2B6462DE4@hg.openjdk.java.net>

Changeset: 4cd7d914b0e3
Author:    jrose
Date:      2013-10-06 23:32 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4cd7d914b0e3

rebase to current hsx/hotspot-comp

! series
! value-obj-8001111.patch


From john.r.rose at oracle.com  Sun Oct  6 23:35:24 2013
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Mon, 07 Oct 2013 06:35:24 +0000
Subject: hg: mlvm/mlvm/jdk: rebase to current jdk8/tl (corrections)
Message-ID: <20131007063525.4A3D562DE5@hg.openjdk.java.net>

Changeset: 93a6c619b0ca
Author:    jrose
Date:      2013-10-06 23:35 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/93a6c619b0ca

rebase to current jdk8/tl (corrections)

! meth-asm.patch
! meth-btype.patch
! meth-lfc.patch
! meth-tidy.patch


From volker.simonis at gmail.com  Mon Oct  7 01:59:38 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 7 Oct 2013 10:59:38 +0200
Subject: JDK7u, hotspot, CC_INTERP, and COBOL
In-Reply-To: <524F0AF0.5050007@orange.fr>
References: <524322D3.4050000@orange.fr>
	<CA+3eh12pEQyHvjGxsLMHidxwsG10qd0OFnkmMSStis3PpEkPXw@mail.gmail.com>
	<524F0AF0.5050007@orange.fr>
Message-ID: <CA+3eh13x-6wkHHu1moWGNZ8Bwd3fsq+hV_PgsM+MP1wRM6A9bg@mail.gmail.com>

What are your settings for 'EnableInvokeDynamic'? If you use the
default which is EnableInvokeDynamic=true then verifier_max_stack()
doesn't account for extra_stack_entries() and this is wrong because
'istate->_stack_limit' does (see the comment in our code).

Your solution probably only seems to work because
'istate->_stack_limit' on x86 currently does not account for
extra_stack_entries() which is wrong (you probalby won't be able to
run any JSR292 code). I think you'll have to add something similar
like

  // max_stack = method->max_stack();
  // TODO: PPC port: assert(2 == methodOopDesc::sz_max_stack(),
"unexpected field size");
  __ ppc_lhz(max_stack, method_(max_stack));

  if (EnableInvokeDynamic) {
    // Take into account 'extra_stack_entries' needed by method
handles (see method.hpp)
    __ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries());
  }

to CppInterpreterGenerator::generate_compute_interpreter_state() on
x86 to make JSR292 work with the CPP interpreter on that platform.
After you did that, you will probably see that the assertion will not
work anymore with verifier_max_stack() and you'll have to use
max_stack() as we did.

The two different versions of the assertion in our code are only
necessary, if you use a HotSpot 24 with a pre HS24 class library, in
which case EnableInvokeDynamic will be switched off after
CppInterpreterGenerator::generate_compute_interpreter_state was
called.

Regards,
Volker


On Fri, Oct 4, 2013 at 8:37 PM, Francis ANDRE
<francis.andre.kampbell at orange.fr> wrote:
> Hi Volker
>
> I had a look to the CPP-Interpreter you mention in your answer and found out
> a somewhat different implementation for verifying the stack size.
>
> here the snippet from the ppc-aix-potr/jdk7u
> #ifdef ASSERT
>   if (istate->_msg != initialize) {
>     // We have a problem here if we are running with a pre-hsx24 JDK (for
> example during bootstrap)
>     // because in that case, EnableInvokeDynamic is true by default but will
> be later switched off
>     // if java_lang_invoke_MethodHandle::compute_offsets() detects that the
> JDK only has the classes
>     // for the old JSR292 implementation.
>     // This leads to a situation where 'istate->_stack_limit' always
> accounts for
>     // methodOopDesc::extra_stack_entries() because it is computed in
>     // CppInterpreterGenerator::generate_compute_interpreter_state() which
> was generated while
>     // EnableInvokeDynamic was still true. On the other hand,
> istate->_method->max_stack() doesn't
>     // account for extra_stack_entries() anymore because at the time when it
> is called
>     // EnableInvokeDynamic was already set to false.
>     // So we have a second version of the assertion which handles the case
> where EnableInvokeDynamic was
>     // switched off because of the wrong classes.
>     if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) {
>       assert(labs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->max_stack() + 1), "bad stack limit");
>     }
>     else {
>       const int extra_stack_entries = 2; // MUST match the value in
> methodOopDesc::extra_stack_entries()
>       assert(labs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->max_stack() + extra_stack_entries
> + 1), "bad stack limit");
>     }
>
>
> On my x86 build, I used this and it seems to work fine also
> #ifdef ASSERT
>   if (istate->_msg != initialize) {
>     assert(abs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->verifier_max_stack() + 1), "bad stack limit");
> #ifndef SHARK
>     IA32_ONLY(assert(istate->_stack_limit == istate->_thread->last_Java_sp()
> + 1, "wrong"));
> #endif // !SHARK
>   }
>
> so I am wondering if it is ok to use the verifier_max_stack() function which
> seems lighter from the lisibility perspective?
>
>
>
> Francis
>
> Le 30/09/2013 17:37, Volker Simonis a ?crit :
>>
>> Just for reference: we have a running CPP-Interpreter on Linux/PPC64
>>
>> with some enhancements like profiling, compressed oops, OSR, JSR292
>> and Biased Locking. So in the case you want to fix it on x86, you may
>> take the PPC64 implementation as a boiler plate:
>>
>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u
>> http://hg.openjdk.java.net/ppc-aix-port/jdk8
>>
>> Regards,
>> Volker
>>
>>
>>
>> On Wed, Sep 25, 2013 at 7:52 PM, Francis ANDRE
>> <francis.andre.kampbell at orange.fr> wrote:
>>>
>>> Hi
>>>
>>> On WXP with VS2010 and the
>>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/
>>> repository, I successfully build and ran the debug version of hotspot in
>>> compiler1 directory. fine
>>>
>>> Next, I tried  to get working the bytecode cppInterpreter instead of the
>>> template based interpreter adding the CC_INTERP=true preprocessor define,
>>> but I got several compile errors -- see below --
>>>
>>> By looking at the Wiki and the OpenJDK website, I discovered that the
>>> cppInterpreter was no more maintained.
>>>
>>> So I am wondering why the cppInterpreter is not anymore maintained and
>>> would
>>> like to understand if this decision is definitive or not, because it
>>> seems
>>> to me that there are very few errors. (see above) and that, IMHO, a
>>> somewhat
>>> small effort should be made to fix the cppInterpreter (but it could be
>>> totally wrong).
>>>
>>> I need the cppInterpreter to make a proposal to the MLVM project to
>>> slightly
>>> change the JVM spec for all xALOAD  and xASTORE bytecodes for a specific
>>> class version number for an efficient support of a _COBOL __runtime_.
>>>
>>> Regards
>>>
>>> Francis
>>>
>>>
>>>   cppInterpreter_x86.cpp
>>> 1>  frame_x86.cpp
>>> 1>  interpreter_x86_32.cpp
>>> 1>  interp_masm_x86_32.cpp
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039:
>>> 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065:
>>> 'interpreter_frame_sender_sp_offset' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039:
>>> 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065:
>>> 'interpreter_frame_last_sp_offset' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039:
>>> 'interpreter_frame_method_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065:
>>> 'interpreter_frame_method_offset' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039:
>>> 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065:
>>> 'interpreter_frame_mdx_offset' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039:
>>> 'interpreter_frame_cache_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065:
>>> 'interpreter_frame_cache_offset' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039:
>>> 'interpreter_frame_locals_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065:
>>> 'interpreter_frame_locals_offset' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039:
>>> 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065:
>>> 'interpreter_frame_bcx_offset' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039:
>>> 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
>>> d?claration de 'frame'
>>> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065:
>>> 'interpreter_frame_initial_sp_offset' : identificateur non d?clar?
>>> 1>  sharedRuntime_x86_32.cpp
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220:
>>> avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r?
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146:
>>> op?rateur
>>> moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign?
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039:
>>> 'increment_mask_and_jump' : n'est pas membre de
>>> 'InterpreterMacroAssembler'
>>> 1> z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
>>> voir
>>> la d?claration de 'InterpreterMacroAssembler'
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur
>>> de
>>> syntaxe : identificateur 'Condition'
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl'
>>> :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): error C3861:
>>> 'incrementl' : identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1422): error C3861: 'movl'
>>> :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1423): error C3861: 'andl'
>>> :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'cond'
>>> :
>>> identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'where'
>>> :
>>> identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C3861: 'jcc' :
>>> identificateur introuvable
>>> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(233): error C2039:
>>> 'empty_expression_stack' : n'est pas membre de
>>> 'InterpreterMacroAssembler'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
>>> voir
>>> la d?claration de 'InterpreterMacroAssembler'
>>> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(235): error C2039:
>>> 'restore_locals' : n'est pas membre de 'InterpreterMacroAssembler'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
>>> voir
>>> la d?claration de 'InterpreterMacroAssembler'
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039:
>>> 'method_handle' : n'est pas membre de 'Interpreter'
>>> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreter.hpp(143)
>>> :
>>> voir la d?claration de 'Interpreter'
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2065:
>>> 'method_handle' : identificateur non d?clar?
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2051:
>>> l'expression associ?e ? case n'est pas une constante
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039:
>>> 'generate_method_handle_entry' : n'est pas membre de
>>> 'InterpreterGenerator'
>>> 1>
>>>
>>> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreterGenerator.hpp(37)
>>> : voir la d?claration de 'InterpreterGenerator'
>>> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2255): error C2064: le
>>> terme
>>> ne correspond pas ? une fonction qui prend 0 arguments
>>> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): error C2220:
>>> avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r?
>>> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): warning C4146:
>>> op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non
>>> sign?
>>> ========== G?n?ration : 0 a r?ussi, 1 a ?chou?, 0 mis ? jour, 0 a ?t?
>>> ignor?
>>> ==========
>>>
>>>
>>>
>>>
>>>
>

From volker.simonis at gmail.com  Tue Oct  8 10:56:32 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 8 Oct 2013 19:56:32 +0200
Subject: JDK7u, hotspot, CC_INTERP, and COBOL
In-Reply-To: <52543E20.1040307@orange.fr>
References: <524322D3.4050000@orange.fr>
	<CA+3eh12pEQyHvjGxsLMHidxwsG10qd0OFnkmMSStis3PpEkPXw@mail.gmail.com>
	<524F0AF0.5050007@orange.fr>
	<CA+3eh13x-6wkHHu1moWGNZ8Bwd3fsq+hV_PgsM+MP1wRM6A9bg@mail.gmail.com>
	<52543E20.1040307@orange.fr>
Message-ID: <CA+3eh13VYAD+d_pTQg+K0qExp0Z+H_-q7gneX7657ZAD9H18nQ@mail.gmail.com>

- reposted without picture -

Hi Francis,

I think the test you used is good (it generates invokedynamic bytecodes
with the ASM library. If you want a better test coverage you could use the
regression tests under jdk/test/java/lang/invoke/.

Regards,
Volker

On Tue, Oct 8, 2013 at 7:17 PM, Francis ANDRE <
francis.andre.kampbell at orange.fr> wrote:

>  Hi Volker
>
> I wanted to test my changes on a simple test that involves InvokeDynamic
> using JDK7. I joined the test I found on the internet and also the output
> of running this test. I run the same way as before where the assert was
> failing before I made the changes.
>
> Can you have a look to this test and tell me if you consider it as a real
> test for the invokedynamic opcode and environment EnableInvokeDynamic as
> true which is the default?
>
> If this ReflectTest.java is not a proper test for testing the
> invokedynamic, could you provide me a test you are considering as a test
> that the interpreter is running fine?
>
>
> Francis
>
>
> Francis
> Le 07/10/2013 10:59, Volker Simonis a ?crit :
>
> What are your settings for 'EnableInvokeDynamic'? If you use the
> default which is EnableInvokeDynamic=true then verifier_max_stack()
> doesn't account for extra_stack_entries() and this is wrong because
> 'istate->_stack_limit' does (see the comment in our code).
>
> Your solution probably only seems to work because
> 'istate->_stack_limit' on x86 currently does not account for
> extra_stack_entries() which is wrong (you probalby won't be able to
> run any JSR292 code). I think you'll have to add something similar
> like
>
>   // max_stack = method->max_stack();
>   // TODO: PPC port: assert(2 == methodOopDesc::sz_max_stack(),
> "unexpected field size");
>   __ ppc_lhz(max_stack, method_(max_stack));
>
>   if (EnableInvokeDynamic) {
>     // Take into account 'extra_stack_entries' needed by method
> handles (see method.hpp)
>     __ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries());
>   }
>
> to CppInterpreterGenerator::generate_compute_interpreter_state() on
> x86 to make JSR292 work with the CPP interpreter on that platform.
> After you did that, you will probably see that the assertion will not
> work anymore with verifier_max_stack() and you'll have to use
> max_stack() as we did.
>
> The two different versions of the assertion in our code are only
> necessary, if you use a HotSpot 24 with a pre HS24 class library, in
> which case EnableInvokeDynamic will be switched off after
> CppInterpreterGenerator::generate_compute_interpreter_state was
> called.
>
> Regards,
> Volker
>
>
> On Fri, Oct 4, 2013 at 8:37 PM, Francis ANDRE<francis.andre.kampbell at orange.fr> <francis.andre.kampbell at orange.fr> wrote:
>
>  Hi Volker
>
> I had a look to the CPP-Interpreter you mention in your answer and found out
> a somewhat different implementation for verifying the stack size.
>
> here the snippet from the ppc-aix-potr/jdk7u
> #ifdef ASSERT
>   if (istate->_msg != initialize) {
>     // We have a problem here if we are running with a pre-hsx24 JDK (for
> example during bootstrap)
>     // because in that case, EnableInvokeDynamic is true by default but will
> be later switched off
>     // if java_lang_invoke_MethodHandle::compute_offsets() detects that the
> JDK only has the classes
>     // for the old JSR292 implementation.
>     // This leads to a situation where 'istate->_stack_limit' always
> accounts for
>     // methodOopDesc::extra_stack_entries() because it is computed in
>     // CppInterpreterGenerator::generate_compute_interpreter_state() which
> was generated while
>     // EnableInvokeDynamic was still true. On the other hand,
> istate->_method->max_stack() doesn't
>     // account for extra_stack_entries() anymore because at the time when it
> is called
>     // EnableInvokeDynamic was already set to false.
>     // So we have a second version of the assertion which handles the case
> where EnableInvokeDynamic was
>     // switched off because of the wrong classes.
>     if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) {
>       assert(labs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->max_stack() + 1), "bad stack limit");
>     }
>     else {
>       const int extra_stack_entries = 2; // MUST match the value in
> methodOopDesc::extra_stack_entries()
>       assert(labs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->max_stack() + extra_stack_entries
> + 1), "bad stack limit");
>     }
>
>
> On my x86 build, I used this and it seems to work fine also
> #ifdef ASSERT
>   if (istate->_msg != initialize) {
>     assert(abs(istate->_stack_base - istate->_stack_limit) ==
> (istate->_method->verifier_max_stack() + 1), "bad stack limit");
> #ifndef SHARK
>     IA32_ONLY(assert(istate->_stack_limit == istate->_thread->last_Java_sp()
> + 1, "wrong"));
> #endif // !SHARK
>   }
>
> so I am wondering if it is ok to use the verifier_max_stack() function which
> seems lighter from the lisibility perspective?
>
>
>
> Francis
>
> Le 30/09/2013 17:37, Volker Simonis a ?crit :
>
>  Just for reference: we have a running CPP-Interpreter on Linux/PPC64
>
> with some enhancements like profiling, compressed oops, OSR, JSR292
> and Biased Locking. So in the case you want to fix it on x86, you may
> take the PPC64 implementation as a boiler plate:
> http://hg.openjdk.java.net/ppc-aix-port/jdk7uhttp://hg.openjdk.java.net/ppc-aix-port/jdk8
>
> Regards,
> Volker
>
>
>
> On Wed, Sep 25, 2013 at 7:52 PM, Francis ANDRE<francis.andre.kampbell at orange.fr> <francis.andre.kampbell at orange.fr> wrote:
>
>  Hi
>
> On WXP with VS2010 and thehttp://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/
> repository, I successfully build and ran the debug version of hotspot in
> compiler1 directory. fine
>
> Next, I tried  to get working the bytecode cppInterpreter instead of the
> template based interpreter adding the CC_INTERP=true preprocessor define,
> but I got several compile errors -- see below --
>
> By looking at the Wiki and the OpenJDK website, I discovered that the
> cppInterpreter was no more maintained.
>
> So I am wondering why the cppInterpreter is not anymore maintained and
> would
> like to understand if this decision is definitive or not, because it
> seems
> to me that there are very few errors. (see above) and that, IMHO, a
> somewhat
> small effort should be made to fix the cppInterpreter (but it could be
> totally wrong).
>
> I need the cppInterpreter to make a proposal to the MLVM project to
> slightly
> change the JVM spec for all xALOAD  and xASTORE bytecodes for a specific
> class version number for an efficient support of a _COBOL __runtime_.
>
> Regards
>
> Francis
>
>
>   cppInterpreter_x86.cpp
> 1>  frame_x86.cpp
> 1>  interpreter_x86_32.cpp
> 1>  interp_masm_x86_32.cpp
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039:
> 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065:
> 'interpreter_frame_sender_sp_offset' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039:
> 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065:
> 'interpreter_frame_last_sp_offset' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039:
> 'interpreter_frame_method_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065:
> 'interpreter_frame_method_offset' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039:
> 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065:
> 'interpreter_frame_mdx_offset' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039:
> 'interpreter_frame_cache_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065:
> 'interpreter_frame_cache_offset' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039:
> 'interpreter_frame_locals_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065:
> 'interpreter_frame_locals_offset' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039:
> 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065:
> 'interpreter_frame_bcx_offset' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039:
> 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la
> d?claration de 'frame'
> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065:
> 'interpreter_frame_initial_sp_offset' : identificateur non d?clar?
> 1>  sharedRuntime_x86_32.cpp
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220:
> avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r?
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146:
> op?rateur
> moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign?
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039:
> 'increment_mask_and_jump' : n'est pas membre de
> 'InterpreterMacroAssembler'
> 1> z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
> voir
> la d?claration de 'InterpreterMacroAssembler'
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur
> de
> syntaxe : identificateur 'Condition'
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl'
> :
> identificateur introuvable
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): error C3861:
> 'incrementl' : identificateur introuvable
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1422): error C3861: 'movl'
> :
> identificateur introuvable
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1423): error C3861: 'andl'
> :
> identificateur introuvable
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'cond'
> :
> identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'where'
> :
> identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C3861: 'jcc' :
> identificateur introuvable
> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(233): error C2039:
> 'empty_expression_stack' : n'est pas membre de
> 'InterpreterMacroAssembler'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
> voir
> la d?claration de 'InterpreterMacroAssembler'
> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(235): error C2039:
> 'restore_locals' : n'est pas membre de 'InterpreterMacroAssembler'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) :
> voir
> la d?claration de 'InterpreterMacroAssembler'
> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039:
> 'method_handle' : n'est pas membre de 'Interpreter'
> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreter.hpp(143)
> :
> voir la d?claration de 'Interpreter'
> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2065:
> 'method_handle' : identificateur non d?clar?
> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2051:
> l'expression associ?e ? case n'est pas une constante
> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039:
> 'generate_method_handle_entry' : n'est pas membre de
> 'InterpreterGenerator'
> 1>
>
> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreterGenerator.hpp(37)
> : voir la d?claration de 'InterpreterGenerator'
> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2255): error C2064: le
> terme
> ne correspond pas ? une fonction qui prend 0 arguments
> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): error C2220:
> avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r?
> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): warning C4146:
> op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non
> sign?
> ========== G?n?ration : 0 a r?ussi, 1 a ?chou?, 0 mis ? jour, 0 a ?t?
> ignor?
> ==========
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131008/2e734f26/attachment-0001.html 

From headius at headius.com  Wed Oct  9 06:50:16 2013
From: headius at headius.com (Charles Oliver Nutter)
Date: Wed, 9 Oct 2013 08:50:16 -0500
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CABKW8RjBfGSxK2uqBY2hihfZmf8mdOhMVCU+KSVQPDLrMrjHdg@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<CADQzvm=3g22DNAYBvunLRKUdWRFokhWGJfSBJ=1z4gTTgqVF0g@mail.gmail.com>
	<CAP7YuAThwv0S77Ct0C1cRkCtEa7aUDd1=FjM8NM4zSH91n0Lrg@mail.gmail.com>
	<CABKW8RjBfGSxK2uqBY2hihfZmf8mdOhMVCU+KSVQPDLrMrjHdg@mail.gmail.com>
Message-ID: <CAE-f1xQmJYeB5Mw9jHtM_n78JZ8aBrVuOFEW2zi0T=_aHhKbCg@mail.gmail.com>

Not bad... I think I could manage that.

- Charlie

On Sat, Oct 5, 2013 at 8:23 AM, Ben Evans <benjamin.john.evans at gmail.com> wrote:
> How about a 1.5 day conference on Thursday 30th & morning of Friday 31st
> January?
>
> Then people who are coming to Europe for FOSDEM can arrive in London on
> Weds, have the language summit for 1.5 days & we can all get the Eurostar to
> Brussels together to arrive in time for the Delerium cafe?
>
> Thanks,
>
> Ben
>
>
> On Sat, Oct 5, 2013 at 11:09 AM, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>>
>> Hi all,
>>
>> Great - I think that's enough positive responses + the ones I got on
>> twitter :-).  Ben and I will put our thinking caps on and see if we can put
>> something very close to FOSDEM so that folks can just Eurostar across (it's
>> the only way to travel ;p).
>>
>> We'll try to grab some sponsorship etc, but I'll warn people that for now
>> they should expect to pay their own way for travel and accommodation.
>>
>> Will post here again when we have some more concrete plans!
>>
>>
>> Cheers,
>> Martijn
>>
>>
>> On 5 October 2013 07:30, C?dric Champeau <cedric.champeau at gmail.com>
>> wrote:
>>>
>>> Hi!
>>>
>>> I am interested too, and I'd vote for an "opposite" summit.
>>>
>>> C?dric
>>>
>>>
>>> 2013/10/2 Martijn Verburg <martijnverburg at gmail.com>
>>>>
>>>> Hi all,
>>>>
>>>> Hope this is the right mailing list to post on, apologies for the slight
>>>> OT post.
>>>>
>>>> A few people asked whether the LJC could/would host a JVM language
>>>> summit in Europe which would hopefully cover the EMEA based folks that can't
>>>> make the existing summit.
>>>>
>>>> I'd like to get an idea of whether there's appetite for this and if so
>>>> when it should be run:
>>>>
>>>> * At the same time and have some video-conferencing sessions? OR
>>>> * At a time almost 'opposite' to the existing summit so that there's a
>>>> summit roughly every 6-months.
>>>>
>>>> Ping me directly with your thoughts (unless this is the right mailing
>>>> list - in that case reply back here).
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>

From david.r.chase at oracle.com  Wed Oct  9 11:49:51 2013
From: david.r.chase at oracle.com (David Chase)
Date: Wed, 9 Oct 2013 14:49:51 -0400
Subject: RFR: 8022718 : Runtime accessibility checking: protected class,
	if extended, should be accessible from another package
Message-ID: <F89F9B69-21A7-4E27-8C0C-781111E51927@oracle.com>


bug: https://bugs.openjdk.java.net/browse/JDK-8022718

webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.00/

Problem: Needed implementation for change to the spec for JVM behavior (from the bug report):

> JSR 335 spec, chapter "15.28.2 Run-time Evaluation of Method References" contains following assertion:
> 
> If the method reference has the form ExpressionName :: NonWildTypeArgumentsopt Identifier or Primary :: NonWildTypeArgumentsopt Identifier, the body of the invocation method has the effect of invoking the compile-time declaration of the method reference, as described in 15.12.4.3, 15.12.4.4, 15.12.4.5.[jsr335-15.28.2-41]
> 
> This assertions refers to chapter "15.12.4.3. Check Accessibility of Type and Method" which contains following assertions:
> 
> Let C be the class containing the method invocation, and let T be the qualifying type of the method invocation (?13.1), and let m be the name of the method as determined at compile-time (?15.12.3).
> ...
> If T is in a different package than C, and T is protected, then T is accessible if and only if C is a subclass of T.
> ...
Note that this cannot be expressed in compatibly compiled Java (yet).  Testing requires either monkeying with change and recompilation, or doctoring bytecodes at runtime.

Fix:
Turns out that all that was needed was the missing case of checking the conditions for protected access,
despite suggestions in the bug report that something different might be needed (the different version of the
access flags was not suitable, and not using them makes for a smaller change anyway).  The new behavior
needed to be mentioned in the Javadoc, so I did.

Testing:
1) wrote new self-contained test to verify behavior (*)
2) jtreg of jdk/lambda java/lang/invoke java/util/stream  (passed)
3) running ute on vm.quick.testlist
4) running JPRT on testset core (well, trying to run JPRT).

Issues:

- It's highly likely I botched the Javadoc changes; I'm sure we have standards, and I'm sure I don't know them.

- (*) The bug, as reported, describes as "wrong" the behavior obtained if the -PUBLIC +PROTECTED access mode appears on the innerclass attributes, not on the class attributes.  I explored this space while developing the test, and if the class itself is marked protected, the failure occurs much earlier in the game when an attempt is made to load the subclass.  The test is written to mimic standalone (with bytecode rewriting) what was seen in the test.

- I decided to put the test in its own subdirectory of test/java/lang/invoke with its own informative name, and not directly in that directory, because all these invocation/protection tests have overlapping and near-overlapping class names, and so it would be confusing not to do this.  Unfortunately, that means there's now two copies of the BogoLoader checked in to the test tree.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131009/0cfafed3/signature.asc 

From john.r.rose at oracle.com  Wed Oct  9 12:22:59 2013
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 9 Oct 2013 12:22:59 -0700
Subject: RFR: 8022718 : Runtime accessibility checking: protected class,
	if extended, should be accessible from another package
In-Reply-To: <F89F9B69-21A7-4E27-8C0C-781111E51927@oracle.com>
References: <F89F9B69-21A7-4E27-8C0C-781111E51927@oracle.com>
Message-ID: <97248223-77FF-48FA-A0ED-978268962952@oracle.com>

On Oct 9, 2013, at 11:49 AM, David Chase <david.r.chase at oracle.com> wrote:

> bug: https://bugs.openjdk.java.net/browse/JDK-8022718
> 
> webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.00/
> 
> Problem: Needed implementation for change to the spec for JVM behavior (from the bug report):
> 
>> JSR 335 spec, chapter "15.28.2 Run-time Evaluation of Method References" contains following assertion:
>> 
>> If the method reference has the form ExpressionName :: NonWildTypeArgumentsopt Identifier or Primary :: NonWildTypeArgumentsopt Identifier, the body of the invocation method has the effect of invoking the compile-time declaration of the method reference, as described in 15.12.4.3, 15.12.4.4, 15.12.4.5.[jsr335-15.28.2-41]
>> 
>> This assertions refers to chapter "15.12.4.3. Check Accessibility of Type and Method" which contains following assertions:
>> 
>> Let C be the class containing the method invocation, and let T be the qualifying type of the method invocation (?13.1), and let m be the name of the method as determined at compile-time (?15.12.3).
>> ...
>> If T is in a different package than C, and T is protected, then T is accessible if and only if C is a subclass of T.
>> ...

JSR 292 doesn't implement the Java language spec; it implements the JVM spec.  In this case there is a difference.

Mixing language and JVM spec. can lead to confusion down the road.

The error is that Class.getModifiers (which is correctly saying "protected") is information about the source code.  The JVM does not look at this for checking access; it looks at the more obscure Reflection.getClassAccessFlags.  Those flags will say "public" (correctly) for a class compiled as "protected".

In order to align exactly with JVM behavior (not Java semantics) the Reflection.getClassAccessFlags need to be looked at.  So I think this fix is wrong.  I think the root cause of this problem was me reaching for Class.getModifiers when I should have grabbed Reflection.getClassAccessFlags.

About BogoLoader:  I would prefer to see it hoisted into a place where more tests can use it.  Consider test/java/lang/invoke/indify/Indify.java as a model; name it test/java/lang/invoke/loader/BogoLoader.java.

? John

> Note that this cannot be expressed in compatibly compiled Java (yet).  Testing requires either monkeying with change and recompilation, or doctoring bytecodes at runtime.
> 
> Fix:
> Turns out that all that was needed was the missing case of checking the conditions for protected access,
> despite suggestions in the bug report that something different might be needed (the different version of the
> access flags was not suitable, and not using them makes for a smaller change anyway).  The new behavior
> needed to be mentioned in the Javadoc, so I did.
> 
> Testing:
> 1) wrote new self-contained test to verify behavior (*)
> 2) jtreg of jdk/lambda java/lang/invoke java/util/stream  (passed)
> 3) running ute on vm.quick.testlist
> 4) running JPRT on testset core (well, trying to run JPRT).
> 
> Issues:
> 
> - It's highly likely I botched the Javadoc changes; I'm sure we have standards, and I'm sure I don't know them.
> 
> - (*) The bug, as reported, describes as "wrong" the behavior obtained if the -PUBLIC +PROTECTED access mode appears on the innerclass attributes, not on the class attributes.  I explored this space while developing the test, and if the class itself is marked protected, the failure occurs much earlier in the game when an attempt is made to load the subclass.  The test is written to mimic standalone (with bytecode rewriting) what was seen in the test.
> 
> - I decided to put the test in its own subdirectory of test/java/lang/invoke with its own informative name, and not directly in that directory, because all these invocation/protection tests have overlapping and near-overlapping class names, and so it would be confusing not to do this.  Unfortunately, that means there's now two copies of the BogoLoader checked in to the test tree.
> 
> David
> 


From david.r.chase at oracle.com  Wed Oct  9 13:18:30 2013
From: david.r.chase at oracle.com (David Chase)
Date: Wed, 9 Oct 2013 16:18:30 -0400
Subject: RFR: 8022718 : Runtime accessibility checking: protected class,
	if extended, should be accessible from another package
In-Reply-To: <97248223-77FF-48FA-A0ED-978268962952@oracle.com>
References: <F89F9B69-21A7-4E27-8C0C-781111E51927@oracle.com>
	<97248223-77FF-48FA-A0ED-978268962952@oracle.com>
Message-ID: <73BAFD52-A7D5-4DF9-996F-9FC5041E7B43@oracle.com>


How about this one?

http://cr.openjdk.java.net/~drchase/8022718/webrev.01/

 This version tests both versions of the modifiers for "public" --
ref.getModifiers apparently sets public in some cases where the other one does not.
Not 100% sure what those cases are, I suspect arrays from the cryptic failure message.

Retested so far on the added test, and on j/l/i/MethodHandlesTest, which has been a fruitful source of problems so far.

David

On 2013-10-09, at 3:22 PM, John Rose <john.r.rose at oracle.com> wrote:
> JSR 292 doesn't implement the Java language spec; it implements the JVM spec.  In this case there is a difference.
> 
> Mixing language and JVM spec. can lead to confusion down the road.
> 
> The error is that Class.getModifiers (which is correctly saying "protected") is information about the source code.  The JVM does not look at this for checking access; it looks at the more obscure Reflection.getClassAccessFlags.  Those flags will say "public" (correctly) for a class compiled as "protected".
> 
> In order to align exactly with JVM behavior (not Java semantics) the Reflection.getClassAccessFlags need to be looked at.  So I think this fix is wrong.  I think the root cause of this problem was me reaching for Class.getModifiers when I should have grabbed Reflection.getClassAccessFlags.
> 
> About BogoLoader:  I would prefer to see it hoisted into a place where more tests can use it.  Consider test/java/lang/invoke/indify/Indify.java as a model; name it test/java/lang/invoke/loader/BogoLoader.java.
> 
> ? John
> 
>> Note that this cannot be expressed in compatibly compiled Java (yet).  Testing requires either monkeying with change and recompilation, or doctoring bytecodes at runtime.
>> 
>> Fix:
>> Turns out that all that was needed was the missing case of checking the conditions for protected access,
>> despite suggestions in the bug report that something different might be needed (the different version of the
>> access flags was not suitable, and not using them makes for a smaller change anyway).  The new behavior
>> needed to be mentioned in the Javadoc, so I did.
>> 
>> Testing:
>> 1) wrote new self-contained test to verify behavior (*)
>> 2) jtreg of jdk/lambda java/lang/invoke java/util/stream  (passed)
>> 3) running ute on vm.quick.testlist
>> 4) running JPRT on testset core (well, trying to run JPRT).
>> 
>> Issues:
>> 
>> - It's highly likely I botched the Javadoc changes; I'm sure we have standards, and I'm sure I don't know them.
>> 
>> - (*) The bug, as reported, describes as "wrong" the behavior obtained if the -PUBLIC +PROTECTED access mode appears on the innerclass attributes, not on the class attributes.  I explored this space while developing the test, and if the class itself is marked protected, the failure occurs much earlier in the game when an attempt is made to load the subclass.  The test is written to mimic standalone (with bytecode rewriting) what was seen in the test.
>> 
>> - I decided to put the test in its own subdirectory of test/java/lang/invoke with its own informative name, and not directly in that directory, because all these invocation/protection tests have overlapping and near-overlapping class names, and so it would be confusing not to do this.  Unfortunately, that means there's now two copies of the BogoLoader checked in to the test tree.
>> 
>> David
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131009/e04146aa/signature.asc 

From david.r.chase at oracle.com  Fri Oct 11 22:14:48 2013
From: david.r.chase at oracle.com (David Chase)
Date: Sat, 12 Oct 2013 01:14:48 -0400
Subject: RFR: 8022718 : Runtime accessibility checking: protected class,
	if extended, should be accessible from another package
In-Reply-To: <73BAFD52-A7D5-4DF9-996F-9FC5041E7B43@oracle.com>
References: <F89F9B69-21A7-4E27-8C0C-781111E51927@oracle.com>
	<97248223-77FF-48FA-A0ED-978268962952@oracle.com>
	<73BAFD52-A7D5-4DF9-996F-9FC5041E7B43@oracle.com>
Message-ID: <37F24081-8D9E-4A8A-8AFA-05ACDA544230@oracle.com>

Further revised after consulting with John Rose on details of fix:

webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.02/

tests:
jtreg of jdk/lambda java/lang/invoke java/util/stream
defmeth (a/b testing)
jprt in progress (assuming I got the incantation right)

David



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131012/76b3ee00/signature.asc 

From martijnverburg at gmail.com  Wed Oct 16 23:49:31 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 17 Oct 2013 07:49:31 +0100
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAH6e9LgqhktoxX9M5j21ivgmrqWyh+5VrSq2Aj+u+kWKHyrHkw@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<CADQzvm=3g22DNAYBvunLRKUdWRFokhWGJfSBJ=1z4gTTgqVF0g@mail.gmail.com>
	<CAP7YuAThwv0S77Ct0C1cRkCtEa7aUDd1=FjM8NM4zSH91n0Lrg@mail.gmail.com>
	<CABKW8RjBfGSxK2uqBY2hihfZmf8mdOhMVCU+KSVQPDLrMrjHdg@mail.gmail.com>
	<CAH6e9LgqhktoxX9M5j21ivgmrqWyh+5VrSq2Aj+u+kWKHyrHkw@mail.gmail.com>
Message-ID: <CAP7YuASK1cWi0HjJ634fC7_QZEKv-uagu0EEM=BGt9_7kB5Fgg@mail.gmail.com>

We work next door to James - I can see something really useful coming out
of this as it's the same space we want to potentially share.  Maybe we can
have a JVM Summit track in the middle of his conference (or off to the
side).  I'll chat to him and see.

Cheers,
Martijn


On 6 October 2013 15:24, David Pollak <feeder.of.the.bears at gmail.com> wrote:

> FWIW, Monkigras is running at the same time:
> http://lanyrd.com/2014/monkigras/
>
> I don't know the cross-over between the two conferences, but I put it out
> there if there is.
>
>
> On Sat, Oct 5, 2013 at 9:23 AM, Ben Evans <benjamin.john.evans at gmail.com>wrote:
>
>> How about a 1.5 day conference on Thursday 30th & morning of Friday 31st
>> January?
>>
>> Then people who are coming to Europe for FOSDEM can arrive in London on
>> Weds, have the language summit for 1.5 days & we can all get the Eurostar
>> to Brussels together to arrive in time for the Delerium cafe?
>>
>> Thanks,
>>
>> Ben
>>
>>
>> On Sat, Oct 5, 2013 at 11:09 AM, Martijn Verburg <
>> martijnverburg at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Great - I think that's enough positive responses + the ones I got on
>>> twitter :-).  Ben and I will put our thinking caps on and see if we can put
>>> something very close to FOSDEM so that folks can just Eurostar across (it's
>>> the only way to travel ;p).
>>>
>>> We'll try to grab some sponsorship etc, but I'll warn people that for
>>> now they should expect to pay their own way for travel and accommodation.
>>>
>>> Will post here again when we have some more concrete plans!
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>>> On 5 October 2013 07:30, C?dric Champeau <cedric.champeau at gmail.com>wrote:
>>>
>>>> Hi!
>>>>
>>>> I am interested too, and I'd vote for an "opposite" summit.
>>>>
>>>> C?dric
>>>>
>>>>
>>>> 2013/10/2 Martijn Verburg <martijnverburg at gmail.com>
>>>>
>>>>> Hi all,
>>>>>
>>>>> Hope this is the right mailing list to post on, apologies for the
>>>>> slight OT post.
>>>>>
>>>>> A few people asked whether the LJC could/would host a JVM language
>>>>> summit in Europe which would hopefully cover the EMEA based folks that
>>>>> can't make the existing summit.
>>>>>
>>>>> I'd like to get an idea of whether there's appetite for this and if so
>>>>> when it should be run:
>>>>>
>>>>> * At the same time and have some video-conferencing sessions? OR
>>>>> * At a time almost 'opposite' to the existing summit so that there's a
>>>>> summit roughly every 6-months.
>>>>>
>>>>> Ping me directly with your thoughts (unless this is the right mailing
>>>>> list - in that case reply back here).
>>>>>
>>>>> Cheers,
>>>>> Martijn
>>>>>
>>>>> _______________________________________________
>>>>> mlvm-dev mailing list
>>>>> mlvm-dev at openjdk.java.net
>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>>
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>
>
> --
> Brick Alloy http://brickalloy.com <https://telegr.am>
> Lift, the simply functional web framework http://liftweb.net
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131017/d7e74b2c/attachment.html 

From david.r.chase at oracle.com  Sun Oct 20 07:37:22 2013
From: david.r.chase at oracle.com (David Chase)
Date: Sun, 20 Oct 2013 10:37:22 -0400
Subject: RFR(S) : 8026818 : Defmeth failures with -mode invoke 
Message-ID: <B577ECA5-DCB9-4E89-AD39-EB6AC061DD8F@oracle.com>


webrev: http://cr.openjdk.java.net/~drchase/8026818/webrev.01/

bug: https://bugs.openjdk.java.net/browse/JDK-8026818

problem:
The report describes a number of problems, cause by 3 separate bugs.

The first is a dupe of https://bugs.openjdk.java.net/browse/JDK-8016839 .

The second is a fault in the test itself, and a proposed patch is now attached to the bug.

The third is caused by code in java.lang.invoke that converts an XXXError into an XXXException,
which is sometimes passed on to client code as that exception, and other times (through other call chains) converted back to an XXXError.  However and unfortunately, there is no such thing as an AbstractMethodException, and so it is mapped to IllegalAccessException; this is the current behavior.  Through the other call chains the IAException is translated back to an error -- IllegalAccessError -- which is not what is specified.

fix:
The code in MethodHandleNatives already attempts to reuse the original Error when it matches the class of the one that would be thrown (to help avoid IllegalAccessError wraps IllegalAccessException wraps IllegalAccessError).  In the case of IAException, a special check is added to see if the original Error was AbstractMethodError, and if it was, throws that instead.

I originally considered mapping IAError to NoSuchMethodException and checking that NSMEx for cause=AMError, but that would change behavior for client code that had originally received IAException.  It's not too weird to think that AMError should map to NSMException, but because of the change in behavior I decided not to do this.

I think this is already reviewed by John Rose -- I pinged him in person, and we discussed the original and revised fix, as well as several others that seemed even less reasonable after a little reflection.

testing:
defmeth, A/B comparisons.
ute, vm.quick.testlist, A/B comparisons.
jtreg, jdk/lambda java/lang/invoke java/util/stream, A/B comparisons.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131020/9272d8d3/signature.asc 

From francis.andre.kampbell at orange.fr  Mon Oct 21 12:10:33 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Mon, 21 Oct 2013 21:10:33 +0200
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
Message-ID: <52657C29.2000804@orange.fr>

Hi Martijn

I am interested by the JVM Summit in Europe. How can I join the process?

Francis
Le 02/10/2013 14:38, Martijn Verburg a ?crit :
> Hi all,
>
> Hope this is the right mailing list to post on, apologies for the slight OT post.
>
> A few people asked whether the LJC could/would host a JVM language summit in 
> Europe which would hopefully cover the EMEA based folks that can't make the 
> existing summit.
>
> I'd like to get an idea of whether there's appetite for this and if so when it 
> should be run:
>
> * At the same time and have some video-conferencing sessions? OR
> * At a time almost 'opposite' to the existing summit so that there's a summit 
> roughly every 6-months.
>
> Ping me directly with your thoughts (unless this is the right mailing list - 
> in that case reply back here).
>
> Cheers,
> Martijn
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131021/d550940d/attachment.html 

From martijnverburg at gmail.com  Tue Oct 22 00:19:52 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 22 Oct 2013 08:19:52 +0100
Subject: JVM Language Summit (Europe)?
In-Reply-To: <52657C29.2000804@orange.fr>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>
	<52657C29.2000804@orange.fr>
Message-ID: <CAP7YuASDKW=HydwduSf_W-FNO6LWmZO24s-DsnTttfJEKOQfeg@mail.gmail.com>

Hi all,

We're working on this (getting a venue etc). I think the focus is likely to
be narrowed to have some presentations/discussions and workshops on Java 9
(10?) related topics. In particular Jigsaw, Type Reification (or not), and
Value Types/Tuples/Packed Objects/Structs/Whatever you want to call them.




Cheers,
Martijn


On 21 October 2013 20:10, Francis ANDRE <francis.andre.kampbell at orange.fr>wrote:

>  Hi Martijn
>
> I am interested by the JVM Summit in Europe. How can I join the process?
>
> Francis
> Le 02/10/2013 14:38, Martijn Verburg a ?crit :
>
> Hi all,
>
>  Hope this is the right mailing list to post on, apologies for the slight
> OT post.
>
>  A few people asked whether the LJC could/would host a JVM language
> summit in Europe which would hopefully cover the EMEA based folks that
> can't make the existing summit.
>
>  I'd like to get an idea of whether there's appetite for this and if so
> when it should be run:
>
>  * At the same time and have some video-conferencing sessions? OR
>  * At a time almost 'opposite' to the existing summit so that there's a
> summit roughly every 6-months.
>
>  Ping me directly with your thoughts (unless this is the right mailing
> list - in that case reply back here).
>
> Cheers,
> Martijn
>
>
> _______________________________________________
> mlvm-dev mailing listmlvm-dev at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131022/b45dd04b/attachment.html 

From francis.andre.kampbell at orange.fr  Tue Oct 22 12:33:48 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Tue, 22 Oct 2013 21:33:48 +0200
Subject: JVM Language Summit (Europe)?
In-Reply-To: <CAP7YuASDKW=HydwduSf_W-FNO6LWmZO24s-DsnTttfJEKOQfeg@mail.gmail.com>
References: <CAP7YuAQySLRFB278OD685uKiRthKL6g66JBSFtCE0wXhp40bHQ@mail.gmail.com>	<52657C29.2000804@orange.fr>
	<CAP7YuASDKW=HydwduSf_W-FNO6LWmZO24s-DsnTttfJEKOQfeg@mail.gmail.com>
Message-ID: <5266D31C.1020705@orange.fr>

Martijn

I would like to make a small presentation about the requirements & ideas for 
extending  the JVM to support a  per formant enterprise  COBOL runtime. I 
already exchange some views long time ago with John Rose but without success (I 
mean, I did not succeed in convincing him about the needed extensions.) This 
should take about 1/2 hour.

May be it would be interesting for all JVM guys to know the problems around 
Cobol, one of the major langage in the computing industry compared to the JVM


Francis

Le 22/10/2013 09:19, Martijn Verburg a ?crit :
> Hi all,
>
> We're working on this (getting a venue etc). I think the focus is likely to be 
> narrowed to have some presentations/discussions and workshops on Java 9 (10?) 
> related topics. In particular Jigsaw, Type Reification (or not), and Value 
> Types/Tuples/Packed Objects/Structs/Whatever you want to call them.
>
>
>
>
> Cheers,
> Martijn
>
>
> On 21 October 2013 20:10, Francis ANDRE <francis.andre.kampbell at orange.fr 
> <mailto:francis.andre.kampbell at orange.fr>> wrote:
>
>     Hi Martijn
>
>     I am interested by the JVM Summit in Europe. How can I join the process?
>
>     Francis
>     Le 02/10/2013 14:38, Martijn Verburg a ?crit :
>>     Hi all,
>>
>>     Hope this is the right mailing list to post on, apologies for the slight
>>     OT post.
>>
>>     A few people asked whether the LJC could/would host a JVM language summit
>>     in Europe which would hopefully cover the EMEA based folks that can't
>>     make the existing summit.
>>
>>     I'd like to get an idea of whether there's appetite for this and if so
>>     when it should be run:
>>
>>     * At the same time and have some video-conferencing sessions? OR
>>     * At a time almost 'opposite' to the existing summit so that there's a
>>     summit roughly every 6-months.
>>
>>     Ping me directly with your thoughts (unless this is the right mailing
>>     list - in that case reply back here).
>>
>>     Cheers,
>>     Martijn
>>
>>
>>     _______________________________________________
>>     mlvm-dev mailing list
>>     mlvm-dev at openjdk.java.net  <mailto:mlvm-dev at openjdk.java.net>
>>     http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>     _______________________________________________
>     mlvm-dev mailing list
>     mlvm-dev at openjdk.java.net <mailto:mlvm-dev at openjdk.java.net>
>     http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131022/eb163f3a/attachment.html