directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raffaele P. Guidi" <raffaele.p.gu...@gmail.com>
Subject Re: Additional Serializer and raw Buffer access
Date Sun, 30 Sep 2012 08:39:56 GMT
I usually work with git-svn and git at least keeps it locally
Il giorno 30/set/2012 09:37, "Noctarius" <me@noctarius.com> ha scritto:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Morning,
>
> is there any way to preserve the commit history? I don't think so.
>
> Cheers Chris
>
> Am 29.09.2012 21:05, schrieb Raffaele P. Guidi:
> > I kinda suspected that... Il giorno 29/set/2012 20:47,
> > "Noctarius" <me@noctarius.com> ha scritto:
> >
> >> Actually all dependencies should be AL2 or BSD licensed :-)
> >>
> >> Am 29.09.2012 20:42, schrieb Raffaele P. Guidi:
> >>>>> Hehe well that really sounds like a nice bunch of
> >>>>> people.
> >>>
> >>> Indeed they are (I'm a newbie as well and try to do my
> >>> best)
> >>>
> >>>>> If lightning will be a sub-part (sub-project) of DM, do
> >>>>> I need to write
> >>> an project purposal?
> >>>
> >>> Nope, not needed for a sub-project
> >>>
> >>>>> Do I need to make any changes to the pom.xml like
> >>>>> adding a
> >>> special parent pom or anything like that?
> >>>
> >>> Not for the serializer - just have to take a look at
> >>> project dependencies - or, better, at their licenses - are
> >>> they compatible with the ASL 2.0? i.e. a GPL'd library is
> >>> not a good fit and should be replaced with an apache
> >>> licensed (or BSD, or MIT...) one if possible. For the
> >>> integration module is a separate story - you should start
> >>> off copying one of the other serializers and reusing the
> >>> same pom and directory structure.
> >>>
> >>> Pleased to meet you, Chris :)
> >>>
> >>> Ciao, R
> >>>
> >>> On Sat, Sep 29, 2012 at 8:24 PM, Noctarius
> >>> <me@noctarius.com> wrote:
> >>>
> >>>> Hehe well that really sounds like a nice bunch of
> >>>> people.
> >>>>
> >>>> Ok to be true I couldn't wait until tomorrow and started
> >>>> already reading the links. From what I was reading: If
> >>>> lightning will be a sub-part (sub-project) of DM, do I
> >>>> need to write an project purposal?
> >>>>
> >>>> Do I need to make any changes to the pom.xml like adding
> >>>> a special parent pom or anything like that?
> >>>>
> >>>> In general: there are a lot things to know :-)
> >>>>
> >>>> Am 29.09.2012 19:59, schrieb Raffaele P. Guidi:
> >>>>> Negative part of ASF membership? You get together with
> >>>>> a lot of geeky, talented people with a fixation for
> >>>>> software and open source. Oh wait but this is actually
> >>>>> nice! :-D Il giorno 29/set/2012 19:05, "Olivier Lamy"
> >>>>> <olamy@apache.org> ha
> >>>> scritto:
> >>>>>
> >>>>>> 2012/9/29 Noctarius <me@noctarius.com>:
> >>>>>>> Thanks Olivier for carify, I'll take a look in it
> >>>>>>> tomorrow but there's just one question left (for
> >>>>>>> now ;)): What is that vote for becoming a
> >>>>>>> committer? What if the vote will be negative?
> >>>>>> The vote is on private list (pmc list for privacy
> >>>>>> reasons and possible negative stuff being on public
> >>>>>> lists)
> >>>>>>> Until now I just used Apache stuff, was never
> >>>>>>> interested in being part of it so I guess it can
> >>>>>>> be negative for any reason, can't it?
> >>>>>> I don't see why it could be negative but suspens
> >>>>>> .... :-)
> >>>>>>>
> >>>>>>> Am 29.09.2012 18:56, schrieb Olivier Lamy:
> >>>>>>>> 2012/9/29 Noctarius <me@noctarius.com>:
> >>>>>>>>> Nope my real name is Christoph Engelbert, but
> >>>>>>>>> Noctarius is the all time nick :)
> >>>>>>>>>
> >>>>>>>>> Renaming the package should be no problem, is
> >>>>>>>>> it "org.apache.directmemory.lightning" or what
> >>>>>>>>> would it be?
> >>>>>>>> fine for me
> >>>>>>>>> Then there needs to be a change in the license
> >>>>>>>>> header as Olivier mentioned, that means just
> >>>>>>>>> remove the first sentence or is there anything
> >>>>>>>>> more to do (maybe it's easiest thing to just
> >>>>>>>>> copy the header from DM file ;))?
> >>>>>>>> yup use same header as DM
> >>>>>>>>>
> >>>>>>>>> The CLA is just a form to clarify that the
> >>>>>>>>> source can be contributed to the Apache
> >>>>>>>>> Foundation?
> >>>>>>>> yup correct.
> >>>>>>>>>
> >>>>>>>>> The final step will be attaching the patch in
> >>>>>>>>> form of a huge diff file?
> >>>>>>>> yes
> >>>>>>>>>
> >>>>>>>>> And what is the way to apply for a membership?
> >>>>>>>>> Never thought about how to do that.
> >>>>>>>> Read here
> >>>>>>>> http://apache.org/foundation/how-it-works.html
> >>>>>>>> and here
> >>>>>>>> http://apache.org/foundation/getinvolved.html .
> >>>>>>>> And feel free to ask any questions :-)
> >>>>>>>>>
> >>>>>>>>> Chris
> >>>>>>>>>
> >>>>>>>>> Am 29.09.2012 18:23, schrieb Raffaele P.
> >>>>>>>>> Guidi:
> >>>>>>>>>> OK, deal, at least for me ;-) I propose you
> >>>>>>>>>> rename the packages, produce a patch for this
> >>>>>>>>>> and the new serializer module (should be
> >>>>>>>>>> simple enough starting from an existing one)
> >>>>>>>>>> and, in the meanwhile, apply for ASF
> >>>>>>>>>> membership. Is IP clearance needed? I guess
> >>>>>>>>>> yes. After this we will come up with a formal
> >>>>>>>>>> vote regarding Noctarius (is this your real
> >>>>>>>>>> name?!) allowance in the project team.
> >>>>>>>>>>
> >>>>>>>>>> Good times are gonna come :-)
> >>>>>>>>>>
> >>>>>>>>>> Thanks, R Il giorno 29/set/2012 17:58,
> >>>>>>>>>> "Olivier Lamy" <olamy@apache.org> ha
> >>>>>>>>>> scritto:
> >>>>>>>>>>
> >>>>>>>>>>> 2012/9/29 Raffaele P. Guidi
> >>>>>>>>>>> <raffaele.p.guidi@gmail.com>:
> >>>>>>>>>>>> Well we already have a NIO ready
> >>>>>>>>>>>> interface allowing direct access to
DMs
> >>>>>>>>>>>> managed bytebuffers but I think this
is
> >>>>>>>>>>>> just half way to what could be achieved
> >>>>>>>>>>>> optimally blending serialization and
> >>>>>>>>>>>> memory allocation together.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Lightning as a module is of course a
> >>>>>>>>>>>> good idea and it could easily evolve
as
> >>>>>>>>>>>> a subproject (for the more experienced
> >>>>>>>>>>>> asf members: is it a feasible way?).
> >>>>>>>>>>> Nothing prevent to have
> >>>>>>>>>>> http://svn.apache.org/repos/asf/directmemory/lightning/trunk
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>
> >>
> >>>>>>>>>>>
> with a package like: o.a.d.lightning That will be a
> >>>>>>>>>>> subproject.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ciao, R Il giorno 29/set/2012 17:44,
> >>>>>>>>>>>> "Noctarius" <me@noctarius.com>
ha
> >>>>>>>>>>>> scritto:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hey guys,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ok there's no lightning binary
> >>>>>>>>>>>>> available since lightning wasn't
ready
> >>>>>>>>>>>>> yet for releasing.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For being the only developer it
would
> >>>>>>>>>>>>> be no problem to contribute the
> >>>>>>>>>>>>> sourcebase for DirectMemory but
I'm not
> >>>>>>>>>>>>> sure yet if it wouldn't be better
to
> >>>>>>>>>>>>> seperate it to be available without
> >>>>>>>>>>>>> using DirectMemory itself. I started
it
> >>>>>>>>>>>>> as a serializer for cluster
> >>>>>>>>>>>>> synchronization, but it would be
cool
> >>>>>>>>>>>>> to contribute lightning as a subproject
> >>>>>>>>>>>>> to DirectMemory :-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> About the second project I would
love
> >>>>>>>>>>>>> to see a public available buffer
API
> >>>>>>>>>>>>> directly in DirectMemory so that
> >>>>>>>>>>>>> project would be nearly needless
:-)
> >>>>>>>>>>>>> The only difference I think is the
> >>>>>>>>>>>>> allocation strategy my implementation
> >>>>>>>>>>>>> is using against the one DirectMemory
> >>>>>>>>>>>>> has, but I'm pretty sure the allocation
> >>>>>>>>>>>>> is extensible ;-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Like I said, for both projects I'm
the
> >>>>>>>>>>>>> only dev so there would be no IP
> >>>>>>>>>>>>> problem. So if it's ok to you to
not
> >>>>>>>>>>>>> include lightning directly in DM
I
> >>>>>>>>>>>>> would be glad to contribute to the
> >>>>>>>>>>>>> Apache Foundation :-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Cheers Chris
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Am 29.09.2012 16:53, schrieb Raffaele
> >>>>>>>>>>>>> P. Guidi:
> >>>>>>>>>>>>>> Ok so it's up to noctarius -
your
> >>>>>>>>>>>>>> move! ;-) Regarding the new
unsafe
> >>>>>>>>>>>>>> storage: it's an opt-in feature
that
> >>>>>>>>>>>>>> can be set with the fluent API
> >>>>>>>>>>> (and
> >>>>>>>>>>>>>> soon through the conference
file).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Ciao, R Il giorno 29/set/2012
16:45,
> >>>>>>>>>>>>>> "Olivier Lamy" <olamy@apache.org>
ha
> >>>>>>>>>>>>> scritto:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2012/9/29 Raffaele P. Guidi
> >>>>>>>>>>>>>>> <raffaele.p.guidi@gmail.com>:
> >>>>>>>>>>>>>>>>>> At least for
the moment he
> >>>>>>>>>>>>>>>>>> can provide
a patch to be
> >>>>>>>>>>>>>>>>>> integrated
> >>>>>>>>>>> in DM
> >>>>>>>>>>>>>>> :-)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Sure, but as lightning
is not in
> >>>>>>>>>>>>>>>> any public mvn repo
should its
> >>>>>>>>>>> code be
> >>>>>>>>>>>>>>>> re-published in our
svn? Or
> >>>>>>>>>>>>>>>> what?
> >>>>>>>>>>>>>>> @Apache we don't care about
> >>>>>>>>>>>>>>> binaries, only sources are
> >>>>>>>>>>>>>>> important ! (a bit theorical
for
> >>>>>>>>>>>>>>> sure but that's it :-) ).
So if
> >>>>>>>>>>>>>>> Noctarius was the only guy
who
> >>>>>>>>>>>>>>> participate in lightning.
He can
> >>>>>>>>>>>>>>> just provide a patch we
could
> >>>>>>>>>>>>>>> integrate as a new dm module
(note:
> >>>>>>>>>>>>>>> the patch must not contains
any
> >>>>>>>>>>>>>>> more copyright and all sources
must
> >>>>>>>>>>>>>>> have ASF licenses).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> "Copyright 2012 the original
author
> >>>>>>>>>>>>>>> or authors." must be removed.
And
> >>>>>>>>>>>>>>> BTW package must be changed
:-)
> >>>>>>>>>>>>>>> (com.github is not acceptable
> >>>>>>>>>>> @asf
> >>>>>>>>>>>>>>> :-) )(@Noctarius are you
working
> >>>>>>>>>>>>>>> for github ? :-) )
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> And having him as a committer
will
> >>>>>>>>>>>>>>> be only a matter of voting
(we
> >>>>>>>>>>> have
> >>>>>>>>>>>>>>> a great chair who take cares
of
> >>>>>>>>>>>>>>> administrative stuff :P
)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If some others have participated
in
> >>>>>>>>>>>>>>> the project, we must pass
tru an
> >>>>>>>>>>>>>>> ip clearance mechanism
> >>>>>>>>>>>>>>> (http://incubator.apache.org/ip-clearance/index.html)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>
> and all contributors to lightning must provide a cla.
> >>>>>>>>>>>>>>> (It it's the case I can
help)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> perso I'd like
we avoid hard
> >>>>>>>>>>>>>>>>>> dependency on
Unsafe as
> >>>>>>>>>>>>>>>>>> maybe some
> >>>>>>>>>>> use
> >>>>>>>>>>>>>>>> other jdks :-)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Well, I believe Unsafe
is
> >>>>>>>>>>>>>>>> supported by Sun JDK,
OpenJDK,
> >>>>>>>>>>>>>>>> IBM JDK and JRockit
- and I
> >>>>>>>>>>>>>>>> believe that it is more
than
> >>>>>>>>>>>>>>>> enough. Also keep in
> >>>>>>>>>>> mind
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> we already have an alternative
> >>>>>>>>>>>>>>>> Unsafe based memory
storage -
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>> although
> >>>>>>>>>>>>>>>> it's not thoroughly
tested for
> >>>>>>>>>>>>>>>> performance it dramaticaly
> >>>>>>>>>>>>>>>> simplifies
> >>>>>>>>>>>>>>> code,
> >>>>>>>>>>>>>>>> I have great expectations
about
> >>>>>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>> Me too :-). Yup definitely
more
> >>>>>>>>>>>>>>> simple and faster ! But
we must
> >>>>>>>>>>>>>>> provide a switch off configuration
> >>>>>>>>>>>>>>> mechanism if some
> >>>>>>>>>>> users
> >>>>>>>>>>>>>>> don't want to use that (because
> >>>>>>>>>>>>>>> Unsafe is just "Unsafe"
:-) ) And
> >>>>>>>>>>>>>>> sorry I didn't have a look
yet at
> >>>>>>>>>>>>>>> your changes with using
Unsafe.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cheers, R
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Sat, Sep 29, 2012
at 4:03 PM,
> >>>>>>>>>>>>>>>> Olivier Lamy <olamy@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2012/9/29 Raffaele
P. Guidi
> >>>>>>>>>>>>>>>>> <raffaele.p.guidi@gmail.com>:
> >>>>>>>>>>>>>>>>>> What do you
think about: 1)
> >>>>>>>>>>>>>>>>>> implementing
a lightning
> >>>>>>>>>>>>>>>>>> serialization
module 2)
> >>>>>>>>>>>>>>>>>> creating a serializer
that
> >>>>>>>>>>>>>>>>>> directly works
on a
> >>>>>>>>>>>>>>>>>> directmemory
> >>>>>>>>>>>>>>> provider
> >>>>>>>>>>>>>>>>>> ByteBuffer or
(maybe better)
> >>>>>>>>>>>>>>>>>> Unsafe based
Pointer?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sounds good (perso
I'd like we
> >>>>>>>>>>>>>>>>> avoid hard dependency
on Unsafe
> >>>>>>>>>>>>>>>>> as maybe some use
other jdks
> >>>>>>>>>>>>>>>>> :-) )
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Now I see lightning
is
> >>>>>>>>>>>>>>>>>> apache licensed
and this is
> >>>>>>>>>>>>>>>>>> fine but I
> >>>>>>>>>>> don't
> >>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>>> it is published
in any
> >>>>>>>>>>>>>>>>>> public maven
repo, am I
> >>>>>>>>>>>>>>>>>> right? We could
> >>>>>>>>>>> find a
> >>>>>>>>>>>>>>> way
> >>>>>>>>>>>>>>>>>> to deal with
this; options
> >>>>>>>>>>>>>>>>>> vary from publishing
> >>>>>>>>>>>>>>>>>> lightning to
the
> >>>>>>>>>>> free
> >>>>>>>>>>>>>>>>>> sonatype repo,
 joining the
> >>>>>>>>>>>>>>>>>> ASF (which is
great anyhow!)
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>> republishing
> >>>>>>>>>>>>>>>>>> lightning code
in
> >>>>>>>>>>>>>>>>>> DirectMemory
becoming a
> >>>>>>>>>>>>>>>>>> commiter (which
has to
> >>>>>>>>>>>>>>> undergo
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> PMC vote).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> At least for the
moment he can
> >>>>>>>>>>>>>>>>> provide a patch
to be
> >>>>>>>>>>>>>>>>> integrated in
> >>>>>>>>>>> DM
> >>>>>>>>>>>>>>> :-)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I'd like to
hear your and
> >>>>>>>>>>>>>>>>>> the team feelings
on this.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks, Raffaele
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Sat, Sep
29, 2012 at 3:27
> >>>>>>>>>>>>>>>>>> PM, Noctarius
> >>>>>>>>>>>>>>>>>> <me@noctarius.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hey Raffaele,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> that's quite
similar to
> >>>>>>>>>>>>>>>>>>> what I did
at work. We're
> >>>>>>>>>>>>>>>>>>> developing
> >>>>>>>>>>> Flash
> >>>>>>>>>>>>>>>>>>> online games
and using a
> >>>>>>>>>>>>>>>>>>> customized
AMF
> >>>>>>>>>>>>>>>>>>> serialization.
To support
> >>>>>>>>>>>>>>>>>>> async writing
of the
> >>>>>>>>>>>>>>>>>>> clients
event results I
> >>>>>>>>>>>>>>>>>>> added serialization
> >>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> the components
/ entities
> >>>>>>>>>>>>>>>>>>> to the players
zone
> >>>>>>>>>>>>>>>>>>> calculation
and
> >>>>>>>>>>> stored
> >>>>>>>>>>>>>>>>>>> the pre-serialized
> >>>>>>>>>>>>>>>>>>> bytestream
directly to the
> >>>>>>>>>>>>>>>>>>> off-heap
(using
> >>>>>>>>>>>>>>>>>>> direct-ring-cache
> >>>>>>>>>>>>>>>>>>> implementation).
When the
> >>>>>>>>>>>>>>>>>>> client requests
the
> >>>>>>>>>>>>>>>>>>> results
(using
> >>>>>>>>>>>>>>>>>>> long-polling)
I just write
> >>>>>>>>>>>>>>>>>>> the pre-serialized
> >>>>>>>>>>> data to
> >>>>>>>>>>>>>>>>>>> the right
position to
> >>>>>>>>>>>>>>>>>>> deserialize
it by standard
> >>>>>>>>>>>>>>>>>>> ways on
Flash
> >>>>>>>>>>> side.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> So yeah
an seriliaztion to
> >>>>>>>>>>>>>>>>>>> off-heap
algorithm would
> >>>>>>>>>>>>>>>>>>> be fine.
You
> >>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>> avoid using
byte arrays
> >>>>>>>>>>>>>>>>>>> and minimalize
GC.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Cheers Chris
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Am 29.09.2012
15:02,
> >>>>>>>>>>>>>>>>>>> schrieb
Raffaele P. Guidi:
> >>>>>>>>>>>>>>>>>>>> Nice
to hear back from
> >>>>>>>>>>>>>>>>>>>> you!
Yes, I was thinking
> >>>>>>>>>>>>>>>>>>>> about
creating a
> >>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>> memory
> >>>>>>>>>>>>>>>>>>>> storage
implementation
> >>>>>>>>>>>>>>>>>>>> using
Unsafe (and I did
> >>>>>>>>>>>>>>>>>>>> it,
recently) and
> >>>>>>>>>>>>>>>>> also, as
> >>>>>>>>>>>>>>>>>>>> DirectMemory
relies
> >>>>>>>>>>>>>>>>>>>> heavily
on serialization
> >>>>>>>>>>>>>>>>>>>> (and
supports many
> >>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> them,
> >>>>>>>>>>>>>>>>>>>> protostuff,
protobuf,
> >>>>>>>>>>>>>>>>>>>> msgpack
and of course
> >>>>>>>>>>>>>>>>>>>> standard
> >>>>>>>>>>>>>>> serialization),
> >>>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>> creating
a simple
> >>>>>>>>>>>>>>>>>>>> embedded
serializer
> >>>>>>>>>>>>>>>>>>>> leveraging
the same
> >>>>>>>>>>>>>>> techniques
> >>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>> used
(Unsafe and
> >>>>>>>>>>>>>>>>>>>> bytecode
generation). The
> >>>>>>>>>>>>>>>>>>>> idea
with embedding is
> >>>>>>>>>>>>>>>>>>>> avoiding
to serialize in
> >>>>>>>>>>>>>>>>>>>> a byte
array
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>> moving
the byte array to
> >>>>>>>>>>>>>>>>>>>> off-heap
memory (via
> >>>>>>>>>>>>>>>>>>>> Unsafe
or
> >>>>>>>>>>>>>>> ByteBuffers),
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> serializing
directly into
> >>>>>>>>>>>>>>>>>>>> a "managed"
off-heap
> >>>>>>>>>>>>>>>>>>>> buffer,
thus
> >>>>>>>>>>> further
> >>>>>>>>>>>>>>>>>>>> optimizing
heap
> >>>>>>>>>>>>>>>>>>>> utilization
(less GC).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> What
do you think about
> >>>>>>>>>>>>>>>>>>>> it?
Does it make any
> >>>>>>>>>>>>>>>>>>>> sense
to you?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Ciao,
R
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Sat,
Sep 29, 2012 at
> >>>>>>>>>>>>>>>>>>>> 2:40
PM, Noctarius
> >>>>>>>>>>>>>>>>>>>> <me@noctarius.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
Hey guys,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
Raffaele found out
> >>>>>>>>>>>>>>>>>>>>>
about a project of mine
> >>>>>>>>>>>>>>>>>>>>>
(Lightning) a few
> >>>>>>>>>>> weeks
> >>>>>>>>>>>>>>>>>>>>>
ago. Lightning is a
> >>>>>>>>>>>>>>>>>>>>>
heavy Unsafe and
> >>>>>>>>>>>>>>>>>>>>>
Bytecode generation
> >>>>>>>>>>>>>>>>>>>>>
using Serializer
> >>>>>>>>>>>>>>>>>>>>>
implementation. He told
> >>>>>>>>>>>>>>>>>>>>>
me that he was
> >>>>>>>>>>>>>>>>>>>>>
interested in adding
> >>>>>>>>>>>>>>>>>>>>>
something similar to
> >>>>>>>>>>>>>>>>>>>>>
DirectMemory and I
> >>>>>>>>>>>>>>>>>>>>>
would be glad to
> >>>>>>>>>>>>>>> help
> >>>>>>>>>>>>>>>>>>>>>
out in this.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
Another project I
> >>>>>>>>>>>>>>>>>>>>>
started a few days ago,
> >>>>>>>>>>>>>>>>>>>>>
since it was needed
> >>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>
work is
> >>>>>>>>>>>>>>>>>>>>>
DirectRingCache. The
> >>>>>>>>>>>>>>>>>>>>>
name not really meets
> >>>>>>>>>>>>>>>>>>>>>
to actual
> >>>>>>>>>>>>>>>>>>>>>
implementation since
> >>>>>>>>>>>>>>>>>>>>>
it's not yet a ring
> >>>>>>>>>>>>>>>>>>>>>
buffer using cache. I
> >>>>>>>>>>>>>>> used
> >>>>>>>>>>>>>>>>>>>>>
this for a
> >>>>>>>>>>>>>>>>>>>>>
pre-serialization
> >>>>>>>>>>>>>>>>>>>>>
simple bytestream cache
> >>>>>>>>>>>>>>>>>>>>>
with self-growing
> >>>>>>>>>>>>>>>>>>>>>
buffers. It could be
> >>>>>>>>>>>>>>>>>>>>>
nice to have
> >>>>>>>>>>>>>>>>>>>>>
DirectMemory
> >>>>>>>>>>> having
> >>>>>>>>>>>>>>>>>>>>>
raw "buffers" to write
> >>>>>>>>>>>>>>>>>>>>>
to or to read from.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
Here are the links
> >>>>>>>>>>>>>>>>>>>>>
from the projects:
> >>>>>>>>>>>>>>>>>>>>>
https://github.com/noctarius/Lightning
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> https://github.com/noctarius/direct-ring-cache
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> It would be nice to help out since I really
> >>>>>>>>> like the idea of
> >>>>>>>>>>>>>>>>>>>>>
DirectMemory and since
> >>>>>>>>>>>>>>>>>>>>>
direct-ring-cache is
> >>>>>>>>>>>>>>>>>>>>>
some kind of
> >>>>>>>>>>>>>>> reinventing
> >>>>>>>>>>>>>>>>>>>>>
the wheel.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
Cheers Noctarius
> >>>>>>>>>>>>>>>>>>>>>
(Chris)
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -- Olivier Lamy
Talend:
> >>>>>>>>>>>>>>>>> http://coders.talend.com
> >>>>>>>>>>>>>>>>> http://twitter.com/olamy
|
> >>>>>>>>>>>>>>>>> http://linkedin.com/in/olamy
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -- Olivier Lamy Talend:
> >>>>>>>>>>>>>>> http://coders.talend.com
> >>>>>>>>>>>>>>> http://twitter.com/olamy
|
> >>>>>>>>>>>>>>> http://linkedin.com/in/olamy
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -- Olivier Lamy Talend:
> >>>>>>>>>>> http://coders.talend.com
> >>>>>>>>>>> http://twitter.com/olamy |
> >>>>>>>>>>> http://linkedin.com/in/olamy
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -- Olivier Lamy Talend: http://coders.talend.com
> >>>>>> http://twitter.com/olamy |
> >>>>>> http://linkedin.com/in/olamy
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJQZ/ZZAAoJEH/g+YBfahrqbIUQALEwBddCj1OY7z2QYgUDze6u
> t2RfhWdWpArExVG4vof46xwJ6RmF5T6muIjl3MoR8B6dG46QeBxv3bPq0RmUkcAF
> U8USSMnC9w6Qr6DCjCwjqLb7dnUBgNGqLIMdIIePX7+UxnOOsQ9l4Ext0Vsz5xn3
> 2qkmy7nxiuBkox9OJlXlB8Nt//3LgHRi3iIuBpZ6S4GEwILIQ/UT0WuGKFx6+Sa7
> bOwtSnViERwYNUiFth8O3SS4KmCsEHwWijV6vd+/jxVGhFqMSzxhj5++KzhCe+GZ
> /WavR3rrvmZot9Mmpc4wDWj+6l6PXQrIXqxZDy9SrV7619r0Mh/SvbAKasP+/uMb
> XLjQ/eZoAXRJ34G2l9l3q33lqwv7GK0+zcmgbgX6qun1eKUMuTR/08qfxu1UZO/k
> MMAEZKfT50sNiEDHFKqyGLk8hgTh4nvoCPwxNZBWbezgIFg+8NdigdAlgIxWb+59
> HwTaFtGmbZYkje0dx6WkoNXgLUsLLGOAq+rSbn4Pz3594hb7leJOIgGKUXA1/Eak
> XoXFaXR/eg9ICuzrgN17Apz7GqN4HT3HxmGk6h+J6jkLTFOfyK5J6WQpP0hEXU5O
> 7dH6q0Zc/Af1J8eT2IGUrbbbwRWwXxIBUEQocon4VoDa219gmev/fxrRlL1xuB9f
> 7LS2c0gONRWWdl7M5n8+
> =/dDf
> -----END PGP SIGNATURE-----
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message