???
Regardless of which, "Onodera" also sounds feminine.
grr... the name is not latin-based, not everything that ends in 'a' is
female.
not like it is some guy with a name like "Chibichibi Hitomi" or
something, which would be a bit suspect.
"anata wa des-ka?"
"chibi-chibi hitomi wa deeesuuu!" (meanwhile doing an imbalanced stance).
as other people look with a solidly "WTF?" expression upon hearing this.
another person stands up, puts his hands to his face, and a background
voice exclaims "shaaku!" (IOW: "shock!").
That would work, if that's what the second word in the object header
normally is. Assuming it's the heap address at time of creation, and
objects are aligned on word boundaries, the two least order bits of the
identity hash are going to be zero, so you can use those bits for
something else and mask them off to get the hash.
On the other hand, that suggests a way to make object headers of only
*one* word.
Consider: how likely are we to have four billion vtables in a running
32-bit JVM? Let alone Long.MAX_VALUE - Long.MIN_VALUE + 1 in a 64-bit one?
well, that is the cost of full pointers probably.
everything is addressable.
storing type-IDs as an id-number can also work, then one fetches the
vtable/... via an array index. a downside though is that this would have
a potential performance impact, as additional operations are now needed
to access the vtable.
or, one can reserve a chunk of memory (wherever it is) and subtract out
the address. then one can re-add the relative address to the base address.
say, a 64-bit base address known to the VM, and only a 32-bit relative
address is stored in the object (possibly shifted right 3 bits with the
top-3 used for the lock).
in x86-64, this can be done mostly with a single instruction, say:
lea rcx, [rbx+rax*8]
or, say, one calls a method (rdx=object, rbx=magic base pointer):
mov eax, [rdx] ;fetch vtable word from object
mov ecx, [rbx+rax*8+72] ;access vtable entry at offset 72
lea r8, [rbx+rcx] ;add method address to base
call r8 ;call method
Reserve a low chunk of the address space (and call it part of permgen?)
for vtables and your vtable pointers get quite short. The vtable pointer
plus a few bits of the object's initial address would still make a
pretty decent identity hash for collections with heterogeneous keys;
homogeneous keys, in my experience, are usually value objects with
overridden hashCode such as Strings and you can make the
initial-address-bits (and the thin lock bit) the low order bits. Shift
right one bit to lose the lock bit and have the hash; shift right n bits
for some fairly small n to get the vtable pointer. Vtable lookup is a
tiny bit slower due to a test of the lock bit plus one added shift
instruction on each lookup, but the critical performance points tend to
get JITted into direct calls or branch-predictable is-it-a-Foo?
jump-or-normal-vtable-lookup choices. And the vast majority of
production Java code is I/O bound anyway.
Well, except when the object needs a fat lock. Then the whole word
becomes a pointer to a structure that points to the vtable and contains
the lock and identity hash. Now vtable lookup has an added indirection.
But the bottleneck with such objects will usually be contention for the
lock itself, not CPU cycles.
Map lookups are O(1) and a low level implementation in C built into the
JVM would boil down to masking and shifting the hash and then a pointer
addition and dereference, only needed when you wanted to lock or unlock
an object -- and again, the time spent on this will be dwarfed by the
time spent in contention for the lock anyway, fairly often. Branch
prediction and pipelining might help in the case of high-CPU areas that
lock an object with low contention, in that some of the work might
proceed in parallel with lock acquisition in the absence of contention
(though, only as far as work that can be done in cache or registers,
since the lock must be held prior to any memory reads or writes in the
guarded object, and on initial acquisition failure that work may have to
be repeated later on acquisitoon).
yep.
a table need not be all that expensive.
in my VM at least, interface method dispatch is itself done via the use
of a hash table (as well as using a table for any object locking).
actually, a variant of the relative-address scheme is used as well on
x86-64, but in this case more due to the x86-64 ISA generally using
32-bit offsets for everything (calls/jumps/... are limited to 32-bits
unless one wants to use GPRs to hold the temporary addresses, meaning it
is much more efficient to try to have most of ones' JITted code/data be
within a +-2GB window).
in this case, calls outside of this window are generally handled via
trampolines within the window.
in effect, this window forms an "executable heap". granted, currently
the whole region is read/write/execute, where I guess on some systems
SELinux may make a problem for this, but I have yet to address this
(seems to work fine on my systems... mostly tested with Fedora x86-64).
(note: I also target Win64 and Win32 as well, with Win64 being done in
roughly the same way, and all this being N/A to Win32).
sadly, the region currently uses manual-MM. the GC can scan the region
for references, but code/data/bss sections are not automatically
reclaimed, as I found out after initial implementation that this would
create serious implementation problems, and so instead opted with using
different executable memory for GCed code, as well as it having to
follow special rules, ...
current setup:
4GB RWX (combined code/data/bss, allocation starts from the middle and
follows an even/odd "spiral" pattern).
theoretically, one would have to double-map the code-heap in this case, say:
2GB RX (code/rodata), 2GB RW (data/bss), 2GB RW (alias for code-heap)
or:
2GB RX (code/rodata), 2GB RW (data/bss, alias to first region)
presumably, the standard JVM does something similar internally?...
in the hypothetical object situation, this region would also be used for
object vtables/... as well (but, as given before, would additionally
require a region-base pointer, that or use relative addresses, which
have their own complexities, and require "movsx rax, dword [...]"
instructions).
or such...
