Thank you Ulf.
I removed the fix in toString method and in debug classes:
http://cr.openjdk.java.net/~weijun/8055723/webrev.00/
On Mon, Oct 20, 2014 at 10:26 PM, Ulf Zibis wrote:
>
> Am 21.10.2014 um 01:02 schrieb Otávio Gonçalves de Santana:
>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK
Hi Jiangli,
Thanks for the review. Please see comments in-line:
On 10/21/14, 2:04 PM, Jiangli Zhou wrote:
Hi Ioi,
Here are some comments from me:
-src/share/vm/classfile/classLoader.cpp
In ClassLoader::setup_search_path, if canonicalize is true it's not
necessary to allocate the 'path' and c
Hi Mandy,
Thanks for the review. I have updated the patch:
http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v2/
Please see comments in-line.
On 10/21/14, 12:56 PM, Mandy Chung wrote:
Hi Ioi,
On 10/21/14 10:27 AM, Ioi Lam wrote:
Please review this fix:
http://cr.openjdk.java.net/~
Thanks Dalibor!
Could someone with the Reviewer status review this please?
Sincerely yours,
Ivan
On 23.10.2014 18:07, dalibor topic wrote:
Approved pending positive review.
On 21.10.2014 08:36, Ivan Gerasimov wrote:
Hello everybody!
This is a request for review of a fix which is applicable
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8049522/webrev/
to address the issue
https://bugs.openjdk.java.net/browse/JDK-8049522
this is javadoc change, which amends the implNote in ORB.java,
relating to the ORBSingleton class loading strategy in JDK9.
regar
Hi,
Using unsafe to read fields will make the code very brittle and require
us to further detect and buffer types and which fields to read and
handle. Currently this seems to be a rather uncommon case, as the code
in Adler32 and CRC32 has done a full allocation in JDK 8, and by far
either wra
On 10/23/2014 02:10 PM, Mandy Chung wrote:
Sean,
I have included a few security tests in this patch:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8043277/webrev.01/
Looks good.
--Sean
Sean,
I have included a few security tests in this patch:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8043277/webrev.01/
Mandy
On 10/22/14 6:08 PM, Mandy Chung wrote:
jtreg policy option overrides the system security policy file and hence
some existing test policy files have to duplicate t
On 23 Oct 2014, at 17:44, Peter Levart wrote:
>
> Is there a test that validates correctness of getMethods() or at least a set
> of interfaces and/or classes to exercise the algorithm and compare it to a
> different implementation?
>
There is :)
http://hg.openjdk.java.net/jdk9/dev/jdk/file/
On Oct 23, 2014, at 1:25 PM, Konstantin Shefov
wrote:
> Gently reminder
>
> On 17.10.2014 13:38, Konstantin Shefov wrote:
>> Hi,
>>
>> I have updated the webrev:
>> http://cr.openjdk.java.net/~kshefov/8059070/webrev.01/
>>
+1
Sorry for the delay,
Paul.
On 10/23/2014 05:44 PM, Peter Levart wrote:
interface A6 extends B6, C6 {}
interface B6 extends D6 { void m(); }
interface C6 extends D6 {}
interface D6 { default void m() {}; }
A6.class.getMethods() returns B6.m, D6.m
Ah, B6.m re-abstracts the default method D6.m. I can see the rule here.
N
On 10/23/2014 05:06 PM, Joel Borggrén-Franck wrote:
Hi Martin,
On 23 okt 2014, at 00:53, Martin Buchholz wrote:
Here at Google we have both kinds of scalability problems - loading classes
from a classpath with 10,000 jars, and loading a single class file packed
with the maximal number of meth
On 10/23/2014 03:48 PM, Karen Kinnear wrote:
Peter,
Which hotspot algorithm is the one you identified as slow? Would that be
for loading the class or for Class.getMethods?
thanks,
Karen
Martin did it. And Alexey profiled it.
I just noted that Java part of Class.getMethods(), should it be
re
Hi Martin,
On 23 okt 2014, at 00:53, Martin Buchholz wrote:
> Here at Google we have both kinds of scalability problems - loading classes
> from a classpath with 10,000 jars, and loading a single class file packed
> with the maximal number of methods. This message is about the latter.
>
> If y
I was under the impression the declaring order has been abandoned in 1.7
which I considered quite a let down as allowed ordering the function calls
in JMX in a non-chaotic way.
On Thu, Oct 23, 2014 at 4:37 PM, Peter Levart
wrote:
> On 10/23/2014 01:57 AM, Stanimir Simeonoff wrote:
>
>> Class.j
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
On 23/10/2014 02:08, Mandy Chung wrote:
jtreg policy option overrides the system security policy file and hence
some existing test policy files have to duplicate the entries to grant
permissions for JDK.
This looks okay to me too. I think this will be the first use of a
jtreg4.1-b10 feature and
On 10/23/2014 01:57 AM, Stanimir Simeonoff wrote:
Class.java can easily be improved by adding an auxiliary HasMap indexing the position in the array by name and then checking
only few overloaded signatures in case of a match.
The auxiliary map can be deployed only past some threshold of methods,
This looks good to me Mandy, and nice to see the superfluous grants being
removed.
-Chris.
On 23 Oct 2014, at 02:08, Mandy Chung wrote:
> jtreg policy option overrides the system security policy file and hence
> some existing test policy files have to duplicate the entries to grant
> permissio
On 10/23/2014 02:54 AM, Mandy Chung wrote:
On 10/22/2014 4:58 PM, Claes Redestad wrote:
This test uses a special class loader that delegates to null class
loader only. Since you have the verification in place, it'd be good
to also call Package.getPackage and Package.getPackages to verify
Gently reminder
On 17.10.2014 13:38, Konstantin Shefov wrote:
Hi,
I have updated the webrev:
http://cr.openjdk.java.net/~kshefov/8059070/webrev.01/
-Konstantin
16.10.2014 17:24, Igor Ignatyev пишет:
Konstantin,
I haven't looked at code religiously, so I wouldn't say that I have
reviewed it.
Hi Martin,
On 23.10.2014 02:53, Martin Buchholz wrote:
> If you have a class with ~64k methods with a superclass that also has ~64k
> methods, class loading that single class will cost you ~30sec and calling
> Class.getMethods another ~10sec. Both are unacceptably slow. I think both
> are due to
On Oct 22, 2014, at 5:09 PM, Kumar Srinivasan
wrote:
> Hello,
>
> Please review fix for JDK-8061830, this is merely a refresh of the existing
> source
> base from upstream ObjectWeb/ASM, the webrev is here:
> http://cr.openjdk.java.net/~ksrini/8061830/webrev.00/
>
+1
Paul.
On 10/23/2014 10:16 AM, Stanimir Simeonoff wrote:
Unsafe is available, so the fields (array, offset) can be read directly
UNSAFE.getObject(buffer, hbOffset), UNSAFE.getObject(buffer, offsetOffset).
No need for MethodHandlers.
During class init the offsets have to be resolved, pretty much like any
On 21.10.2014 23:09, huizhe wang wrote:
> http://cr.openjdk.java.net/~joehw/jdk9/8061686/webrev/
+1 (not a Reviewer)
-Aleksey
>>, UNSAFE.getObject(buffer, offsetOffset)
Obviously should be Unsafe.getInt(buffer, offsetOffset)
On Thu, Oct 23, 2014 at 11:16 AM, Stanimir Simeonoff
wrote:
> Unsafe is available, so the fields (array, offset) can be read directly
> UNSAFE.getObject(buffer, hbOffset), UNSAFE.getObject(buffer,
Unsafe is available, so the fields (array, offset) can be read directly
UNSAFE.getObject(buffer, hbOffset), UNSAFE.getObject(buffer, offsetOffset).
No need for MethodHandlers.
During class init the offsets have to be resolved, pretty much like any CAS
utilizing algorithm.
I didn't propose it as re
On 10/23/2014 03:52 AM, Staffan Friberg wrote:
Webrev with these last updates. Added more tests to make sure CRC32C,
CRC32 and Checksum default methods all are covered.
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.07
Hi Staffan,
Regarding default case:
168 } else {
28 matches
Mail list logo
