On 9/7/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 9/7/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> Hi Mikhail,
> Sorry I left this thread for a while. Are you implementing VMMagic
> support in .OPT currently, and prototyping with bump allocation? I am
> just
> trying to understand in what order we are doing this.
I'm implementing VMMagics and going to use it to prototype bump pointer
allocation. I hope I will finish VMMagic OPT package in a several weeks.
Would it be possible to list the fastpath helpers so that the java
> interfaces to access them could be defined? All of them don't need magic
> classes support and one of us could just write them. I don't know the
list
> of intrinsics implemented already in .JET. Can we just use them as is,
and
> what else ( other than TLS access, call support ) would need to be
added?
The list of the helpers with fast path to be written in Java:
1) object allocation
2) array allocation
3) monitor enters
4) monitor exits
5) I hope we can move some profiling helpers to Java and to remove the
knowledge about their implementation from JIT.
6) write and read barriers
7) back branch polling helper
8) ? Some TI helpers ?
VM gurus, have you anything to add to this list?
This is a good list to start with. I would focus on the first four for
now. This is because for the most part the interface from the common, fast
code to the slow not-so-common code is real simple and well understood. The
idea is to start with the simplest thing possible that exercises all the
vmmagic functions you want to add (call, thread-local access).
Write barriers fall into a different category. It depends on the write
barrier algorithm that happens to be implemented by the GC. And what the GC
happens to be written in. In other words, the integration we recently did
for MMTk probably does not apply to what Xiao Feng will be doing in GCV5.
Also on closer look, there are allocation algorithms that are not as simple
and clean as "bump the pointer". For example a non-moving collector might
search size segregated lists to allocate an object. The point is that it
would be good if the JIT keeps the existing helper interface in addition to
the work you are proposing.
+ I think that TLS and call support are enough.
BTW, there may be a small omission in the example below..if I am reading
> this right...
IMO "newCurrent = oldCurrent + size" is OK. May be the source of the
problem
is the variable name, i.e. 'ceiling' is always >= 'current' in my example.
Thanks,
> Rana
>
> On 8/28/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>
> > Folks,
> > Here is the example of fast allocation helper written in Java with the
> > help
> > of VMMagic
> > If nobody objects I'm starting to implement VMMagic support in
> > Jitrino.OPTthis week.
> >
> >
> >
> > private static final int GC_TLS_OFFSET = 10;
> > private static final int GC_CURRENT_OFFSET= GC_TLS_OFFSET + 0;
> > private static final int GC_CEILING_OFFSET= GC_TLS_OFFSET + 4;
> > private static final int OBJ_VTABLE_OFFSET = 0;
> >
> > //annotate with calling convention and real VM helper id/name
> information
> > private static Address slowAlloc(int vtable, int size) {throw new
> > Error("must never be called!");}
> >
> > private static Address fastAlloc(int vtable, int size) {
> > Address tlsBase = TLS.getAddress(); //load thread local client
area
> > address
> >
> > Address currentFieldAddress = tlsBase.plus(GC_CURRENT_OFFSET);
> > Address ceilingFieldAddress = tlsBase.plus(GC_CEILING_OFFSET);
> >
> > Address newObjectAddress; //the result of the method
> >
> > // check if there is enough size to do allocation in thread local
> > buffer
> > Address current = currentFieldAddress.loadAddress();
> > Address ceiling = ceilingFieldAddress.loadAddress();
> > Address newCurrent = current.plus(size);
> > if (newCurrent.LT(ceiling)) {
>
>
> >> newCurrent = newCurrent.plus(-size);
>
> currentFieldAddress.store(newCurrent.toWord());
> > newObjectAddress = newCurrent;
> > newObjectAddress.store(vtable, Offset.fromInt
> (OBJ_VTABLE_OFFSET));
> >
> > } else {
> > newObjectAddress = slowAlloc(vtable, size);
> > }
> > return newObjectAddress;
> > }
> >
> > --
> > Mikhail Fursov
> >
> >
>
>
--
Mikhail Fursov
--
Weldon Washburn
Intel Middleware Products Division
