Trouble finding the definition for class BarrierSet
John Paul Adrian Glaubitz
glaubitz at physik.fu-berlin.de
Mon Jun 4 20:24:33 UTC 2018
On 06/04/2018 10:18 PM, Erik Österlund wrote:
>> On 06/04/2018 09:47 PM, Erik Österlund wrote:
>>> Can't you just #include "gc/shared/barrierSet.hpp" in library_call.cpp?
>> Hmm. Let me try. But why would it be necessary on linux-sparc and not
>> anywhere else?
> Not sure. But regardless of the case, that include should be in there anyway.
That fixes it. However, I then get:
/srv/openjdk/jdk/src/hotspot/share/opto/macroArrayCopy.cpp: In member function ‘Node* PhaseMacroExpand::generate_arraycopy(ArrayCopyNode*, AllocateArrayNode*,
Node**, MergeMemNode*, Node**, const TypePtr*, BasicType, Node*, Node*, Node*, Node*, Node*, bool, bool, RegionNode*)’:
/srv/openjdk/jdk/src/hotspot/share/opto/macroArrayCopy.cpp:553:36: error: incomplete type ‘BarrierSet’ used in nested name specifier
BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2();
I really wonder where the other architectures are getting it from.
There must be one feature/header etc that the other architectures are
including but that's being used on linux-sparc. But I cannot figure out what
>>> It is forward declared in oop.hpp, c1_LIRAssembler.hpp and collectedHeap.hpp. Perhaps
>>> you got one of those accidentally.
>> You mean, I'm somehow pulling either of those headers in in library_call.cpp?
> That sounds like the most natural explanation to me.
But why would these forward declarations hurt?
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
More information about the hotspot-dev