  import static java.lang.invoke.MethodHandles.*;
@@ -2020,17 +2021,22 @@
  ...
  MethodHandle deepToString = publicLookup()
    .findStatic(Arrays.class, "deepToString", methodType(String.class, 
Object[].class));
+
  MethodHandle ts1 = deepToString.asCollector(String[].class, 1);
  assertEquals("[strange]", (String) ts1.invokeExact("strange"));
+
  MethodHandle ts2 = deepToString.asCollector(String[].class, 2);
  assertEquals("[up, down]", (String) ts2.invokeExact("up", "down"));
+
  MethodHandle ts3 = deepToString.asCollector(String[].class, 3);
  MethodHandle ts3_ts2 = collectArguments(ts3, 1, ts2);
  assertEquals("[top, [up, down], strange]",
               (String) ts3_ts2.invokeExact("top", "up", "down", 
"strange"));
+
  MethodHandle ts3_ts2_ts1 = collectArguments(ts3_ts2, 3, ts1);
  assertEquals("[top, [up, down], [strange]]",
               (String) ts3_ts2_ts1.invokeExact("top", "up", "down", 
"strange"));
+
  MethodHandle ts3_ts2_ts3 = collectArguments(ts3_ts2, 1, ts3);
  assertEquals("[top, [[up, down, strange], charm], bottom]",
               (String) ts3_ts2_ts3.invokeExact("top", "up", "down", 
"strange", "charm", "bottom"));


On 9/13/13 6:55 AM, John Rose 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.
>

From rose00 at me.com  Wed Sep 18 19:32:22 2013
From: rose00 at me.com (John Rose)
Date: Wed, 18 Sep 2013 19:32:22 -0700
Subject: RFR (S) 8001105: findVirtual of Object[].clone produces internal error
Message-ID: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>

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



From benjamin.sieffert at metrigo.de  Thu Sep 19 01:37:21 2013
From: benjamin.sieffert at metrigo.de (Benjamin Sieffert)
Date: Thu, 19 Sep 2013 10:37:21 +0200
Subject: Calls to native methods setCallSiteTargetNormal and
	defineAnonymousClass taking very long
Message-ID: 

Hello everyone,

I have been sent over her from the nashorn-dev mailing list. We're having
trouble with our application getting (rather randomly) very busy with calls
to the methods mentioned in the topic. On jdk8, that is. On jdk7, we're
exclusively seeing setCallSiteTargetNormal. This probably has to do with
LambdaForms not being in use on jdk7. Anyway, we're running roughly the
following setup:

- application mantle in JRuby
- application core in Java
- at the VERY core: highly repetitive javascript run via java (switched
from rhino to nashorn recently there)

It's a kind of webserver handling about 2-3k reqeusts per second. Each
request will result in a few dozen calls to our javascript. Since we need
our response times to be as low as possible, we'll not do the
javascript-calls serially, but commit them all to an executor running on a
number of threads equal to the number of available cores (usually 16 or 24
on our machines, 64bit-linux), so that ideally we'll use all cores for
every single request.

In summary: High level of concurrency, huge number of classes and nmethods
generated at runtime (both by jruby and nashorn).
(Some numbers after 20+ hours. jdk8: 140.000 classes live, 1M unloaded.
800mb metaspace exhausted; jdk7: 14.000 live, 2.000 unloaded. 500mb permgen
exhausted)

As for our actual problem, like I said, it's that sometimes all our worker
threads will start to be 100% busy and, when looking at the stack traces,
will all be in one of those two:

1.
at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
Method)
at java.lang.invoke.CallSite.setTargetNormal(CallSite.java:245)
at java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154)
at
jdk.internal.dynalink.support.AbstractRelinkableCallSite.initialize(AbstractRelinkableCallSite.java:115)
at jdk.internal.dynalink.DynamicLinker.link(DynamicLinker.java:184)
at
jdk.nashorn.internal.runtime.linker.Bootstrap.bootstrap(Bootstrap.java:126)
at
java.lang.invoke.LambdaForm$DMH/272755642.invokeStatic_LLLI_L(LambdaForm$DMH)
... (omitting a few invocations of LambdaForm methods)
at java.lang.invoke.LambdaForm$MH/839784351.invoke_MT(LambdaForm$MH)
at java.lang.invoke.CallSite.makeSite(CallSite.java:283)
at
java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:294)
at jdk.nashorn.internal.scripts.Script$\^eval\_._L196(:231)
...

2.
at sun.misc.Unsafe.defineAnonymousClass(Native Method)
at
java.lang.invoke.InvokerBytecodeGenerator.loadAndInitializeInvokerClass(InvokerBytecodeGenerator.java:262)
at
java.lang.invoke.InvokerBytecodeGenerator.loadMethod(InvokerBytecodeGenerator.java:250)
at
java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(InvokerBytecodeGenerator.java:509)
at java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:454)
at java.lang.invoke.LambdaForm.checkInvocationCounter(LambdaForm.java:634)
... (omitting a few invocations of LambdaForm methods)
at java.lang.invoke.LambdaForm$LFI/1682860686.interpret_L(LambdaForm$LFI)
at java.lang.invoke.LambdaForm$MH/1997512181.linkToCallSite(LambdaForm$MH)
at jdk.nashorn.internal.scripts.Script$\^eval\_._L196(:232)
...


Obviously, the application is near unresponsive under these conditions
(i.e. doesn't respond to actual requests from the outside, though you can
connect with jconsole / visualvm / jprofiler just fine and observe it). CPU
will be near 100% bound by these calls, too.

Now there are a few interesting things to note that might help with
diagnosis.
Maybe most importantly, a full gc (we're using CMS, but
CMSClassUnloadingEnabled does not need to be set) will stop the
misbehaviour and will return the application to its normal state.
Obviously, we'd rather not run full gcs all the time, but it's maybe also
interesting to note that this can indeed be triggered by setting (on jdk7)
MaxPermSize low enough or not at all. Apparently the garbage collector will
always find enough space to clean up on PermGen that it doesn't really need
to grow above some threshold -- though the graph showing our PermGen
consumption will then look like the one showing our Heap consumption (i.e.
up and down all the time) and we don't really have good response times,
understandably. So this is not an option to fix the problem, but might be a
clue to what's going on.
A kind of additional problem in this regard is that exhausted PermGen /
MetaSpace will nearly stop increasing under the problematic condition.
Which, in turn, makes a full gc less likely to take place.

Another clue is that we have been able to make the problem happen less
often by dialing back on the amount of reference-replacement we do on our
nashorn-javascript-engines. I.e. those engines have engine-wide bindings
(as according to the javax.script api) you can replace just by calling
.put(bindingName, object) on the engine, even while other threads are
involved in calls inside it. Now apparently this causes much relinking of
callsites to be done and thus fosters our problem.

Still, it's hard to tell what's going on for sure, as we have no stack
traces for what's happening inside the native code. I hope I could give you
some idea.

Best regards
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130919/59175acb/attachment.html 

From john.r.rose at oracle.com  Fri Sep 20 17:09:07 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 20 Sep 2013 17:09:07 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <523CC710.5030806@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
	<523CC710.5030806@oracle.com>
Message-ID: 

On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov  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  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.)

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130920/6827b3b3/attachment.html 

From john.r.rose at oracle.com  Fri Sep 20 18:18:05 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 20 Sep 2013 18:18:05 -0700
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
In-Reply-To: <523C69EA.3030107@oracle.com>
References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
	<239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>
	<523C69EA.3030107@oracle.com>
Message-ID: <11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com>

On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov  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 > > 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  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
>> 


From morris.meyer at oracle.com  Sat Sep 21 02:34:17 2013
From: morris.meyer at oracle.com (Morris Meyer)
Date: Sat, 21 Sep 2013 05:34:17 -0400
Subject: RFR (S) 8001105: findVirtual of Object[].clone produces internal
	error
In-Reply-To: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com>
Message-ID: <4AFDBF02-CFAE-40ED-9BCB-BC53B769AEC2@oracle.com>

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  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

From francis.andre.kampbell at orange.fr  Wed Sep 25 10:52:19 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Wed, 25 Sep 2013 19:52:19 +0200
Subject: JDK7u, hotspot, CC_INTERP, and COBOL
Message-ID: <524322D3.4050000@orange.fr>

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? 
==========





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

From blackdrag at gmx.org  Thu Sep 26 07:20:23 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 26 Sep 2013 16:20:23 +0200
Subject: jdk8 metaspace problem with indy
Message-ID: <524442A7.704@gmx.org>

Hi all,

probably not such a good time to ask, since many of those, that could 
answer this might be on JavaOne... but still

On the user list we got an interesting program that makes quite some 
problems to the jvm as it seems. The groovy program looks like this:

>     println "Started"
>     for(int i = 0; i < 100; i++) {
>         print "."
>         for (int j=0;j<100000;j++) {
>             Container c = new Container()
>             c.run()
>         }
>     }
>     println "\ndone"
>
> public class Container implements Runnable {
>   public Container() {}
>   public void run() {
>     GroovyShell gs = new GroovyShell()
>     Script script = gs.parse("")
>     script.run()
>   }
> }

What happens is that gs.parse will create a new script and a new class 
every time. Now using our custom call site code this works fine. Using 
the indy port, it fails with a permgen error on any jdk7 before u40. On 
u40 this works fine again. In jdk8 this fails sometimes with a metaspace 
error, while in u40 it seems to work quite reliable.

The problem must be more than just creating many classes, because our 
custom callsite caching creates just as many classes for the scripts as 
the indy version does. What does not happen so much there though is code 
generated by reflection and of course non from indy. So I especially 
suspect the code cache here to be responsible for the problem, but I 
have no real basis for this. I lack the means to diagnose the problem 
further

Is there a way to make this work on older jdk7 vms? And is there a way 
for me to make this work on jdk8? Do others here have similar experiences?

bye Jochen
-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From christian.thalinger at oracle.com  Thu Sep 26 18:46:23 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 18:46:23 -0700
Subject: RFR (L) 8024761: JSR 292 improve performance of generic invocation
In-Reply-To: <0F691222-C21B-416E-B029-D8CA7D8ADFE0@oracle.com>
References: <69A734BA-67A8-4BA2-9A8B-075E455327A3@oracle.com>
	
	<0F691222-C21B-416E-B029-D8CA7D8ADFE0@oracle.com>
Message-ID: <321B997C-A151-4162-BF5E-6E37F413AC4B@oracle.com>


On Sep 18, 2013, at 6:43 PM, John Rose  wrote:

> On Sep 18, 2013, at 2:11 PM, Christian Thalinger  wrote:
> 
>> src/share/classes/java/lang/invoke/CallSite.java:
>> 
>> +                    if (3 + argv.length > MethodType.MAX_MH_ARITY)
>> +                    MethodType invocationType = MethodType.genericMethodType(3 + argv.length);
>> +                    MethodHandle spreader = invocationType.invokers().spreadInvoker(3);
>> 
>> Could we use a defined constant for "3"?
> 
> Yes.
>> 
>> src/share/classes/java/lang/invoke/Invokers.java:
>> 
>> +        if (targetType == targetType.erase() && targetType.parameterCount() < 10)
>> 
>> The same here for "10".
> 
> Fixed; factored to a subroutine.
> 
>> Actually, exactInvoker and generalInvoker's code could be factored into one method.
>> 
>> +    /*non-public*/ MethodHandle basicInvoker() {
>> +        //invoker.form.compileToBytecode();
> 
> Done.
> 
>> Please remove commented lines.
>> 
>> +    static MemberName exactInvokeLinkerMethod(MethodType mtype, Object[] appendixResult) {
>> +    static MemberName genericInvokeLinkerMethod(MethodType mtype, Object[] appendixResult) {
>> 
>> These two could also be factored into one method.
> 
> Done.  I removed those two, and called the one new method from MethodHandleNatives.
> 
>> +    // Return an adapter for invokeExact or generic invoke, as a MH or constant pool linker
>> +    // mtype : the caller's method type (either basic or full-custom)
>> +    // customized : whether to use a trailing appendix argument (to carry the mtype)
>> +    // which&0x01 : whether it is a CP adapter ("linker") or MHs.invoker value ("invoker")
>> +    // which&0x02 : whether it is for invokeExact or generic invoke
>> +    //
>> +    // If !customized, caller is responsible for supplying, during adapter execution,
>> +    // a copy of the exact mtype.  This is because the adapter might be generalized to
>> +    // a basic type.
>> +    private static LambdaForm invokeHandleForm(MethodType mtype, boolean customized, int which) {
>> 
>> Why are you not using Javadoc style for this method comment?  It's still helpful in IDEs.
> 
> Fixed.
> 
>> src/share/classes/java/lang/invoke/LambdaForm.java:
>> 
>>    static void traceInterpreter(String event, Object obj, Object... args) {
>> +        if (!(TRACE_INTERPRETER && INIT_DONE))  return;
> 
> Done.
>> 
>> Why not use the same pattern:
>> 
>> +        if (TRACE_INTERPRETER && INIT_DONE)
>> 
>> as the other places?
>> 
>> +    static final boolean INIT_DONE = Boolean.TRUE.booleanValue();
>> 
>> Why are we having this after all?
> 
> I removed it; see webrev.  There's a comment which explains the problem and the nicer replacement.

Good comment.  Thank you.

> 
>> src/share/classes/java/lang/invoke/MemberName.java:
>> 
>> +    public MemberName asNormalOriginal() {
>> 
>> Could you add a comment to this method?  It's not clear to me what "normal" and "original" mean here.
> 
> Done.
> 
>> +    public MemberName(byte refKind, Class defClass, String name, Object type) {
>> +        @SuppressWarnings("LocalVariableHidesMemberVariable")
>> +        int kindFlags;
>> 
>> The SuppressWarnings is in the other constructors because of the name "flags".  You don't need it here.  Maybe rename the others as well and get rid of the annotation.
> 
> OK; I removed 2/3 of them.
> 
>> src/share/classes/java/lang/invoke/MethodHandleNatives.java:
>> 
>>    static String refKindName(byte refKind) {
>>        assert(refKindIsValid(refKind));
>> -        return REFERENCE_KIND_NAME[refKind];
>> +        switch (refKind) {
>> 
>> After this change REFERENCE_KIND_NAME is not used anymore.
> 
> Good catch.
> 
>> src/share/classes/java/lang/invoke/MethodHandles.java:
>> 
>> +            member.getName().getClass(); member.getType().getClass();  // NPE
>> 
>> Please don't!  It would be nice to have at least a different line number in the backtrace.
> 
> OK.  I split three such lines.
> 
> I would like to switch all these to Objects.requireNonNull, but only after a little performance testing to make sure we don't have surprises.
> 
>> src/share/classes/java/lang/invoke/MethodTypeForm.java:
>> 
>> +            //Lookup.findVirtual(MethodHandle.class, name, type);
>> 
>> Either remove it or add a comment why it's there.
> 
> Commented better now.

> 
> While testing, I found a spot in BoundMethodHandle that needed a tweak to avoid a bootstrap problem.  (Too many of those.)

> 
> I sharpened the type of 'caller' in CallSite.makeSite.

> 
> The webrev is updated:
>  http://cr.openjdk.java.net/~jrose/8024761/webrev.01/

This looks good.

> 
> Thanks!
> 
> ? John
> 
>> On Sep 12, 2013, at 6:36 PM, John Rose  wrote:
>> 
>>> Please review this change for a change to the JSR 292 implementation:
>>> 
>>> http://cr.openjdk.java.net/~jrose/8024761/webrev.00/
>>> 
>>> Bug description:  The performance of MethodHandle.invoke is very slow when the call site type differs from the method handle type. When the types differ, the invocation is defined to proceed as if two steps were taken: 
>>> 
>>> 1. the target method handle is first adjusted to the call site type, by MethodHandles.asType 
>>> 
>>> 2. the type-adjusted method handle is invoked directly, by MethodHandles.invokeExact 
>>> 
>>> The existing code (from JDK 7) awkwardly performs the type adjustment on every call. But performing the type analysis and adapter creation on every call is inherently slow. A good fix is to cache the result of step 1 (MethodHandles.asType), since step 2 is already reasonably fast. 
>>> 
>>> For most applications, a one-element cache on each individual method handle is a reasonable choice. It has the particular advantage of speeding up invocations of non-varargs bootstrap methods. To benefit from this, the bootstrap methods themselves need to be uniquified across multiple class files, so this work will also include a cache to benefit commonly-used bootstrap methods, such as JDK 8's LambdaMetafactory.metafactory. 
>>> 
>>> Additional caches could be based on the call site, the call site type, the target type, or the target's MH.form. 
>>> 
>>> Thanks,
>>> ? John
>>> 
>>> P.S. Since this is an implementation change oriented toward performance, the review request is to mlvm-dev and hotspot-compiler-dev.
>>> Changes which are oriented toward functionality will go to mlvm-dev and core-libs-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  Thu Sep 26 18:52:01 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 18:52:01 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
	<9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
	
Message-ID: <70118D67-B367-461B-A4F2-04B2FB18047D@oracle.com>


On Sep 19, 2013, at 9:57 AM, David Chase  wrote:

> Recommended changes made:
> 
> http://cr.openjdk.java.net/~drchase/8022701/webrev.04/

Looks good.  Thanks for using ASM.

> 
> Test with jtreg (for pass and for induced failure) on MacOS,
> not sure what additional other testing is desired since it is entirely in the libraries.
> 
> I included code to handle the case of a broken field-referencing methodhandle,
> but did not test it because there's no syntax for these in Java, nor is their creation
> well-documented.
> 
> David
> 
> 
> On 2013-09-13, at 12:02 AM, John Rose  wrote:
> 
>> On Sep 12, 2013, at 5:44 PM, David Chase  wrote:
>> 
>>> Do these sibling bugs have numbers?
>> 
>> Yes, 8022701.  I just updated the bug to explain their common genesis.
>> 
>>> And I take it you would like to see
>>> 
>>> 1) a test enhanced with ASM to do all 3 variants of this
>> 
>> Yes, please.  The case of "no such field" does not have a direct cause from lambda expressions AFAIK, but it can occur with "raw" CONSTANT_MethodHandles.  (It would be reasonable for javac to emit CONSTANT_MH's for fields in some very limited circumstances, but I'll bet it doesn't.)
>> 
>>> 2) DO attach the underlying cause
>> 
>> Yes.  Read the javadoc for ExceptionInInitializerError for an example of why users want the underlying cause for linkage errors.
>> 
>> (Golly, I wonder what happens if resolution of a CONSTANT_MethodHandle tries to touch a class with a booby-trapped .  I hope it's the case that the ExceptionInInitializerError just passes straight up the stack.  But if it were to get wrapped in a ROE of some sort, it would probably bubble up as an IAE.  Could be a charming exploration.  Actually, no, I don't want to go in there.  Getting all possible linkage errors correct is fine, but we have more important things to do.)
>> 
>> ? John
>> 
>>> David
>>> 
>>> On 2013-09-12, at 5:35 PM, John Rose  wrote:
>>> 
>>>> It looks good.  I have three requests.
>>>> 
>>>> Regarding this comment:
>>>> +     * See MethodSupplier.java to see how to produce these bytes.
>>>> +     * They encode that class, except that method m is private, not public.
>>>> 
>>>> The recipe is incomplete, since it does not say which bits to tweak to make m private.  Please add that step to the comments more explicitly, or if possible to the code (so bogusMethodSupplier is a clean copy of the od output).  I suppose you could ask sed to change the byte for you.  That will make this test a better example for future tests, and make it easier to maintain if javac output changes.  The high road to use would be asm, although for a single byte tweak od works OK.
>>>> 
>>>> Also, this bug has two twins.  The same thing will happen with NoSuchMethodE* and NoSuchFieldE*.  Can you please make fixes for those guys also?
>>>> 
>>>> FTR, see MemberName.makeAccessException() for logic which maps the other way, from *Error to *Exception.  I don't see a direct way to avoid the double mapping (Error=>Exception=>Error) when it occurs.
>>>> 
>>>> For the initCause bit we should do this:
>>>> 
>>>>     } catch (IllegalAccessException ex) {
>>>>         Error err = new IllegalAccessError(ex.getMessage());
>>>>         err.initCause(ex.getCause());  // reuse underlying cause of ex
>>>>         throw err;
>>>>     } ... and for NSME and NSFE...
>>>> 
>>>> That way users can avoid the duplicate exception but can see any underlying causes that the JVM may include.
>>>> 
>>>> Thanks for untangling this!
>>>> 
>>>> ? John
>>>> 
>>>> On Sep 12, 2013, at 12:17 PM, David Chase  wrote:
>>>> 
>>>>> The test is adapted from the test in the bug report.
>>>>> The headline on the bug report is wrong -- because it uses reflection in the test to do the invocation,
>>>>> the thrown exception is wrapped with InvocationTargetException, which is completely correct.
>>>>> HOWEVER, the exception inside the wrapper is the wrong one.
>>>>> 
>>>>> The new test checks the exception in both the reflective-invocation and plain-invocation cases,
>>>>> and also checks both a method handle call (which threw the wrong exception) and a plain
>>>>> call (which threw, and throws, the right exception).
>>>>> 
>>>>> The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get
>>>>> the error, so it is not only shell-free, it can also be run outside jtreg.
>>>>> 
>>>>> On 2013-09-12, at 2:34 PM, Christian Thalinger  wrote:
>>>>> 
>>>>>> 
>>>>>> On Sep 12, 2013, at 11:28 AM, David Chase  wrote:
>>>>>> 
>>>>>>> New webrev, commented line removed:
>>>>>>> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
>>>>>> 
>>>>>> I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?
>>>>>> 
>>>>>> And it would be good if John could also have a quick look (just be to be sure).
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> On 2013-09-12, at 1:53 PM, David Chase  wrote:
>>>>>>> 
>>>>>>>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>>>>>>>> 
>>>>>>>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>>>>>>>> 
>>>>>>>>> +             // err.initCause(ex);
>>>>>>>>> 
>>>>>>>>> Why is this commented?
>>>>>>>>> 
>>>>>>>>> -- Chris
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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  Thu Sep 26 18:55:00 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 18:55:00 -0700
Subject: RFR (S) 8001108: an attempt to use "" as a method name
	should elicit NoSuchMethodException
In-Reply-To: <99860D39-C18B-4638-94BB-12084139AE1E@oracle.com>
References: <6FAC275C-6374-41F5-BAB7-CA1AC729EF9F@oracle.com>
	<09F68115-21E6-450C-8DC2-6FCDB6C191B4@oracle.com>
	<99860D39-C18B-4638-94BB-12084139AE1E@oracle.com>
Message-ID: <35BFE992-4E0C-4816-851B-EE871FA375F2@oracle.com>


On Sep 19, 2013, at 2:31 PM, John Rose  wrote:

> 
> On Sep 18, 2013, at 5:05 PM, Christian Thalinger  wrote:
> 
>> src/share/classes/java/lang/invoke/MethodHandles.java:
>> 
>> +     * methods as if they were normal methods, but the JVM verifier rejects them.
>> 
>> I think you should say "JVM byte code verifier" here.
> 
> Done.  s/byte code/bytecode/.
> 
>> 
>> +         * (Note:  JVM internal methods named {@code } not visible to this API,
>> +         * even though the {@code invokespecial} instruction can refer to them
>> +         * in special circumstances.  Use {@link #findConstructor findConstructor}
>> 
>> Not exactly sure but should this read "are not visible"?
> 
> Yes.
> 
>> 
>>        MemberName resolveOrFail(byte refKind, Class refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException {
>> +            type.getClass();  // NPE
>>            checkSymbolicClass(refc);  // do this before attempting to resolve
>> -            name.getClass(); type.getClass();  // NPE
>> +            checkMethodName(refKind, name);
>> 
>> Could you add a comment here saying that checkMethodName does an implicit null pointer check on name?  Maybe a comment for checkMethodName too.
> 
> Done.
> 
>> 
>> What was the problem with the null pointer exceptions?  Is it okay that we might throw another exception before null checking name?
> 
> Foo.  The reordering of those null checks seems to be a needless change that crept in.  I'm going to keep them the way they are.
> 
> See updated webrev:
>  http://cr.openjdk.java.net/~jrose/8001108/webrev.01/

Looks good.

> 
> ? John
> 
>> On Sep 12, 2013, at 6:47 PM, John Rose  wrote:
>> 
>>> Please review this change for a change to the JSR 292 implementation:
>>> 
>>> http://cr.openjdk.java.net/~jrose/8001108/webrev.00
>>> 
>>> Summary: add an explicit check for leading "<", upgrade the unit tests
>>> 
>>> The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
>>> 
>>> In the RI, there is an explicit error check.
>>> 
>>> 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
>> 
>> _______________________________________________
>> 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  Thu Sep 26 19:16:38 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 19:16:38 -0700
Subject: jdk8 metaspace problem with indy
In-Reply-To: <524442A7.704@gmx.org>
References: <524442A7.704@gmx.org>
Message-ID: <2AE76E37-87D6-4518-9643-6398448749C5@oracle.com>


On Sep 26, 2013, at 7:20 AM, Jochen Theodorou  wrote:

> Hi all,
> 
> probably not such a good time to ask, since many of those, that could 
> answer this might be on JavaOne... but still
> 
> On the user list we got an interesting program that makes quite some 
> problems to the jvm as it seems. The groovy program looks like this:
> 
>>    println "Started"
>>    for(int i = 0; i < 100; i++) {
>>        print "."
>>        for (int j=0;j<100000;j++) {
>>            Container c = new Container()
>>            c.run()
>>        }
>>    }
>>    println "\ndone"
>> 
>> public class Container implements Runnable {
>>  public Container() {}
>>  public void run() {
>>    GroovyShell gs = new GroovyShell()
>>    Script script = gs.parse("")
>>    script.run()
>>  }
>> }
> 
> What happens is that gs.parse will create a new script and a new class 
> every time. Now using our custom call site code this works fine. Using 
> the indy port, it fails with a permgen error on any jdk7 before u40. On 
> u40 this works fine again. In jdk8 this fails sometimes with a metaspace 
> error, while in u40 it seems to work quite reliable.
> 
> The problem must be more than just creating many classes, because our 
> custom callsite caching creates just as many classes for the scripts as 
> the indy version does. What does not happen so much there though is code 
> generated by reflection and of course non from indy. So I especially 
> suspect the code cache here to be responsible for the problem, but I 
> have no real basis for this. I lack the means to diagnose the problem 
> further
> 
> Is there a way to make this work on older jdk7 vms? And is there a way 
> for me to make this work on jdk8? Do others here have similar experiences?

Is this 64-bit with compressed oops?  Is tiered compilation on?

> 
> bye Jochen
> -- 
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
> 
> _______________________________________________
> 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 Sep 26 19:19:10 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 19:19:10 -0700
Subject: JDK7u, hotspot, CC_INTERP, and COBOL
In-Reply-To: <524322D3.4050000@orange.fr>
References: <524322D3.4050000@orange.fr>
Message-ID: 


On Sep 25, 2013, at 10:52 AM, Francis ANDRE  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.

I have no idea if it works on Windows but on Linux you can build Zero:

http://openjdk.java.net/projects/zero/

Zero uses the C++ interpreter.

> 
> 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 francis.andre.kampbell at orange.fr  Thu Sep 26 19:40:33 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Fri, 27 Sep 2013 04:40:33 +0200
Subject: JDK7u, hotspot, CC_INTERP, and COBOL
In-Reply-To: 
References: <524322D3.4050000@orange.fr>
	
Message-ID: <5244F021.8060803@orange.fr>

Hi Christian

Ok, I will have a look at Zero and try to make it on windows. Thanks for the 
pointer.

Le 27/09/2013 04:19, Christian Thalinger a ?crit :
> On Sep 25, 2013, at 10:52 AM, Francis ANDRE  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.
> I have no idea if it works on Windows but on Linux you can build Zero:
>
> http://openjdk.java.net/projects/zero/
>
> Zero uses the C++ interpreter.

>
>> 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 john.r.rose at oracle.com  Thu Sep 26 21:33:26 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 26 Sep 2013 21:33:26 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
	<9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
	
Message-ID: 

On Sep 19, 2013, at 9:57 AM, David Chase  wrote:

> Recommended changes made:
> 
> http://cr.openjdk.java.net/~drchase/8022701/webrev.04/

Good; reviewed.

Consider adding this tweak, which would close the loop on alternation between the fooError and fooException versions:

+    static private void initCauseFrom(Error err, Exception ex) {
+        Throwable th = ex.getCause();
++      if (err.getClass().isInstance(th))  throw (Error) th;
+        err.initCause(th == null ? ex : th);
+    }

E.g., if the reason for linkage failure was originally NoSuchMethodError, but was mapped to NoSuchMethodException (which can happen in MemberName.makeAccessException) then the original NoSuchMethodError is extracted and thrown, rather than a new NoSuchMethodError which wraps the original NoSuchMethodError.

> Test with jtreg (for pass and for induced failure) on MacOS,
> not sure what additional other testing is desired since it is entirely in the libraries.

Your test case is enough.

> I included code to handle the case of a broken field-referencing methodhandle,
> but did not test it because there's no syntax for these in Java, nor is their creation
> well-documented.

That's fine.  Ship it, preferably with the tweak above.

? John

From forax at univ-mlv.fr  Thu Sep 26 23:13:19 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 27 Sep 2013 08:13:19 +0200
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
	<9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
	
	
Message-ID: <524521FF.5090706@univ-mlv.fr>

On 09/27/2013 06:33 AM, John Rose wrote:
> On Sep 19, 2013, at 9:57 AM, David Chase  wrote:
>
>> Recommended changes made:
>>
>> http://cr.openjdk.java.net/~drchase/8022701/webrev.04/
> Good; reviewed.
>
> Consider adding this tweak, which would close the loop on alternation between the fooError and fooException versions:
>
> +    static private void initCauseFrom(Error err, Exception ex) {
> +        Throwable th = ex.getCause();
> ++      if (err.getClass().isInstance(th))  throw (Error) th;
> +        err.initCause(th == null ? ex : th);
> +    }
>
> E.g., if the reason for linkage failure was originally NoSuchMethodError, but was mapped to NoSuchMethodException (which can happen in MemberName.makeAccessException) then the original NoSuchMethodError is extracted and thrown, rather than a new NoSuchMethodError which wraps the original NoSuchMethodError.

I'm late in this game but having a method initCauseFrom() that throws an 
exception (an error exactly)
seems plainly wrong to me.

>
>> Test with jtreg (for pass and for induced failure) on MacOS,
>> not sure what additional other testing is desired since it is entirely in the libraries.
> Your test case is enough.
>
>> I included code to handle the case of a broken field-referencing methodhandle,
>> but did not test it because there's no syntax for these in Java, nor is their creation
>> well-documented.
> That's fine.  Ship it, preferably with the tweak above.
>
> ? John

R?mi


From blackdrag at gmx.org  Fri Sep 27 00:55:24 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 27 Sep 2013 09:55:24 +0200
Subject: jdk8 metaspace problem with indy
In-Reply-To: <2AE76E37-87D6-4518-9643-6398448749C5@oracle.com>
References: <524442A7.704@gmx.org>
	<2AE76E37-87D6-4518-9643-6398448749C5@oracle.com>
Message-ID: <524539EC.4010806@gmx.org>

Am 27.09.2013 04:16, schrieb Christian Thalinger:
[...]
>> Is there a way to make this work on older jdk7 vms? And is there a way
>> for me to make this work on jdk8? Do others here have similar experiences?
>
> Is this 64-bit with compressed oops?  Is tiered compilation on?

It has been run with a 64bit Linux JVM on default settings. So I think 
the answer to both is yes.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From blackdrag at gmx.org  Fri Sep 27 01:07:48 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 27 Sep 2013 10:07:48 +0200
Subject: jdk8 metaspace problem with indy
In-Reply-To: <2AE76E37-87D6-4518-9643-6398448749C5@oracle.com>
References: <524442A7.704@gmx.org>
	<2AE76E37-87D6-4518-9643-6398448749C5@oracle.com>
Message-ID: <52453CD4.3060907@gmx.org>

Am 27.09.2013 04:16, schrieb Christian Thalinger:
>
> On Sep 26, 2013, at 7:20 AM, Jochen Theodorou  wrote:
[...]
>> Is there a way to make this work on older jdk7 vms? And is there a way
>> for me to make this work on jdk8? Do others here have similar experiences?
>
> Is this 64-bit with compressed oops?  Is tiered compilation on?

It has been run with a 64bit Linux JVM on default settings.

I just tried on jdk7u25 -XX:-UseCompressedOops and 
-XX:-TieredCompilation and I tried with only one of them active, there 
is no change in how it behaves

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From david.r.chase at oracle.com  Fri Sep 27 05:08:15 2013
From: david.r.chase at oracle.com (David Chase)
Date: Fri, 27 Sep 2013 08:08:15 -0400
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: <524521FF.5090706@univ-mlv.fr>
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
	<9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
	
	
	<524521FF.5090706@univ-mlv.fr>
Message-ID: 


http://cr.openjdk.java.net/~drchase/8022701/webrev.06/

Changes made, incorporating Rose and Forax comments.
Anyone care to push this for me?

     /**
+     * Use best possible cause for err.initCause(), substituting the
+     * cause for err itself if the cause has the same (or better) type.
+     */
+    static private Error initCauseFrom(Error err, Exception ex) {
+        Throwable th = ex.getCause();
+        if (err.getClass().isInstance(th))
+           return (Error) th;
+        err.initCause(th == null ? ex : th);
+        return err;
+    }
+
+    /**

Or should I convert the calls to one-liners?

+        } catch (IllegalAccessException ex) {
+            Error err = new IllegalAccessError(ex.getMessage());
+            throw initCauseFrom(err, ex);
+        } catch (NoSuchMethodException ex) {
+            Error err = new NoSuchMethodError(ex.getMessage());
+            throw initCauseFrom(err, ex);
+        } catch (NoSuchFieldException ex) {
+            Error err = new NoSuchFieldError(ex.getMessage());
+            throw initCauseFrom(err, ex);

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/20130927/1d9cdf0e/signature.asc 

From blackdrag at gmx.org  Fri Sep 27 07:31:04 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 27 Sep 2013 16:31:04 +0200
Subject: MethodHandles#catchException bug in jdk7u40 and jdk8ea ?
Message-ID: <524596A8.5050502@gmx.org>

Hi again,

I have a Groovy-indy program looking like this 
https://gist.github.com/abargnesi/6628656

This did work in 7u25 and does not work in 7u40 or the developer preview 
of jdk8. What I found out is, if you remove an argument the 
IllegalArgumentException is not thrown

What I have (using 7u40 debug information) is a SimpleMethodHandle
type: (Class,int,Class,Class,Class,Class,Class,Class,Class)Object
lambda: convert=Lambda(a0:L,a1:L,a2:I,a3:L,a4:L,a5:L,a6:L,a7:L,a8:L,a9:L)=>{
     t10:L=MethodHandle(int)Object(a2:I);
arity: 10

On this I call
MethodHandles.catchException(handle, GroovyRuntimeException.class, 
UNWRAP_EXCEPTION);
UNWRAP_EXCEPTION is the the result of a findStatic and looks basically 
like this:
>     public static Object unwrap(GroovyRuntimeException gre) throws Throwable {
>         throw ScriptBytecodeAdapter.unwrap(gre);
>     }
(I add it more for the signature, than for the content.)

After the the call to catchException the type of the handle is changed 
to one containing for everything Object, instead of the original type:

SimpleMethodHandle
type: (Object,Object,Object,Object,Object,Object,Object,Object,Object)Object
lambda: 
collect=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L,a5:L,a6:L,a7:L,a8:L,a9:L)=>{ 
t10:L=ValueConversions.array(a1:L,a2:L,a3:L,a4:L,a5:L,a6:L,a7:L,a8:L,a9:L);
     t11:L=MethodHandle(Object[])Object(t10:L);t11:L}
arity: 10

Later on I add a switchpoint guard, which expects the original type and 
thus I get a runtime error about mismatched types. With a lower arity 
the type change does not happen.

Now.. looking at the documentation of the method I then this here:

>      * T target(A..., B...);
>      * T handler(ExType, A...);
>      * T adapter(A... a, B... b) {
>      *   try {
>      *     return target(a..., b...);
>      *   } catch (ExType ex) {
>      *     return handler(ex, a...);
>      *   }
>      * }

implies to me, that the type of the returned handle (adapter) should be 
equal to the type of the handle target. And that would mean this is a bug.

Am I right about this? If this is no bug, then the documentation 
absolutely needs an update, plus I doubt such behaviour is good for 
performance.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From coleen.phillimore at oracle.com  Mon Sep 30 07:48:02 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Sep 2013 10:48:02 -0400
Subject: jdk8 metaspace problem with indy
In-Reply-To: <524442A7.704@gmx.org>
References: <524442A7.704@gmx.org>
Message-ID: <52498F22.6020706@oracle.com>


Hi,  Stefan has found the cause of the problem you have described this 
thread, but we're discussing internally how to fix it.  I'll let him 
explain.

Thanks,
Coleen

On 09/26/2013 10:20 AM, Jochen Theodorou wrote:
> Hi all,
>
> probably not such a good time to ask, since many of those, that could
> answer this might be on JavaOne... but still
>
> On the user list we got an interesting program that makes quite some
> problems to the jvm as it seems. The groovy program looks like this:
>
>>      println "Started"
>>      for(int i = 0; i < 100; i++) {
>>          print "."
>>          for (int j=0;j<100000;j++) {
>>              Container c = new Container()
>>              c.run()
>>          }
>>      }
>>      println "\ndone"
>>
>> public class Container implements Runnable {
>>    public Container() {}
>>    public void run() {
>>      GroovyShell gs = new GroovyShell()
>>      Script script = gs.parse("")
>>      script.run()
>>    }
>> }
> What happens is that gs.parse will create a new script and a new class
> every time. Now using our custom call site code this works fine. Using
> the indy port, it fails with a permgen error on any jdk7 before u40. On
> u40 this works fine again. In jdk8 this fails sometimes with a metaspace
> error, while in u40 it seems to work quite reliable.
>
> The problem must be more than just creating many classes, because our
> custom callsite caching creates just as many classes for the scripts as
> the indy version does. What does not happen so much there though is code
> generated by reflection and of course non from indy. So I especially
> suspect the code cache here to be responsible for the problem, but I
> have no real basis for this. I lack the means to diagnose the problem
> further
>
> Is there a way to make this work on older jdk7 vms? And is there a way
> for me to make this work on jdk8? Do others here have similar experiences?
>
> bye Jochen


From blackdrag at gmx.org  Mon Sep 30 08:03:07 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Mon, 30 Sep 2013 17:03:07 +0200
Subject: jdk8 metaspace problem with indy
In-Reply-To: <52498F22.6020706@oracle.com>
References: <524442A7.704@gmx.org> <52498F22.6020706@oracle.com>
Message-ID: <524992AB.80309@gmx.org>

Hi,

good to hear, that the problem is understood and worked on ;)
Since you guys know what the problem is, is there a way to prevent this 
to happen on jdk7 before u40?

bye Jochen

Am 30.09.2013 16:48, schrieb Coleen Phillimore:
>
> Hi,  Stefan has found the cause of the problem you have described this
> thread, but we're discussing internally how to fix it.  I'll let him
> explain.
>
> Thanks,
> Coleen
>
> On 09/26/2013 10:20 AM, Jochen Theodorou wrote:
>> Hi all,
>>
>> probably not such a good time to ask, since many of those, that could
>> answer this might be on JavaOne... but still
>>
>> On the user list we got an interesting program that makes quite some
>> problems to the jvm as it seems. The groovy program looks like this:
>>
>>>       println "Started"
>>>       for(int i = 0; i < 100; i++) {
>>>           print "."
>>>           for (int j=0;j<100000;j++) {
>>>               Container c = new Container()
>>>               c.run()
>>>           }
>>>       }
>>>       println "\ndone"
>>>
>>> public class Container implements Runnable {
>>>     public Container() {}
>>>     public void run() {
>>>       GroovyShell gs = new GroovyShell()
>>>       Script script = gs.parse("")
>>>       script.run()
>>>     }
>>> }
>> What happens is that gs.parse will create a new script and a new class
>> every time. Now using our custom call site code this works fine. Using
>> the indy port, it fails with a permgen error on any jdk7 before u40. On
>> u40 this works fine again. In jdk8 this fails sometimes with a metaspace
>> error, while in u40 it seems to work quite reliable.
>>
>> The problem must be more than just creating many classes, because our
>> custom callsite caching creates just as many classes for the scripts as
>> the indy version does. What does not happen so much there though is code
>> generated by reflection and of course non from indy. So I especially
>> suspect the code cache here to be responsible for the problem, but I
>> have no real basis for this. I lack the means to diagnose the problem
>> further
>>
>> Is there a way to make this work on older jdk7 vms? And is there a way
>> for me to make this work on jdk8? Do others here have similar experiences?
>>
>> bye Jochen
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From volker.simonis at gmail.com  Mon Sep 30 08:37:45 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 30 Sep 2013 17:37:45 +0200
Subject: JDK7u, hotspot, CC_INTERP, and COBOL
In-Reply-To: <524322D3.4050000@orange.fr>
References: <524322D3.4050000@orange.fr>
Message-ID: 

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
 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 stefan.karlsson at oracle.com  Mon Sep 30 08:10:04 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 30 Sep 2013 17:10:04 +0200
Subject: jdk8 metaspace problem with indy
In-Reply-To: <52498F22.6020706@oracle.com>
References: <524442A7.704@gmx.org> <52498F22.6020706@oracle.com>
Message-ID: <5249944C.6040409@oracle.com>

On 2013-09-30 16:48, Coleen Phillimore wrote:
>
> Hi,  Stefan has found the cause of the problem you have described this 
> thread, but we're discussing internally how to fix it.  I'll let him 
> explain.

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

StefanK

>
> Thanks,
> Coleen
>
> On 09/26/2013 10:20 AM, Jochen Theodorou wrote:
>> Hi all,
>>
>> probably not such a good time to ask, since many of those, that could
>> answer this might be on JavaOne... but still
>>
>> On the user list we got an interesting program that makes quite some
>> problems to the jvm as it seems. The groovy program looks like this:
>>
>>>      println "Started"
>>>      for(int i = 0; i < 100; i++) {
>>>          print "."
>>>          for (int j=0;j<100000;j++) {
>>>              Container c = new Container()
>>>              c.run()
>>>          }
>>>      }
>>>      println "\ndone"
>>>
>>> public class Container implements Runnable {
>>>    public Container() {}
>>>    public void run() {
>>>      GroovyShell gs = new GroovyShell()
>>>      Script script = gs.parse("")
>>>      script.run()
>>>    }
>>> }
>> What happens is that gs.parse will create a new script and a new class
>> every time. Now using our custom call site code this works fine. Using
>> the indy port, it fails with a permgen error on any jdk7 before u40. On
>> u40 this works fine again. In jdk8 this fails sometimes with a metaspace
>> error, while in u40 it seems to work quite reliable.
>>
>> The problem must be more than just creating many classes, because our
>> custom callsite caching creates just as many classes for the scripts as
>> the indy version does. What does not happen so much there though is code
>> generated by reflection and of course non from indy. So I especially
>> suspect the code cache here to be responsible for the problem, but I
>> have no real basis for this. I lack the means to diagnose the problem
>> further
>>
>> Is there a way to make this work on older jdk7 vms? And is there a way
>> for me to make this work on jdk8? Do others here have similar 
>> experiences?
>>
>> bye Jochen
>

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

From blackdrag at gmx.org  Mon Sep 30 11:49:16 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Mon, 30 Sep 2013 20:49:16 +0200
Subject: jdk8 metaspace problem with indy
In-Reply-To: <5249944C.6040409@oracle.com>
References: <524442A7.704@gmx.org> <52498F22.6020706@oracle.com>
	<5249944C.6040409@oracle.com>
Message-ID: <5249C7AC.4040900@gmx.org>

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 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

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


