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
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
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
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:
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,
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
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
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
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 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
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
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
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
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
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
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;
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
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
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
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
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
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
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:
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,
24 matches
Mail list logo
