[mkgmap-dev] [PATCH v1] make DP filter avoidremovingpointslocated at nodes

Mon Nov 23 15:07:44 GMT 2009

Hi Mark,

As far as I'm aware that's an implementation detail only, not mandated by 
the spec, so you're right I don't think it's something you can rely on. Having 
said that, it never used to be an issue when the minimum size allocated to 
each primitive was 4 bytes! I guess this change must have come in with Java 
6. I'm surprised that boolean is only using one byte given that non-aligned 
access is more expensive than aligned, but I guess the VM implementors have 
found a way of dealing with that. Also note that Java bytecode only has 4 
and 8 byte types, so it really is the VM that's doing all the clever stuff 
here, not the compiler.

In response to an earlier comment of yours:

"If the Java implementers are smart they would be stored as single bits rather 
than bytes/shorts/words. Perhaps someone who knows about this could comment"

I don't pretend to know all that much about what it would take to implement 
this properly, but my understanding is that this isn't really feasible because 
operations on the bits would need to be performed atomically to prevent race 
conditions against the other booleans, and that becomes very expensive.

It's quite interesting how the extra level of abstraction the VM provides 
makes these sort of optimisations a moving target.

Chris

MB> Here's something else I guess you shouldn't depend on:
MB> 
MB> further experimentation shows that the order of the class member
MB> declarations doesn't make any difference to the object size. So you
MB> can
MB> intersperse the bools with the ints and the object size doesn't
MB> change.
MB> The Java compiler must order the fields to minimise the space
MB> required.
MB> That's fine because (not being C) you can't address the object's
MB> fields by pointer so the ordering is not visible to the programmer.
MB> Cheers,
MB> 
MB> Mark