Bug 4390

Summary:	CorefileByteBuffer needs to use a lighter weight file access method than RandomAccessFile
Product:	frysk	Reporter:	Phil Muldoon <pmuldoon>
Component:	general	Assignee:	Phil Muldoon <pmuldoon>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:
Bug Depends on:
Bug Blocks:	4378

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 ;)