Overall, this kind of change seems barely worth doing.
---
This change:
// Let gc do its work
-for (int i = 0; i < size; i++)
-elementData[i] = null;
+Arrays.fill(elementData, null);
changes the performance of clear from O(size) to O(capacity), which is bad,
Hello all;
Last night while pushing another changeset I accidentally pushed a changeset
for JKD-7143928. Since the review and testing was not complete on this issue I
have backed out that changeset and created a new bug number to continue
development. The new webrev to complete the review is:
On 2/04/2013 2:08 PM, Mike Duigou wrote:
The changeset is now available as a webrev at:
http://cr.openjdk.java.net/~mduigou/JDK-8011199/0/webrev/
Thanks Mike - looks like a clean reversal. Reviewed.
David
-
Thanks,
Mike
On Apr 1 2013, at 21:02 , David Holmes wrote:
Hi Mike,
I need
Changeset: 760074bec012
Author:mduigou
Date: 2013-04-01 21:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/760074bec012
8011178: improve common/bin/hgforest.sh python detection (MacOS)
Reviewed-by: ohair
! common/bin/hgforest.sh
Sounds like a reasonable plan to me; approved to go back.
-Joe
On 04/01/2013 09:08 PM, Mike Duigou wrote:
The changeset is now available as a webrev at:
http://cr.openjdk.java.net/~mduigou/JDK-8011199/0/webrev/
Thanks,
Mike
On Apr 1 2013, at 21:02 , David Holmes wrote:
Hi Mike,
I need to
The changeset is now available as a webrev at:
http://cr.openjdk.java.net/~mduigou/JDK-8011199/0/webrev/
Thanks,
Mike
On Apr 1 2013, at 21:02 , David Holmes wrote:
> Hi Mike,
>
> I need to see the actual proposed changeset to Review it.
>
> Thanks,
> David
>
> On 2/04/2013 1:43 PM, Mike Dui
Hi Mike,
I need to see the actual proposed changeset to Review it.
Thanks,
David
On 2/04/2013 1:43 PM, Mike Duigou wrote:
Hello all;
Unfortunately while pushing another changeset I accidentally pushed JDK-7143928
as well. Since the review is not complete (and sufficient testing has not been
Hello all;
Unfortunately while pushing another changeset I accidentally pushed JDK-7143928
as well. Since the review is not complete (and sufficient testing has not been
completed) this change needs to be backed out.
I have created an "hg backout -r 0cccdb9a9a4c" changeset of
http://hg.openjdk
Changeset: 0cccdb9a9a4c
Author:mduigou
Date: 2013-04-01 20:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cccdb9a9a4c
7143928: Optimize empty HashMap and ArrayList
Reviewed-by: mduigou
Contributed-by: Sergey Linetskiy , John Rose
, Mike Duigou
! src/share/classes/java/
Hello all;
I have posted an updated version of the empty ArrayList and HashMap patch.
http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/
This revised implementation introduces *no new fields* to either class. For
ArrayList the lazy allocation of the backing array occurs only if the list
On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote:
> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of
> Caller-Sensitive Methods [1]. Christian has posted the webrev for the
> hotspot VM change a couple weeks ago [2].
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/w
On 4/1/13 12:28 PM, Alan Bateman wrote:
On 27/03/2013 17:35, Mandy Chung wrote:
This is the JDK change for JEP 176: JEP 176: Mechanical Checking of
Caller-Sensitive Methods [1]. Christian has posted the webrev for
the hotspot VM change a couple weeks ago [2].
Webrev at:
http://cr.openjdk.jav
Hi All,
In this fix, I have updated files in JDK libraries to use @Native
annotation instead of @GenerateNativeHeader to mark classes that
contain no native methods but constants used by native codes.
@GenerateNativeHeader was added earlier in the development for
JDK8."This has proved probl
Hello all;
Another changeset for review in the series "JDK-8009683 Running regression
tests with make". Many of the targets in jdk/test/Makefile are currently unused
or were never used. These targets will be removed:
perftest
packtest
vmsqe_*
jck*
I have checked with Kelky O'Hair and Kumar S
On 27/03/2013 17:35, Mandy Chung wrote:
This is the JDK change for JEP 176: JEP 176: Mechanical Checking of
Caller-Sensitive Methods [1]. Christian has posted the webrev for the
hotspot VM change a couple weeks ago [2].
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev
Changeset: fc1e08c2bb27
Author:mduigou
Date: 2013-04-01 11:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/fc1e08c2bb27
8010267: Add test-clean for cleaning of testoutput directory from output
directory. Add depedency on test-clean to clean
Reviewed-by: mchung, tbell
! common
On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourgès
wrote:
> Andrea,
>
> It could be very interesting if you could provide some concrete example
> about your map server: typical image height / width, shape complexity
> (number, size, path sizes ...).
>
It's all over the place. Image size: from 256x2
On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès
wrote:
> - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory
> waste)
>
I see, yes. Indeed in the GeoServer code we already work around some of
those issues by
clipping the geometries read from the database to the graphics2d v
Jesper,
It looks good and works for me on Linux_64.
Some comments for others:
before running IDE specify IDE_JAVAPATH env variable if want to navigate
into some java/include files (value is the same as previously was known
as ALT_BOOTDIR):
#export IDE_JAVAPATH=/opt/jdk/latest7
after opening p
Other thoughts - using chained buckets of edges instead of one single long list. It
would be easier to keep a pool of buckets (each holding, say, 256 edges?) than a
"one-size-fits-all" pool of arrays. Then all you have to do is keep high water
marks on the number of simultaneously used bucket
Jesper,
Minor comment: it's better to have env variable named IDE_ALT_BOOTDIR instead of
IDE_JAVAPATH to give analogy with the old well known meaning.
Vladimir.
On 03/30/13 03:03 PM, Vladimir Voskresensky wrote:
Jesper,
It looks good and works for me on Linux_64.
Some comments for others:
On 28/03/2013 15:59, Paul Sandoz wrote:
Hi,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010096
Webrev:
http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/
Spec diff:
http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/specdiff/overview-summary.html
We've upgraded to 7u21 and now we're seeing the same initialization problem as
reported in bug JDK-8002283, except this time with WeakHashMap instead of
HashMap. The same workaround of explicitly initializing WeakHashMap in
System.initializeSystemClass has gotten us around the issue.
Here's th
Changeset: 41a212ea8c0c
Author:sundar
Date: 2013-03-28 20:48 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/41a212ea8c0c
8010924: Dealing with undefined property gets you a fatal stack
Reviewed-by: lagergren, jlaskey
! src/jdk/nashorn/internal/runtime/resources/mozilla_c
24 matches
Mail list logo
