Re: Bulk Array Element Allocation, is it faster?
Eric Sosman schrieb:
Challenge: Look through your own code, right now, and count
the number of times you have actually filled an array with references
to N identically-constructed-with-no-args objects.
> Exhibit some actual code, so people can stop guessing about
> what you've done.
I am not asking people to guess what I have done. I
am asking about whether JIT can optimize loops with
new in it. The new in it needs not to be a argument
less constructor. It could be also a constructor
with arguments.
All the optimizations that came to my mind easily
work also with argument based constructors. For
example moving the lock outside of the loop should
also work with argument based constructors in most
cases:
for (int i=0; i<n; i++) {
lock heap
bla[i] = new Bla(i);
unlock heap
}
Is the same as:
lock heap
for (int i=0; i<n; i++) {
bla[i] = new Bla(i);
}
unlock heap
If <init> of bla does not much. And the other optimization
with the memory allocate is also not impacted much by
argument based constructors. And it can be combined with
the heap locking, and we can move the lock before
the loop, and will lock less time:
for (int i=0; i<n; i++) {
lock heap
p = allocate size X
bla[i] = init p;
unlock heap
}
Is the same as:
lock heap
p = allocate size n*X
unlock heap
for (int i=0; i<n; i++) {
bla[i] = init p;
p += x;
}
I hope you see now what I am heading for. But I must
disappoint you, if a compiler would be able to optimize
constructors with arguments, maybe not in all situations
but to a great degree, I will not have use for it in
my application, since my current problem is argument
less.
But I would be of course also happy to hear something
about the more general problem of constructors with
arguments and what the JIT would do for loops. Since
it would then be very easy for me to specialize the
insight to my argument less problem.
I do not exclude that JITs can also deal with
constructors that have arguments in loops.
Bye