+1
-Sundar
On Wednesday 22 October 2014 08:39 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/
All the validatio
On 22/10/2014 10:40 PM, Claes Redestad wrote:
Thanks! Updated:
http://cr.openjdk.java.net/~redestad/8060130/webrev.07/
On a related note,
java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java is
failing when I run make TEST=jdk_lang test from jdk9-dev, and it seems
to be due to the t
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
//Staffan
On 10/22/2014 05:37 PM, Stanimir Simeonoff wrote:
Hi Staffan,
The readonly buffer (ByteBuffer.asR
Am Wed, 22 Oct 2014 14:56:59 -0700
schrieb Mandy Chung :
> I guess your question is related to my comment about two class loaders
> can define classes in a package of the same name (two different
> runtime packages). ClassLoader.getPackage(s) assumes there is only
> one Package for each name in th
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.
jtreg has been enhanced to provide "java.security.policy" option to
specify using the specified policy file in the same way as
-Djava
On 10/22/2014 4:58 PM, Claes Redestad wrote:
A minor nit: Package.java line 636: it can return EMPTY_MANIFEST
that will set manifest to non-null so that an invalid file would
avoid opening the file every time getManifest is called (although
this case rarely happens). line 639 can then b
Hi Staffan,
The readonly buffer (ByteBuffer.asReadOnlyBuffer()) don't have array()
"working".
You can use "int length = Math.min(buffer.remaining, b.length)" instead,
same with new byte[Math.min(4096, buffer.remaining)]. Using smaller chunks
will be more performance friendly than allocating/eatin
Just realized that in the Checksum default case we will actually end up
there for Direct buffers.
//Staffan
On 10/22/2014 05:06 PM, Staffan Friberg wrote:
Hi,
I was thinking about this earlier when I started writing the patch and
then I forgot about it again. I haven't been able to figure ou
Hi,
I was thinking about this earlier when I started writing the patch and
then I forgot about it again. I haven't been able to figure out when the
code will be executed. ByteBuffer is implemented in such a way that
only the JDK can extend it and as far as I can tell you can only create
3 ty
On 2014-10-22 23:35, Mandy Chung wrote:
On 10/21/2014 6:43 AM, Claes Redestad wrote:
http://cr.openjdk.java.net/~redestad/8060130/webrev.07/
Looks good.
Thanks!
A minor nit: Package.java line 636: it can return EMPTY_MANIFEST
that will set manifest to non-null so that an invalid fil
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, so
it should not affect the common case.
Alternati
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 you have a class with ~64k methods with a superclass that also has ~64k
me
Hi Peter,
On 10/21/2014 3:37 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.03/
I skimmed through this webrev. I would suggest to hold off this patch
and there are various ideas of the optimization for class loading
performance with modules.
On Thu, Oct 23, 2014 at 12:10 AM, Bernd Eckenfels
wrote:
> Hello,
>
> just a question in the default impl:
>
> +} else {
> +byte[] b = new byte[rem];
> +buffer.get(b);
> +update(b, 0, b.length);
> +}
>
> would it be a good idea to actually put a
On 10/21/2014 2:08 PM, Bernd Eckenfels wrote:
Hello,
one thing I wonder - in the old and in the new case there is nothing
in definePackage() guaring the parents from getting to know the new
package and causing a conflict (as the atomic insert is only on the
specific packages table. Are those (p
On 10/21/2014 6:43 AM, Claes Redestad wrote:
http://cr.openjdk.java.net/~redestad/8060130/webrev.07/
Looks good.
A minor nit: Package.java line 636: it can return EMPTY_MANIFEST that
will set manifest to non-null so that an invalid file would avoid
opening the file every time getManifest
Hello,
just a question in the default impl:
+} else {
+byte[] b = new byte[rem];
+buffer.get(b);
+update(b, 0, b.length);
+}
would it be a good idea to actually put a ceiling on the size of the
array which is processed at once? Something below
You're right, managed to convince myself here as well. Will change it to <=.
An unfortunate side-effect seems to be that in a benchmark with 1024
long array it seems like the performance drops when the tail loop is not
utilized.
As you can see below there is a slight drop when the data is perfe
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/
All the validations performed are documented in the JBS issue.
Thanks
Kumar
Thanks! Updated:
http://cr.openjdk.java.net/~redestad/8060130/webrev.07/
On a related note,
java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java is
failing when I run make TEST=jdk_lang test from jdk9-dev, and it seems
to be due to the test expecting java.home to be set to a JRE d
20 matches
Mail list logo
