RFC: architecture define probably masks variable names in header files

[iris clark]

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.