Bug 4390 - CorefileByteBuffer needs to use a lighter weight file access method than RandomAccessFile
Summary: CorefileByteBuffer needs to use a lighter weight file access method than Rand...
Status: RESOLVED FIXED
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Phil Muldoon
URL:
Keywords:
Depends on:
Blocks: 4378
  Show dependency tree / graph
 
Reported: 2007-04-18 01:57 UTC by Phil Muldoon
Modified: 2008-01-09 13:49 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Muldoon 2007-04-18 01:57:46 UTC 
A read from a corefile should be open->read->close. Doing this with
RandomAccessFile would cause many dozens of java objects queued for GC on a lot
of peek() operations. Right now, because of that, CorefileBytebuffer maintains
the RandomAccessFile open for the life of the buffer, consuming one FD for a
long time.

A very light weight object that keeps the file closed, opens it on read, then
closes it again is required, so that fd's and other systems resources can be
cycled back into the pool
Comment 1 Phil Muldoon 2008-01-09 13:43:51 UTC 
Appears that the comment above fixed the issue, and this bug was left open
Comment 2 Phil Muldoon 2008-01-09 13:47:01 UTC 
Reopening to add actual commit changelog
Comment 3 Phil Muldoon 2008-01-09 13:47:31 UTC 
2007-05-22  Phil Muldoon  <pmuldoon@redhat.com>

	* CorefileByteBuffer.java (finalize): Remove.
	(isFileOpen): Remove.
	(peek): Rewrite to use StatelessFile.
	(isFileSane): Test for object creation.
	(openFile): Rewrite. Use StatlessFile.
	(CorefileByteBuffer): Switch order of file open
	and elf address offset table creation.
	* TestCorefileByteBuffer (testCoreFileByteBufferMapOverrun): Move
	overrun location.
Comment 4 Phil Muldoon 2008-01-09 13:47:54 UTC 
Changing Assigned to pmuldoon
Comment 5 Phil Muldoon 2008-01-09 13:49:20 UTC 
Closing (finally ;)