Remaining Specification topics

[Steve Poole <sp...@googlemail.com>]

hi all,

Now we have a first specification draft I've been thinking about the
remaining design activities that need to be closed before we can call the
JSR complete.  Here's my list.  I'll send out a specific email for each one
to keep the threads separate.


1 -  Round tripping entity identity.   Its desirable to be able to get a
handle to an entity within a dump and then come back later and ask for the
entity by handle.

2 - Standardising access to internals.   The Java runtime API is
inconsistent in offering support for accessing the internal data of an
entity.

3 - Optionality - how do we  define a mechanism that allows a dump to
explain what it contains.

 4 - "Snapshot" support - We need to determine what the direction is for
supporting smaller, faster and content configurable dumps.

Cheers

Steve

Re: Remaining Specification topics

[Steve Poole <sp...@googlemail.com>]

On Thu, Sep 10, 2009 at 3:21 PM, Adam Pilkington <
pilkington.adam@googlemail.com> wrote:

> Hi, I think that there is an additional topic which needs to be added
> to the list of outstanding items. Although it is not strictly a design
> activity, more a strategy, design decisions will need to be made in
> order to adhere to it (if we accept that it should be addressed). What
> I propose is that implementations of this JSR are required to adopt a
> 'best can do' approach to returning data to the user. What I mean by
> this is that it is not acceptable to be unable to provide information
> through the API in the event that a non fatal error occurs when the
> underlying data in the core file is being processed. Core files are
> often produced in less than ideal circumstances and data integrity
> problems should be expected and be treated as 'business as usual'. A
> simple example could be iterating over the stack frames and finding a
> corrupt one - an implementation would be expected to return the stack
> information up to the point of the corruption followed by an object
> which implements a CorruptData interface, rather than to just throw a
> CorruptDataException.
>
> One implication of adopting this 'best can do' approach is that when
> an error occurs you may be able to silently deal with it and complete
> the operation, however in terms of problem determination you may have
> lost information which could be important in debugging. This
> information may be important to the tool which is consuming the API,
> but of less importance to the user viewing the information through the
> tool. Take for example executing a JavaObject.arraycopy(). It may well
> be that as you are traversing the array you come across an invalid
> memory address for one of the elements in the array, so rather than
> fail the entire copy operation you insert a CorruptData object into
> the target array and carry on. The API consumer can detect that one of
> the array objects is corrupt, but you have potentially lost vital
> information. What I would suggest is that an internal error/message
> queue is created onto which more detailed, perhaps also more low
> level, information is placed and linked to the returned item via the
> objects ID (by ID I mean the value that is returned by calling getID()
> on the object). This would allow you to link the error information to
> the returned object. It would also allow the operation to complete and
> honour the 'best can do' approach. A similar approach is adopted by
> the Firefox browser in that it will always attempt to render what it
> can to the user, but if you open the error console in a separate
> window, you can see all the errors or warnings that were encountered
> and what action was taken.
>
> The final part of this is that the API would need to be expanded to
> allow this error information to be exposed to API consumers (but not
> necessarily the end users)
>
> Does this sound like something that is worth taking forwards ?
>
> I sort of think this is part of a discussion we had on this list for what I
coined "no nulls"  - ie you always get something back when you ask.
I had wondered how to deal with the two opposite requirements :
       one when you want to know about corrupt objects (perhaps because
that's what your looking for),
       the other when you don't want to know about corrupt /  incomplete
objects

You've explained what Firefox does and I can see your thinking.   I think
its a good idea.   Would this mean that the concept of the Corrupt exception
or corrupt data goes away?
Would we have an API where , as you put it,  its always best can do?  and
you always get an object - even if its synthetic?



> 2009/9/8 Steve Poole <sp...@googlemail.com>:
> > hi all,
> >
> > Now we have a first specification draft I've been thinking about the
> > remaining design activities that need to be closed before we can call the
> > JSR complete.  Here's my list.  I'll send out a specific email for each
> one
> > to keep the threads separate.
> >
> >
> > 1 -  Round tripping entity identity.   Its desirable to be able to get a
> > handle to an entity within a dump and then come back later and ask for
> the
> > entity by handle.
> >
> > 2 - Standardising access to internals.   The Java runtime API is
> > inconsistent in offering support for accessing the internal data of an
> > entity.
> >
> > 3 - Optionality - how do we  define a mechanism that allows a dump to
> > explain what it contains.
> >
> >  4 - "Snapshot" support - We need to determine what the direction is for
> > supporting smaller, faster and content configurable dumps.
> >
> > Cheers
> >
> > Steve
> >
>
>
>
> --
> Regards
>
> Adam Pilkington
>

Re: Remaining Specification topics

[Adam Pilkington <pi...@googlemail.com>]

Hi, I think that there is an additional topic which needs to be added
to the list of outstanding items. Although it is not strictly a design
activity, more a strategy, design decisions will need to be made in
order to adhere to it (if we accept that it should be addressed). What
I propose is that implementations of this JSR are required to adopt a
'best can do' approach to returning data to the user. What I mean by
this is that it is not acceptable to be unable to provide information
through the API in the event that a non fatal error occurs when the
underlying data in the core file is being processed. Core files are
often produced in less than ideal circumstances and data integrity
problems should be expected and be treated as 'business as usual'. A
simple example could be iterating over the stack frames and finding a
corrupt one - an implementation would be expected to return the stack
information up to the point of the corruption followed by an object
which implements a CorruptData interface, rather than to just throw a
CorruptDataException.

One implication of adopting this 'best can do' approach is that when
an error occurs you may be able to silently deal with it and complete
the operation, however in terms of problem determination you may have
lost information which could be important in debugging. This
information may be important to the tool which is consuming the API,
but of less importance to the user viewing the information through the
tool. Take for example executing a JavaObject.arraycopy(). It may well
be that as you are traversing the array you come across an invalid
memory address for one of the elements in the array, so rather than
fail the entire copy operation you insert a CorruptData object into
the target array and carry on. The API consumer can detect that one of
the array objects is corrupt, but you have potentially lost vital
information. What I would suggest is that an internal error/message
queue is created onto which more detailed, perhaps also more low
level, information is placed and linked to the returned item via the
objects ID (by ID I mean the value that is returned by calling getID()
on the object). This would allow you to link the error information to
the returned object. It would also allow the operation to complete and
honour the 'best can do' approach. A similar approach is adopted by
the Firefox browser in that it will always attempt to render what it
can to the user, but if you open the error console in a separate
window, you can see all the errors or warnings that were encountered
and what action was taken.

The final part of this is that the API would need to be expanded to
allow this error information to be exposed to API consumers (but not
necessarily the end users)

Does this sound like something that is worth taking forwards ?

2009/9/8 Steve Poole <sp...@googlemail.com>:
> hi all,
>
> Now we have a first specification draft I've been thinking about the
> remaining design activities that need to be closed before we can call the
> JSR complete.  Here's my list.  I'll send out a specific email for each one
> to keep the threads separate.
>
>
> 1 -  Round tripping entity identity.   Its desirable to be able to get a
> handle to an entity within a dump and then come back later and ask for the
> entity by handle.
>
> 2 - Standardising access to internals.   The Java runtime API is
> inconsistent in offering support for accessing the internal data of an
> entity.
>
> 3 - Optionality - how do we  define a mechanism that allows a dump to
> explain what it contains.
>
>  4 - "Snapshot" support - We need to determine what the direction is for
> supporting smaller, faster and content configurable dumps.
>
> Cheers
>
> Steve
>



-- 
Regards

Adam Pilkington