September 18, 2009
Poll Result: Java Is Most Preeminent in Europe.
Some voters in this past week's java.net poll questioned whether the question could be answered, but the result showed that a plurality of voters considered Europe to be region where Java has the greatest market share among competing technologi...
More »
September 17, 2009
Sun Collaborates with Software Freedom International to Connect More than 25,000 Developers and Students in 30 Countries for Software Freedom Day 2009. Building on its commitment to empower developers and students across the globe, Sun Microsystems, Inc. (NASDAQ: JAVA) is sponsoring more than 300 community style events in more than 30 countries for Software Freedom Day (SFD) on September 19, 2009. W...
More »
November/2009
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | | 8 | 9 | 10 | 11 | 12 | 13 | 14 | | 15 | 16 | 17 | 18 | 19 | 20 |
21 | | 22 | 23 | 24 | 25 | 26 | 27 | 28 | | 29 | 30 | | | | | |
|
 |
When long is not long enough
Yesterday, a Hudson committer Alan Harder discovered an EOFException in Hudson, which only happens on 64bit JVM on Solaris. This was happening in the part of Hudson (or more precisely, in a separate library called Akuma) where we look at the memory space of the process to figure out the command line arguments of the current process (the /proc/ID/as file — an equivalent of /proc/ID/mem in Linux)
It turns out that the problem was because this sparse file is 264 bytes long on 64bit systems. So for Hudson to look at arbitrary positions in the process memory space, it needs be able to seek beyond Long.MAX_VALUE (263-1.)
Java's RandomAccessFile has the seek(long) method, but it uses long as a signed value (as it should), so this won't do it. Alan suggested that we first seek to 263-1 and then call skipBytes repeatedly till we get to where we want. This won't do it either, unfortunately, because skipBytes takes int. I'd have to call this method for close to 232 times in the worst case! (And it turns out that internally RandomAccessFile keeps the file offset in a single long field, so it just can't address anything above 263-1 anyway.)
So to do this, I had to go back to libc, namely fseek. It still uses a signed long, but with fseek, one could say "move ahead by 263-1 from the current position", so in the worst case, it takes up to 3 seeks to get to where I want, but I was finally able to fix the problem tha...
Date: September, 17 2009
Url: http://www.java.net/blog/kohsuke/archive/2009/09/17/when-long-not-long-enough
Others News
Leave a Reply
Related
- LongLongHoneymoon.com | Get hitched. On our Long Long Honeymoon, we’ve enjoyed our share of rustic camping locations. Places like Yellowstone, the Grand Canyon, and Glacier National Park come to mind.
|
