I wonder if these numbers have some variation per platform? For me (on
Windows; 32-bit JDKs), the results of this test (java -verbose:class |
grep Loaded | wc -l) are:
1.5.0_22: 239
1.6.0_21: 274
1.7.0-ea-b103: 403
The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to be a
heavy regres
2994 / 3108 3170 / 3258
>>>> organ pipes: 7073 / 7296 6939 / 7090
>>>> stagger(2): 7765 / 8069 7531 / 7731
>>>> period(1,2): 653 / 743 719 / 753
>>>> random(1..4): 2152 / 2234 1567 / 1591
>
Hi Vladimir,
2010/6/19 Vladimir Iaroslavski
> Hello Osvaldo,
>
> I've prepared simple test which scans an array and does assignments for
> each element,
> see attached Test class:
>
> a[k] = a[less];
> a[less++] = 0; // or a[less] = 0; less++;
>
> The result of running "java -client Test" is:
>
2010/5/3 Martin Buchholz
> It's a coding style made popular by Doug Lea.
> It's an extreme optimization that probably isn't necessary;
> you can expect the JIT to make the same optimizations.
>
It certainly is necessary - unfortunately. Testing my particle/octree-based
3D renderer without this m
2010/4/17 assembling signals
> Hello, everyone!
>
> In the Collections utility class we have
>
> * emptyMap()
> * emptySet()
>
> * unmodifiableSet(...)
> * unmodifiableMap(...)
> * unmodifiableSortedSet(...)
> * unmodifiableSortedMap(...)
>
> So we have no
>
> * emptySortedMap()
> * emptySortedSe
This could
> be reused in any/all collections.
>
>
> On Mon, Mar 29, 2010 at 10:08 AM, Osvaldo Doederlein wrote:
>
>> Initially, it would be good enough to replace only java.util.ArrayList
>> with minimal overhead. ArrayList does not support efficient add-at-front or
&
Initially, it would be good enough to replace only java.util.ArrayList with
minimal overhead. ArrayList does not support efficient add-at-front or other
enhancements of ArrayDeque; but ArrayList is still a much more important and
popular collection, it's the primary "straight replacement for primit
Hi,
I've tread the google-groups thread, it seems you didn't test on a 64-bit
VM. Could you do that test, with and without CompressedOops, and using
latest HotSpot (7b85 or 6u20ea)? I guess we should see advantages in both
memory savings and speed, at least with CompressedOops.
It is too easy to
Should we really consider this a VM bug? I'm not sure that it's a good idea
to allocate a single object which size exceeds 4Gb (for a byte[] - due to
the object header and array size field) - even on a 64-bit VM. An array with
2^32 elements is impossible, the maximum allowed by the size field is 2^
It's sad to see this issue of serialization vs. final resurface so many
times. I have complained about this myself a number of times. The 'final'
modifier is counter-intuitive as it doesn't really prohibit modification
(most developers don't know that even a 'private static final' field can be
upda
Hi,
I just suffered the following deadlock, stress-testing my app in a JavaEE
application server:
Thread 1:
at java.util.Collections$SynchronizedSet.hashCode(Collections.java:1658)
- waiting to lock <0xfd7fdd8ce548> (a
java.util.Collections$SynchronizedSet)
Thread 2:
at
java.util.
ibrary team doesn't need to poke the compiler guys to
add extra intrinsic compilation for every method that may benefit from
optimizations which are only safe for confined objects.
A+
Osvaldo
2009/11/22 Jesús Viñuales
> Osvaldo Doederlein wrote:
> >
> > Em 22/11/2009 05:55,
Hi Goktug,
Looks like good stuff. And it remembers me from another old issue: patterns
of code that demand data copying that could often be avoided. Every
StringBuffer/StringBuilder is ultimately consumed by a toString() invocation
to produce the result String, and in 99% of all uses, only one suc
Hi,
Some suggestions:
1) Any equals*(a, b) methods should support a==null && b==null returning
true, only a==null returning -1, and only b==null returning +1. This is very
useful for much the same reasons that it's useful in SQL (although the exact
ordering of null/non-null is debatable - SQL def
Windows 7 seems to be better, check my last comente here:
http://javafx-jira.kenai.com/browse/JFXC-3357
A+
Osvaldo
2009/9/14 Jeroen Frijters
> Andrew Haley wrote:
> > Please, someone tell me Windows isn't still using the old 18.2 Hz DOS
> > timer for its system clock. No
>
> Not that i
15 matches
Mail list logo
