Looks good. Matches the existing JVMS. Thanks for the tests.
thanks,
Karen
> On Jun 19, 2018, at 8:08 PM, Paul Sandoz wrote:
>
> Hi,
>
> Please review the following fix to ensure method references to VarHandle
> signature polymorphic methods are supported at runtime (specifically the
> metho
the VM can
>>>>> perform access control based on those attributes and so allow direct
>>>>> private access between nestmates without requiring javac to generate
>>>>> synthetic accessor methods. These access control changes also extend to
>>
Looks good!
Thank you so much David and Vladimir for all the work to cover the corner cases.
thanks,
Karen
> On Apr 26, 2018, at 12:12 AM, David Holmes wrote:
>
> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/
>
> Karen formulated an additional test scenario invoking O
ote:
>
> On 3/27/2018 2:49 AM, Claes Redestad wrote:
>
>>
>>
>> On 2018-03-26 17:51, Claes Redestad wrote:
>>> Karen,
>>>
>>> On 2018-03-26 17:15, Karen Kinnear wrote:
>>>> Claes,
>>>>
>>>> Discussed with L
Claes,
Discussed with Lois. We think that it would make more sense to pass the new
argument into MethodHandles::resolve_MemberName and at all three places that we
currently CHECK_PENDING_EXCEPTION/return null there
- if speculative flag is set - CLEAR_PENDING_EXCEPTION before you return null
at line 786 of
> systemDictionary.cpp.
> http://cr.openjdk.java.net/~hseigel/bug_8184289.3/webrev/index.html
> <http://cr.openjdk.java.net/~hseigel/bug_8184289.3/webrev/index.html>
> Thanks, Harold
>
> On 2/12/2018 2:39 PM, Karen Kinnear wrote:
>> Harold,
>>
&
Harold,
Thanks for doing this.
I think you told me that
1) the version change has made it in
2) you also put 12 as an expiration date
3) you are running the ParallelClassLoading tests with the remaining two flags
(you’ve already
run them without any flags):
AllowParallelDefineClass = true and
Paul,
Thank you for the explanations. Asking for your help in some test case
construction at the end here:
>> 3. java/lang/invoke/package-info.java 128-134
>> Error handling could be clearer.
>> My understanding is that if a LinkageError or subclass is thrown, this will
>> be rethrown
>> for al
Thank you so much for doing this jointly.
Couple of questions/comments:
1. thank you for making UseBootstrapCallInfo diagnostic
2. org/objectweb/asmClassReader.java
why hardcoded 17 instead of ClassWriter.CONDY?
3. java/lang/invoke/package-info.java 128-134
Error handling could be clearer.
My un
+1
Karen
> On Nov 10, 2016, at 5:56 PM, David Holmes wrote:
>
>
>
> On 11/11/2016 8:46 AM, Mandy Chung wrote:
>>
>>> On Nov 10, 2016, at 2:28 PM, Peter Levart wrote:
>>>
>>> On 11/10/2016 05:59 PM, Alan Bateman wrote:
On 10/11/2016 17:42, David M. Lloyd wrote:
> My ori
For the record, I reviewed the jvm changes and they look good.
thanks,
Karen
> On May 4, 2016, at 3:29 PM, Mandy Chung wrote:
>
> The default implementation of ObjectInputStream::resolveClass and
> resolveProxyClass finds the user-defined class loader on the stack and
> assumes that only syst
in the
java.util.concurrent
libraries can experiment with the mechanism and add incremental improvements.
thanks,
Karen
> On Nov 22, 2015, at 7:04 PM, Doug Lea wrote:
>
> On 11/20/2015 12:40 PM, Karen Kinnear wrote:
>> Totally appreciate the suggestion that the java.
njdk.java.net/~fparain/8046936/webrev.01/hotspot/
> <http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/>
> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/
> <http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/>
>
> On 20/11/2015 19:44, Karen Ki
Frederic,
Code review for web revs you sent out.
Code looks good. I am not as familiar with the compiler code.
I realize you need to check in at least a subset of the java.util.concurrent
changes for
the test to work, so maybe I should not have asked Doug about his preference
there.
Sorry.
I a
Totally appreciate the suggestion that the java.util.concurrent modifications
be done by folks with more domain expertise.
Would you have us incorporate the initial minimal set of j.u.c. updates or none
at all?
thanks,
Karen
> On Nov 11, 2015, at 8:09 PM, Doug Lea wrote:
>
> On 11/10/2015 12:
One other example is an unlock that requires three steps - update state, update
owner and
unpark successor.
thanks,
Karen
> On Nov 19, 2015, at 9:25 PM, David Holmes wrote:
>
> On 20/11/2015 4:10 AM, Doug Lea wrote:
>> On 11/16/2015 08:00 PM, David Holmes wrote:
I've tried that :-) The am
Coleen,
Question for you below please ...
> On Oct 30, 2015, at 3:44 PM, Coleen Phillimore
> wrote:
>
>
> Hi Ioi,
> This is a manageable code change.
>
> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html
>
> You forward decl
Seconded. For the hash code, talk to Coleen and ask her who did the work in
core libs recently.
In addition, those bits are fiercely sought after - we have other things we
would like to do with any available bits and I am
not convinced this is more valuable. We just resisted using one for the jd
;return (super.loadClass(name, resolve));
> }
>
> Thanks
>
> - Ioi
>
> On 10/29/14, 12:10 PM, Mandy Chung wrote:
>>
>> On 10/29/2014 7:16 AM, Karen Kinnear wrote:
>>> Sorry, I was confused about who wrote what.
>>>
>>>
:
> On 29/10/2014 4:04 PM, Ioi Lam wrote:
>>
>> On 10/28/14, 7:34 PM, David Holmes wrote:
>>> Hi Karen,
>>>
>>> I haven't been tracking the details of this and am unclear on the
>>> overall caching strategy however ...
>>>
>>&
David,
On Oct 29, 2014, at 2:04 AM, Ioi Lam wrote:
>
> On 10/28/14, 7:34 PM, David Holmes wrote:
>> Hi Karen,
>>
>> I haven't been tracking the details of this and am unclear on the overall
>> caching strategy however ...
>>
>> On 29
Ioi,
Looks good! Thanks to all who have contributed!
A couple of minor comments/questions:
1. jvm.h (hotspot and jdk)
All three APIs talk about loader_type, but the code uses loader.
2. Launcher.java
To the best of my understanding - the call to findLoadedClass does not require
synchronizing
Peter,
Which hotspot algorithm is the one you identified as slow? Would that be
for loading the class or for Class.getMethods?
thanks,
Karen
On Oct 23, 2014, at 9:37 AM, Peter Levart wrote:
> On 10/23/2014 01:57 AM, Stanimir Simeonoff wrote:
>> Class.java can easily be improved by adding an aux
Looks good. Ship it!
thank you so much Ioi, Jiangli, Calvin, Yumin and David for all the hard work!
Karen
On Aug 13, 2014, at 2:25 AM, Ioi Lam wrote:
> Hi,
>
> Thank you all for the reviews! I have prepared a final version that has
> incorporated all the comments.
>
> http://cr.openjdk.java.n
Ioi,
Changes look really good. Just minor comments:
1. jdk: SecureClassLoader.java: getProtectionDomain
please add a comment that this assumes no signers and combine the first and
third lines
2. classFileParser.cpp
Would it make sense to move the assertion from skip_over_field_name for
DumpSha
g error
> (AME instead of NPE) because the resolved code goes directly to the
> itable and sees the null method.
>
> With Methodhandles, resolution and invocation are separate, and it
> always throws the wrong error.
>
> Fix:
>
> I considered (and discussed with John
Changeset: e39b138b2518
Author:acorn
Date: 2013-10-19 18:32 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e39b138b2518
8026893: Push 8026365 to TL early and add test
Reviewed-by: dcubed, kamg
! src/share/vm/classfile/verifier.cpp
! test/TEST.groups
+ test/runtime/802636
.
>
> David
>
> On 11/10/2013 12:32 AM, Karen Kinnear wrote:
>> Joel,
>>
>> Thank you for the review.
>>
>> Actually, that is a very good question.
>> We will be adding the test case for this one to our vm side
>> defmeth.PrivateMethodsTest,
y much like Paul's suggestion - thank you again
On Oct 10, 2013, at 9:47 AM, Karen Kinnear wrote:
> Paul,
>
> Thank you so much for the review and suggestion. I will rewrite this this way
> and resend.
>
> thanks!
> Karen
>
> On Oct 10, 2013, at 5:13 AM, Paul Sa
than 15 times?
>
> cheers
> /Joel
>
> On 2013-10-09, Karen Kinnear wrote:
>>
>> Please review:
>>
>> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213
>>
>> Summary:
&
David,
Thanks for the information.
The VM side of this is 8011311 which pushed on 10/8 to jdk8 master to be part
of JDK8b111.
thanks,
Karen
On Oct 10, 2013, at 5:06 AM, David Holmes wrote:
> Hi Karen,
>
> On 10/10/2013 8:13 AM, Karen Kinnear wrote:
>>
>> Please review
Thank you Remi.
I'm actually going to leave the assertion. We are frequently asked to expand
limits and
catching this if that time ever happens would make our lives much easier.
thanks,
Karen
On Oct 10, 2013, at 5:21 AM, Remi Forax wrote:
> On 10/10/2013 12:13 AM, Karen Kinne
Paul,
Thank you so much for the review and suggestion. I will rewrite this this way
and resend.
thanks!
Karen
On Oct 10, 2013, at 5:13 AM, Paul Sandoz wrote:
>
> On Oct 10, 2013, at 12:13 AM, Karen Kinnear wrote:
>
>>
>> Please review:
>>
>> webrev:
Please review:
webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8026213
Summary:
Reflection generates code dynamically to speed up reflection processing after
startup. The first
15 runs of a reflection call use the vm code path, after that
Thank you, we really appreciate all testing.
I have a fix in a prototype in the vm for this. Let me know if you want an
early patch.
Or you can just file a bug and that way you'll know when the fix is officially
in the tree.
thanks,
Karen
On Sep 12, 2013, at 10:59 AM, Peter Levart wrote:
> H
Kumar,
Looks good. And thank you - we definitely needed the URLClassLoader so that we
actually test the verifier, unless we had a force -Xverify:all flag. Thank you
for
fixing the major version from 0x33 ->0x34.
I presume the push will also delete the file from the current location :-)
thanks,
Vladimir Ivanov has already written tests at the classfile level, which javac
doesn't generate.
They do not all pass yet, which is why they are not on by default.
Let me know if anyone wants to study the details.
Note that there is already a bug filed to remove the bridging and covariant
return
Frederic,
Code looks good - actually it looks very clean. Ship it.
Couple of minor comments that don't require re-review:
1. nmtDCmd.hpp/cpp - copyrights 2012 -> 2012, 2013
2. jmm.h
line 213: "True is" -> "True if"
3. diagnosticFramework.hpp
Thank you for the comments!
line 298 "rational
Changeset: d254a5f9b93f
Author:acorn
Date: 2013-03-27 13:40 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d254a5f9b93f
8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java
Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52
Rev
Changeset: 4f520ce7ba3f
Author:acorn
Date: 2013-02-13 16:09 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f520ce7ba3f
8007888: jdk fix default method: VerifyError: Illegal use of nonvirtual
Summary: Recognize VM generated method in old verifier. With 8004967
Reviewed-by: co
Dan,
I had a question on this comment.
Should we fix this in hotspot?
So you mention recent Linux open() documentation.
How does this behave on Solaris and Mac? I assume the library code is shared
code across platforms.
Also - what is the oldest Linux we support for JDK8?
thanks,
Karen
On Jan
Bharadwaj,
Makes me glad Remi brought up his concerns :-)
I like the additional checking. I wonder if you could possibly modify this to
rename
the API to JVM_IsVMGeneratedMethodIx - since that might be clearer that this is
has internal
vm meaning which is not related to any of the specification
Change looks good give I don't know any way for the java library to get the
internal method type information.
Can you please fix the spelling of "implementation" in the comment?
thanks,
Karen
p.s. And I think you are ensuring !abstract by doing an exact match of flags.
On Jan 16, 2013, at 1:35
David,
I fully support the concept of a fully concurrent class loader, which allows
parallel defineClass.
I would agree that we deprecate registerAsParallelCapable - starting
deprecation in JDK8.
My memory is that customers asked us for the getClassLoadingLock API so that
they could
do their
JVM_FindClassFromBootLoader is new with JDK7. Kumar added it.
thanks,
Karen
On Jul 24, 2009, at 11:07 AM, Paul Hohensee wrote:
Can't remove it unless it's fixed in jdk6 as well as 7. Also, one
of these days we'll
get around to shipping current hotspot in jdk5 and maybe 1.4.2. How
would th
Heiko,
I'm copying this to the core-libs-dev@openjdk.java.net alias, since
I think the APIs you are referring to are more familiar to that team.
And I've retitled it "Java JRE" so folks see the bigger picture.
hope this helps,
Karen
Heiko Wagner wrote:
Hi,
I am currently investigating on a pr
and comments to this mailing list or to any of the following development engineers. Karen Kinnear, VM runtime technical lead - [EMAIL PROTECTED] Valerie Peng, VM core libraries - [EMAIL PROTECTED] Jeff Nisewanger, VM core libraries - [EMAIL PROTECTED]
Title: ClassLoaderForTest < HotspotRunt
47 matches
Mail list logo
