Hi, Paul.
You recall correctly. We've wanted to remove the entire HPI layer
since at least 1.3 but it's never been high enough priority,
particularly given that we expect it to be a non-trivial task. New
APIs (e.g. java.nio) were explicitly written to avoid using it, but a
number of old APIs still depend on it.
As for the "Thread" portion of HPI, here's the RFE for removing it:
4919401: (thread) Remove Thread interface from HPI
The RFE asserts that the HPI_ThreadInterface isn't used by Hotspot and
is in fact broken. This has caused us some problems, the most recent
of which is described in the following bug:
6626677: Error: Unimplemented()/HPI sysMonitorExit is broken on
linux-amd64
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6626677
I'm sure that given more time I could dig up additional bugids
describing various HPI problems and their symptoms, but the related
bugs listed for 6626677 are a good start.
Thanks,
iris
> Paul Hohensee wrote:
> Actually, I recall that one of the things we've always wanted to
> do is get rid of HPI. Never seems to be important enough.
>
> Paul
>
> Kelly O'Hair wrote:
> > If it's not used, I say OFF WITH IT"S HEAD! ;^)
> >
> > -kto
> >
> >
> > Alan Bateman wrote:
> >> Kelly O'Hair wrote:
> >>> I very much suspect that this -D$(ARCH) could be removed with no
> >>> consequences.
> >>> The difficult part would be verifying it.
> >>>
> >>> C macros are a very powerful tool, but some of the global names we
> >>> have chosen
> >>>
> >>> over the years have come back to haunt us. :^(
> >> src/solaris/hpi/native_threads is one place that seems to depend on
> >> $(ARCH) being defined. That code is part of the HPI "Thread"
> >> interface. As I recall, HotSpot doesn't use the HPI's "Thread" or
> >> "Memory" interfaces and so this code probably hasn't been used since
> >> the transition to HotSpot back in 1.3.
> >>
> >> -Alan.
